CRI와 dockershim

dockershim1

출처: https://www.tutorialworks.com/difference-docker-containerd-runc-crio-oci/

runc는 가장 낮은 수준의 컨테이너 런타임으로 Linux의 기본 기능을 사용하여 컨테이너를 생성하고 실행합니다. OCI 표준을 따르며 컨테이눠 생성을 위한 Go 라이브러리인 libcontainer가 포함되어 있습니다. 컨테이너는 로우 레벨 런타임 위에 위치하며 이미지 전송, 스토리지, 네트워킹과 같은 다양한 기능을 추가한 상위 컨테이너 런타임입니다. 또한 OCI 사양을 완벽하게 지원합니다.

Docker 데몬은 표준 API를 제공하고 컨테이너 런타임과 통신하는 데몬 프로세스(백그라운드에서 계속 실행되는 장기 실행 프로세스)입니다. 쿠버네티스는 원래 도커를 사용했었지만 시간이 지나면서 독자적인 플랫폼으로 발전, 다른 컨테이너 런타임을 연결할 수 있는 컨테이너 런타임 인터페이스(CRI) API가 Kubernetes에서 만들어졌고 Kubernetes보다 오래된 프로젝트인 Docker Engine은 CRI를 구현하지 않았습니다. 따라서 전환을 돕기 위해서 Kubernetes 프로젝트에 dockershim이라는 구성 요소가 포함되어 Kubernetes가 docker 런타임으로 컨테이너를 실행할 수 있게 되었습니다.

dockershim은 쿠버네티스에서 CRI 인터페이스가 도입된 이후, Docker를 쿠버네티스 환경에서 계속 사용할 수 있도록 하기 위해 만들어졌습니다. 쿠버네티스는 컨테이너 오케스트레이션 플랫폼으로 초기엔 Docker 컨테이너 런타임을 기본 런타임으로 사용했습니다 도커는 컨테이너를 생성하고 관리하기 위한 플랫폼으로 쿠버네티스와 함께 널리 사용되었습니다. 이후에 쿠버네티스는 다양한 컨테이너 런타임을 지원하기 위해 CRI를 도입했으며 CRI는 컨테이너 런타임과 쿠버네티스 간의 표준 인터페이스를 정의하여 다양한 컨테이너 런타임을 쉽게 통합할 수 있게 하였습니다.

dockershim은 CRI 인터페이스를 통해 dockershim에 명령을 보내고, dockershim은 이를 Docker 엔진에 전달하여 컨테이너를 관리합니다. 하지만 쿠버네티스 커뮤니티는 dockershim을 장기적으로 유지하는 것이 기술 부채를 증가시킨다고 판단하여 Kubernetes 1.24 버전부터는 공식적으로 dockershim 지원이 중단되었습니다. Kubernetes 환경에서는 Docker 대신 Containerd, CRI-O 와 같은 CRI 호환 컨테이너 런타임 환경을 사용하는 것이 권장됩니다. 이러한 런타임들은 CRI 표준을 따르기 때문에 추가적인 어댑터 없이 쿠버네티스와 직접 통합됩니다.

OCI는 컨테이너 세계를 위한 몇가지 표준을 만들기 위한 최초의 노력 중 하나였으며 2015년에 도커 등이 설립, 여러 기술 회사의 지원을 받아 컨테이너 이미지 형식과 컨테이너 실행 방식에 대한 사양을 관리하고 있습니다. 기본 개념은 컨테이너가 무엇이며 컨테이너가 무엇을 할 수 있어야 하는지를 표준화하는 것입니다. 즉, 사양을 준수하는 다양한 런타임 중에서 자유롭게 선택할 수 있습니다. 그리고 이러한 런타임은 각각 다른 하위 수준 구현을 가질 수 있습니다.

CRI는 쿠버네티스 프로젝트에서 만든 API로 CRI는 쿠버네티스 컨테이너를 생성하고 관리하는 다양한 런타임을 제어하기 위해 사용하는 인터페이스입니다. 쿠버네티스는 사용자가 어떤 컨테이너 런타임을 사용하는지 신경 쓰지 않습니다. 단지 파드용 컨테이너를 생성하고 종료하는 등의 명령만 전송할 수 있습니다. 쿠버네티스 프로젝트가 각 런타임에 대한 지원을 개별적으로 추가할 필요가 없는 대신, CRI CPI는 쿠버네티스가 모든 런타임과 상호 작용하는 방법을 설명합니다. 특정 컨테이너 런타임이 CRI API를 구현하는 한 런타임은 원하는 대로 컨테이너를 생성하고 시작할 수 있습니다.

참고 자료