Docker, Kubernetes에서의 런타임시 Containerd로의 전환

 

Docker 측에서는 기존 Docker Engine의 Monolithic한 구조를 나누는 작업을 시작했다.

초기 Docker를 개발하면서 하나의 완성된 컨테이너 사용자경험을 만드는 것에 집중하다보니 Docker Engine이라는 하나의 패키지에 API, CLI, 네트워크, 스토리지 등 여러 기능들을 모두 담게 되었고, Docker에 의존하고 있던 Kubernetes에서는 Docker 버전이 새로 나올때마다 Kubernetes가 크게 영향을 받는 일들이 생겨났다.

 

이로 인해, Docker를 중심으로 구글 등 컨테이너 기술에 관심있는 여러 집단들이 한데 모여 Open Container Initiative, 이하 OCI라는 프로젝트를 시작하여 컨테이너에 관한 표준을 정하는 일들을 시작하게 된다. 그래서 Docker에서는 OCI 표준을 준수하는 containerd라는 Container Runtime을 만들고, Kubernetes에서는 OCI 표준을 준수하는 이미지들을 실행할 수 있는 Container Runtime Interface, 이하 CRI 스펙을 버전 1.5부터 제공함으로써 Docker 버전과 무관하게 OCI 표준을 준수하기만 하면 어떤 컨테이너 이미지도 Kubernetes에서 실행가능한 환경이 만들어지게 되었다.

 

요약하자면 컨테이너를 빌드하고, 실행하고 거기에 네트워크, 스토리지, CLI까지 제공해주는 Docker Engine이라는 패키지가 있었는데, 이게 하나의 패키지로 묶여있다보니 여러 불편함들이 생겨났고 이를 해소하기 위해 여러 사람들이 모여 OCI라는 Container Runtime 표준을 만들고 이 표준대로 각자 Container Runtime을 만들기 시작했는데 Docker에서 만든 Container Runtime이 바로 containerd (https://containerd.io/)라는 이야기이다. 참고로 containerd의 d는 daemon의 d이다.

 

한편, Red Hat, Intel, SUSE, Hyper, IBM 쪽에서도 OCI 표준에 따라 Kubernetes 전용 Container Runtime을 만들었는데 이것이 CRI-O (https://cri-o.io/)이다. containerd와 CRI-O 이 두가지 Container Runtime이 현재 가장 널리 사용되고 있으며 containerd는 Docker Engine에 기본으로 탑재되어 있어서 지금도 Docker를 사용한다면 내부적으로 사용되는 Container Runtime은 containerd 를 사용하게 된다. 참고로 `docker build` 커맨드로 생성되는 이미지들 역시 OCI Image Spec을 준수하기 때문에 별도의 작업없이 containerd로 실행시킬 수 있다.

 

이렇게 Container Runtime이 Monolithic 아키텍처에서 분리되어 나오면서 Java 어플리케이션을 배포할 때 JDK보다 가벼운 JRE를 사용하는 것처럼 (물론 이 경우에는 보안과 같은 다른 이유도 있다.) 컨테이너를 실행할 때 무거운 Docker Engine이 아닌 containerd나 CRI-O와 같은 가벼운 Container Runtime을 사용하게 되면서 다음과 같은 장점도 나타나게 되었다.

 

 

 

• "kubelet workingset": 이는 kubelet 프로세스의 현재 메모리 작업 집합을 말하며, 시스템의 RAM에서 활성으로 사용 중인 부분을 의미한다.
• "kubelet rss" (Resident Set Size): 이는 kubelet 프로세스가 사용 중인 메모리의 양을 나타내며, 실제로 RAM에 올라와 있는 부분이다.
• "runtime workingset": 이는 컨테이너 런타임의 메모리 작업 집합을 말한다.
• "runtime rss": 이는 컨테이너 런타임의 rss를 나타낸다.

쉽게 말해 containerd로의 전환을 통해 Pod은 더 빨리 시작되고, CPU와 메모리의 사용량은 더 줄었다는 이야기로, containerd로의 전환이 왜 일어나고 있는지를 잘 설명해주고 있다.

 

하지만, containerd를 사용하는 방법은 분명히 Docker에 비해 까다롭다. 개발자 입장에서는 예전과 같이 docker build만 실행하면 되기 때문에 크게 달라지는 것이 없다고는 하나, Kubernetes 클러스터를 운영하는 입장에서는 Docker로 한번에 모든 것을 제어할 수 있었던 예전과는 달리, 이제는 runc, containerd, ctr 등 낯선 라이브러리들과 익숙해져야 하는 부담이 생겼다.

 

dockershim 은 도커 컨테이너를 실행시키기 위한 “도커 컨테이너 런타임”이다.

윗 글에서 언급한 대로 Dockershim 은 이제 무거워진 도커 엔진에서 벗어나고자 deprecated 되었고,

CRI(Container Runtime Interface) 에 맞춰 만들어진 containerd를 도커 컨테이너 런타임으로 사용하게 되었다.

따라서 K8S 1.24부터는 dockershim 으로 정상적인 설치가 안되며, 이미 EKS, AKS, GKE 와 같은 클라우드 업체의 K8S 플랫폼에서는 모두 dockershim -> containerd로 변경되었다.

 

따라서 K8S 1.24 이후 버전에서는 

`$ docker ps` 와 같은 명령어를 사용할 수 없으며

`$ crictl ps` 명령어로 container들의 상태를 확인할 수 있게 되었다.