dockerd : 컨테이너를 지속적으로 관리하는 데몬 프로세스로서, docker CLI 같은 클라이언트가 사용할 수 있는 RESTful API를 제공하고 있음...흔히 명령어로 사용하는 docker 실행 파일이 docker CLI이고... 사용자가 입력하는 docker 명령어는 이 dockerd에 전달되고, 실행됨
dockerd는 unix, tcp, fd의 세 가지 소켓 유형을 통해, 도커 API 요청을 수신할 수 있습니다.
containerd(container daemon)
containerd는 이미지를 push 하고 pull하고, 스토리지를 관리하고, 네트워킹 기능을 정의할 수 있는 독립 실행형 고수준 (high-level)컨테이너 런타임입니다. runc 같은 저수준(low-level)의 컨테이너 런타임에 해당 명령을 전달하여, 컨테이너를 실행하는 등의 라이프사이클을 관리한다.
도커에 의해 빠르게 확산되고 있던 컨테이너 환경에서, 컨테이너 런타임을 특정 벤더에 의존하지 않고, 중립적인 입장에서 컨테이너 표준에 맞게 구현하는 것을 목적으로 만들어짐.
Docker Inc는 2016년 12월 컨테이너 런타임 부분을 독립적은 오프소스 프로젝트인 containerd로 분리하여, 마이크로 소프트, google, AWS, IBM 등과 공동으로 개발하기로 발표.
그리고, 2017년 3월에는 CNCF (Cloud Native Computing Foundation)에 기부되었고, 이후 이를 담당해왔습니다.
도커는 1.11 이후 버전부터 containerd를 컨테이너 런타임으로 사용하고 있습니다.
containerd-shim
containerd-shim은 runc를 실행하고, 컨테이너 프로세스를 제어하는 경량 데몬입니다. 컨테이너와 containerd 의 모든 통신은 containerd-shim 을 통해서 이루어 집니다.
containerd-shim 은 보통 다음과 같은 역할을 담당합니다.
컨테이너의 stdout 및 stderr의 스트림을 제공해 주고 있습니다. 그래서 containerd 가 재시작 중에도 문제가 발생하지 않습니다. containerd 는 stdout 및 stderr의 스트림을 받아서 로그 파일로 저장을 할 수 있습니다.
runc 는 컨테이너 프로세스를 실행(fork)한 다음, 포그라운드 프로세스를 종료하여, 컨테이너 프로세스를 의도적으로 데몬화 합니다. 이렇게 되면, 컨테이너 프로세스는 호스트의 init 프로세스가 담당하게 되어서, 컨테이너의 관리가 어려워집니다. 이 문제를 해결하기 위해 shim 프로세스를 subreaper로 만들어서, 컨테이너 프로세스를 shim 프로세스가 관리하도록 합니다.
runc
OCI 런타임 스펙을 구현하고 있는 저수준 컨테이너 런타임입니다. 저수준 컨테이너 런타임이라고 부르는 이유는, 오직 실행 중인 컨테이너 관리에만 그 범위를 집중시키고 있기 때문입니다. 리눅스 커널의 네임스페이스와 cgroups 을 사용하여 격리시키는 기능을 제공합니다. 컨테이너를 생성(spawning)과 실행(running) 할 수있는 CLI로 구현되어 있습니다.
runc 는 도커 프로젝트(이전 이름은 libcontainer)에서 나와, OCI에 기부되었고, 이후 이를 담당해 왔습니다.
<요약>
<Docker의 운영 방식>
Docker는 Docker라는 회사에서 실행하는 컨테이너 관리 프로젝트 세트 이러한 프로젝트는 함께 작동하여 컨테이너 배포를 위한 포괄적인 플랫폼을 제공
docker의 구성 단위
docker CLI : 명령줄 인터페이스 프로그램입니다. 사용자는 docker CLI를 실행하여 Docker 컨테이너를 만들고 관리 합니다 .
containerd : 사용자의 명령을 수용하는 단계. 명령을 수신하고 데몬으로 움직입니다. 요청한 이미지를 가져와 저장하고 컨테이너 수명 주기를 제어합니다.
runC - 가볍고 이식 가능한 컨테이너 런타임. runC는 Docker가 로컬 시스템과 상호 작용하는 데 필요한 구성 요소를 통합하는 저수준 구성 요소. 이 도구가 생성하는 컨테이너는 OCI와 호환됩니다.
kubernetes with docker(before v1.20)
kubernetes는 dockershim이라는 컴포넌트로 docker를 위한 컴포넌트를 운영해왔었다.
kubernetes(v1.24)부터 다른 container runtime을 CRI(container runtime interface)를 사용함으로서 지원하는 개발 방향으로 바꾸었다.
그럼으로 kubernetes의 버전이 올라간다고해서 docker형식의 컨테이너를 실행 할 수 없다는 것을 의미하지는 않는다. containerd 와 CRI-O 는 모두 Docker 형식(실제로는 OCI 형식) 이미지를 실행할 수 있으며, docker명령이나 Docker 데몬 을 사용하지 않고도 실행할 수 있습니다 .
CRI는 무엇인가?
CRI는 kubernetes가 컨테이너를 생성하고 관리하는 다양한 런타임을 제어하는 데 사용하는 프로토콜입니다.
CRI는 사용하려는 모든 종류의 컨테이너 런타임을 지원하기 위한 추상화된 개념입니다. 따라서 CRI의 표준을 따르는 이상 kubernetes가 다른 컨테이너 런타임을 더 쉽게 사용할 수 있습니다.
각 런타임데 대한 지원을 수동으로 추가해야하는 kubernetes 프로젝트 대신 CRI API는 kubernetes가 각 런타임과 상호작용하는 방식을 결정합니다. 따라서 실제로 컨테이너를 관리하는 것은 런타임에 달려있습니다. 다시말해, CRI API를 준수하는 한 원하는 모든 컨테이너 런타임을 통해 작업을 수행 할 수 있다.
