[k8s] 컨테이너 한방 정리

 

기술의 흐름으로 이해하는 컨테이너

 

k8s 역사와 흐름

쿠버네티스 (kubernetes - 이하 k8s)

• 쿠버네티스를 한마디로 정의 → '오픈소스 컨테이너 오케스트레이션 플랫폼'
• 컨테이너 가상화 / Dev-ops 환경에서 이젠 필수적인 요소
• 컨테이너를 중심으로한 여러 배경 흐름이 중요하다.

 

1. Linux OS 흐름

• 최초의 리눅스는 UNIX (유료) 로 시작함 → Linux (무료) unix의 배포판.
• Linux 는 debian 계열과 RedHat 계열로 나뉨
• debian 기반 ubuntu
• RedHat 기반 
  • fedora : 최초 무료 배포용
  • RedHat Enterprise Linux (RHEL) : 유지보수 비용을 내는 유료 버전
  • CentOS →  RHEL 복제판 (오픈소스)
• CentOS 의 현 상태
  • CentOS 8 → 2021 지원종료
  • CentOS 7 → 2024 종료예정
• RedHat → IBM 인수이후 현 상태
  
  • fedora : 동일하게 사용. (기능개발)
  • CentOS Streams : fedora 에서 개발한 기능을 테스트 (테스트베드) → 바이너리 호환성 보장안됨.
  • RedHat Linux : 안정화버전

이후 기업들의 CentOS 대체 방안

 

오픈소스 활용을 위해 Rocky Linux / AlmaLinux 중 선택

 

AlmaLinux vs RockyLinux

• Github Watch/Fork/Start 비교 (rocky link), (alma link)

2. Container 흐름

 

 

• Linux 발전에 따라 내부 코어기술도 함께 발달함.
• 그중 하나가 격리 기술.

격리기술

• chroot (사용자격리) : 파일이나 네트워크를 분리하는 기술이 발전한다.
• cgroup : App 마다 cpu 나 memory 를 할당
• namespace : 프로세스 격리
• 이 기술들을 집약하여 정리한 것이 LXC (LinuxContainer)
• LXC 를 기반으로 여러 컨테이너들이 발전함. ex) Docker

• 이전 몇몇 컨테이너 기술들은 사용이 어려웠지만 Docker 는 사용이 매우 쉬움.
• rkt (rocket 컨테이너) : docker 가 보안에 취약한 점을 공략하기 위해 안정적인 컨테이너로 새롭게 등장.
  • Docker 는 root권한으로 설치를 진행했어야 했음.
  • Docker 에서 이제는 rootless 설치 모드가 생겨서 보안이 강화되었다.
• 클라우드 시장에서 점점 표준화가 되어가는 쿠버네티스에서 이제는 어떤 컨테이너를 써야 하는지에 대한 서로간의 경쟁이 시작되었다.
• 대표적인 컨테이너
  • containerd : Docker 에서 컨테이너 기능만 분리된 프로젝트 (CNCF Graduated Project)
  • cri-o : RedHat 에서 만든 컨테이너 (CNCF Incubating Project)
  • 두 프로젝트 모두  CNCF 에 기부됨

 

 

3. Container Orchestration과 Container 흐름

• 도커는 LXC 기반 libcontainer 를 사용자 친화적으로 만들어짐.
  • 도커와 LXC 모두 컨테이너 가상화를 하지만 서로 성격이 다소 다름
  • LXC : 운영체제를 컨테이너 가상화로 나누기 위한 목적
  • Docker : App을 가상화로 독립적으로 띄우기 위한 목적
• 쿠버네티스가 컨테이너 런타임을 어떻게 쓰는지
  1. kube-apiserver : 쿠버네티스에 요청되는 모든 요청을 받음
  2. kubelet : Pod 생성에 대한 처리를 진행하여 컨테이너 런타임(Docker)에게 컨테이너 생성 명령을 넘김
• kubelet 에서 컨테이너 런타임에 따라 컨테이너 생성 명령이 나누어져 있었다.
• 컨테이너 런타임이 계속 생성되면서 쿠버네티스에서 관리해야 할 컨테이너 런타임이 너무 많아짐.
• 쿠버네티스는 런타임이 늘어날때마다 kubelet 소스를 수정해야 되는 번거로움이 생김
  • 이를 해결하기 위해 쿠버네티스 1.5 버전부터 interface 개념이 도입됨.
  • 구현부(CRI) 를 따로두어 kubelet의 인터페이스 규격을 정하고 이 규격에 맞게 구현부를 만듬.
  • 각 구현분에서 컨테이너 런타임을 호출한다. (런타임 측에서 소스를 만들어 쿠버네티스에 contribution 하는 형태)

한창 쿠버네티스에서 도커의 지원을 중지한다는 이야기가 있었는데 그럼 도커를 이제는 쓰면 안되는 것인가?

• k8s 1.0 에서 도커를 사용하던 로직을 1.20 에서 deprecated 됨
• k8s 1.5 버전부터 인터페이스 규격으로 정한 로직을 쓰겠다는 말 이었음. 이 또한 1.23 버전에서 deprecated
• CLI 에서 dockershim 만 빼겠다는 내용이었으나 오해가 있었음.
• k8s 1.24 버전부터 Docker 를 인수한 MIRANTIS 에서 dockershim 프로젝트를 cri-dockerd 프로젝트로 분리하여 다시 사용 가능해짐. → Mirantis Container Runtime
• OCI 에서 컨테이너 규격을 표준화 하게됨. → 런타임끼리 서로 이미지 공유가 가능함.
• Docker 에서는 이 표준을 지키기 위해 runC 를 만듬 →  containerd 에서 사용하도록 변경됨.
  • runC : LXC 를 사용하지 않고 kernel-level 의 가상화를 바로 사용

 

 

• k8s 1.24 버전 이전에는 컨테이너 런타임에서 변경이 있을시 CRI 구현체도 변경되어야 하는 번거로움이 있었으나 1.24 버전 이후부터 CRI-Plugin 을 통해 kubelet 에서 직접 받을수 있게 구현이 변경됨.
• 1.27 버전부터 stable 되어 이 동작으로 동작하게 된다.