1) History
컨테이너가 대중화 되기 이전에는 Docker만이 존재했었고, 컨테이너 작업이 아주 간단해진다는 사용자 경험 덕분에 지배적인 입지를 가짐
그러나 오케스트레이션이라는 개념이 필요해짐에 따라 쿠버네티스가 등장하게 되었는데, 당시의 쿠버네티스는 CRE(Container Runtime Engine)으로 Docker만 지원
쿠버네티스가 유명해짐에 따라 Docker 외의 다른 CRE를 지원할 필요가 있었고, 이에 따라 CRI(Container Runtime Interface)라는 개념을 도입
즉, OCI (Open Container Initiative) 라는 표준을 지키기만 하면 어떤 CRE든 Kubenetes의 CRE로 사용할 수 있음
OCI의 규격으로는 imagespec과 runtimespec으로 나뉨 (imagespec은 컨테이너의 이미지를 어떻게 만들어야 하는지 (이미지 빌드 방식)의 규격, runtimespec은 컨테이너의 런타임 동작 방식의 규격)
따라서 Docker 이후에 나온 대부분의 CRE는 CRI를 만족하는데 반해, Docker는 CRI가 생기기 이전에 만들어졌고 CRI를 만족하기 위해 만든 것이 아니기 때문에 표준 스펙이 아니라는 문제가 발생
Docker가 표준은 아니지만, 여전히 지배적인 CRE 였기에 쿠버네티스는 Docker를 CRE로 계속 지원할 필요가 있었음
표준이 아닌 CRE를 지원하는 방식이 쿠버네티스의 기능 확장에 제약이 커지자 지원 가능한 CRE에서 Docker를 공식적으로는 배제하고, dockershim이라는 기능을 통해 Docker를 지원하는 방식으로 변경 (이는 CRI라는 규격을 사용하는 CRE로의 동작이 아닌 Docker 자체만을 위한 동작)
하지만 Docker를 위한 dockershim을 유지하는 것이 불필요한 노력으로 이어진다는 추가적인 문제 때문에 쿠버네티스 1.24 버전을 기점으로 Docker는 쿠버네티스의 CRE에서 배제 (일단 Docker가 CRE에서 배제된다고 하더라도 Docker를 이용하여 만든 이미지는 정상 동작을 보장하는데, 이는 Docker가 CRI의 imagespec을 준수하기 때문)
여기서 Docker가 왜 표준 스펙이 아닌지 이해하면 Docker가 CRE에서 배제되었지만 근본적으로 해결이 가능하다는 것을 알 수 있음
Docker는 CLI, API, BUILD, VOLUMES, AUTH, SECURITY, ContainerD 등이 포함되는 다중 도구였기 때문에 CRI를 만족하지 않는 것인데, Docker에 포함되어 있는 ContainerD는 다른 CRE처럼 CRI를 만족하는 CRE였기에 이를 분리하여 지원하면 dockershim이라는 임시 해결책에서 벗어날 수 있음
이와 같은 이유로 ContainerD라는 개념이 Docker로부터 분리되어 CRE로 정착하게 됨
2) CLI
위에서 보았던 것과 같이, ContainerD의 시작은 Docker였지만 현재는 완전히 독립적인 프로젝트
따라서 이전에는 ContainerD를 이용하려면 Docker를 설치해야 했지만, 현재는 별도의 프로젝트로 분리되었기 때문에 ContainerD만 설치하여 사용 가능
이전에는 Docker라는 다중 도구가 있었기에 ContainerD가 컨테이너를 실행하게 만들 수 있었는데, ContainerD만 설치한 경우에는 컨테이너를 실행할 수 있도록 별도의 장치가 필요했음
이에 따라 ctr이라는 ContainerD를 지원하는 CLI도 함께 개발되었고, ContainerD를 설치할 때 함께 설치됨 (CRI에 포함되는 것은 아니고 설치 시 번들로 함께 설치되는 것)
하지만 ctr은 기본적으로 디버깅을 위한 컨테이너만 지원하는데다가 사용자 친화적이지 않았기 때문에, nerdctl이라는 CLI가 개발됨 (Docker에서 지원하는 기능들을 모두 제공하고, 쿠버네티스 친화적인 추가 기능들도 제공)
nerdctl은 Docker 명령어의 형식을 거의 그대로 계승해서, Docker 이용자들도 헷갈리지 않고 ContainerD를 조작할 수 있음
ctr 및 nerdctl 외에도 CRI를 만족하는 CRE를 제어할 수 있는 crictl도 있는데, crictl은 다른 CLI와 달리 특정 CRE를 조작하는 것이 아니라 쿠버네티스의 관점에서의 (인터페이스 관점에서의) 상호작용을 제공
즉, crictl만 알면 쿠버네티스 위에서 동작하는 대부분의 CRE를 제어할 수 있는데 (ContainerD를 위해 만들어졌음에도 다른 CRE의 제어를 보장함), 단점으로는 ctr 처럼 crictl도 디버깅 목적의 CLI라는 것 (crictl의 기능이 Kubelet과 잘 어울리는데, crictl을 통해 컨테이너를 만들면 Kubelet은 자신도 모르게 만들어진 컨테이너를 지우기 때문에 디버깅 목적으로 활용 가능)