Container Runtime 컴포넌트 분석

컨테이너 런타임에 대해서 조사하다보면 OCI나 container-shim 과 같은 생소한 용어들이 보인다. 컨테이너 런타임의 과정에 대해서 조사를 하면서 추가로 Runtime 과 관련된 컴포넌트들을 정리해본다.

먼저 자주 쓰이는 용어들은 아래와 같이 별도로 정리하였다.

*OCI (Open Container Initiative) : 컨테이너의 기술적 표준. 혹은 컨테이너 기술 표준을 설계하기 위한 Linux foundation project를 지칭한다. 컨테이너 기술을 구현하기 위해서 구현해야 하는 cgroup, namespace 등에 대한 표준을 정의하였으며 Runtime-spec 과 Image-spec 으로 각각 구분된다.

*CRI (Container Runtime Interface) : kubelet 이 컨테이너를 제어할 수 있도록 해주는 인터페이스로 Kubernetes와 통신하는 다양한 container runtime 에 대하여 통일화 된 인터페이스를 제공한다. CRI 표준을 따르는 컨테이너 런타임이 kubernetes와 통합하도록 지원하는 역할을 한다.

다음으로 Container Runtime과 관련된 component 들에 대하여 아래와 같이 정리하였다.

컴포넌트	설명
kubelet	kube-apiserver 로부터 명령을 받아 CRI API(gRPC)로 cri-o, dockerd, containerd 와 같은 CRI runtime 서비스를 호출한다. - dockerd : pull 등의 CRI 명령을 수행 - containerd : run, exec, logs 등의 CRI 명령을 수행     ※ cri-o (다 통합된 형태, cri-o 도입시)
dockerd	docker client(명령어)에 대응하는 서버 프로세스 - docker 명령어를 받고 containerd를 제어한다. - containerd에 의존적이며 containerd 없이 단독으로 실행되지 않는다.     = systemctl stop docker → dockerd만 stop     = systemctl start docker → 둘다 start - dockerd 구동 시, 컨테이너와의 통신을 위하여 containerd의 grpc address를 파라미터로 실행
conatinerd (High Level)	runC를 호출하여 컨테이너를 구동한다. - containerd-shim들의 부모 프로세스 - 프로세스 기동 순서 : 리눅스 부팅 → containerd 시작 → dockerd 시작 - containerd만 start하면 혼자 실행된다. (독립적) - dockerd는 containerd에 의존적이다.     = systemctl start containerd → containerd만 start     = systemctl stop containerd → 둘다 stop     = systemctl stop docker → dockerd만 stop     = systemctl start docker → 둘다 start
containerd-shim	주요 역할 - 컨테이너 내 PID 1 프로세스의 부모 프로세스(wrapper) - dockerd 와 containerd 사이를 분리     = 컨테이너 엔진 업그레이드 등으로 관리 레벨(dockerd)이 재기동 되어도 컨테이너에 이상이 없도록 분리 - container log/exec 등을 수행 - runC를 이용하여 컨테이너를 생성. runC가 죽은 후 container 프로세스의 부모 프로세스가 됨. - 컨테이너의 종료 status 보고 *shim이란? 벽돌들을 일정한 간격으로 배열하기 위해 사이에 끼우는 끼움쇠 → 의미: containerd와 container(PID 1) 사이의 간격 유지
runC (Low Level)	- cgroup, namespace 등을 호출하여 컨테이너를 직접 구동("run container") 하는 명령 줄 도구 - 컨테이너를 구동한 후 종료된다 - Docker, cri-o 등에 의해 호출되어 사용된다. - 독립 실행형 파일이며, contatinerd 패키지에 포함되어 있음. (파일위치는 버전에 따라 상이)     = /usr/sbin/runc (1.0.0-rc6+dev)     = /bin/runc (1.0.1-dev) 작업흐름 (다음 문단 그림 참조) 1. docker run ... 2. containerd가 자식프로세스 containerd-shim 생성 3. containerd-shim이 runc 호출 4. runc는 container를 생성하고 종료되며     -> 호출 구조상 container는 containerd-shim의 자식 프로세스가 된다. 5. 생성된 container(PID 1)는 containerd-shim의 자식이 된다.

 

Component 들의 호출 구조는 다음과 같다.

 

시간 순으로 본 Container Runtime Model 의 변화상은 아래와 같다. Docker 와 kubernetes 그리고 CRI 에 대한 히스토리도 하단 그림과 함께 다음에 정리해보기로 한다.