Docker vs Containerd / Container runtime, 쿠버네티스, 도커, 차이점, 장단점

Container Runtime 때문에 문제가 생겼던 적이 있었다... Containerd와 Docker를 혼용하다가 생긴 문제였다.

다들 알다시피 Kubernetes version 1.24부터 Docker를 사용하지 못하게 됐다.

Dockershim Removed from kubelet

After its deprecation in v1.20, the dockershim component has been removed from the kubelet in Kubernetes v1.24. From v1.24 onwards, you will need to either use one of the other supported runtimes (such as containerd or CRI-O) or use cri-dockerd if you are relying on Docker Engine as your container runtime. For more information about ensuring your cluster is ready for this removal, please see this guide.

하지만 규모가 큰 서비스를 할때는 바로 최신버전을 사용하는 것이 어려운 것 같다.

스타트업을 다닐때는 그냥 버전업하고 마이그레이션 하면 되는거 아니야? 라고 생각을 하곤 했다.

그러나 여러 연계된 서비스들이 존재하는 상황이라면 각 서비스 간 버전을 맞춰야 할 것이고, 최신버전을 사용하게 되면 예상치 못한 문제에 대해 대비를 해야한다.

흔치않지만, 특정 커널 버전에 예상치 못한 문제가 생긴다던지.. 언어 버전에 따라 보안취약점이 발견된다던지..

실제로 이러한 문제가 생기기도 하기때문에 실시간 서비스를 하게되면 보수적으로 접근하게 되는 것 같다.

이번 기회에 Docker와 Containerd의 차이를 정리해두려고 한다.

 

Docker vs Containerd

---

- 구조

https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/#containerd-1-0-cri-containerd-end-of-life

Kubernetes 공식 문서에 나와있는 Docker와 Containerd의 구조

Docker와 Containerd의 차이를 한눈에 볼 수 있어서 좋은 것 같다.

사실 Docker도 OCI표준을 준수하는 containerd를 사용하기 때문에 그 하위 단계에서는 차이가 존재하지 않는다.

중간에서 편의성을 제공하는 것으로 간단하게 보면 될 것 같다.

버전이 올라감에 따라 containerd에서도 편의성 기능이 점점 추가되고 있어서, 추후에는 결국 containerd로 다 마이그레이션 되긴 할 것이다.

 

- 장단점

containerd is a lightweight container runtime, suitable either for limited-resource computing environments or when you’re using a container management system like Kubernetes. Due to its basic interface and lack of ability to build images, it may not be suitable for your development purposes.

Docker offers a full-featured toolkit to build, run, and manage container images and containers in standalone and networked setups. It provides more features than containerd and is more human friendly. Also, Docker uses containerd, which makes it suitable for desktop and continuous integration (CI) build environments. You could use it in production as well if Kubernetes is not available, or if you need isolated network namespaces.

https://earthly.dev/blog/containerd-vs-docker/

Comparing Container Runtimes: containerd vs. Docker

약 1년전 글이긴 한데.. 간단하게 이해가 되는 것 같아서 가져왔다.

요약하자면

Containerd는 중간에 layer가 적기때문에 좀 더 가볍기때문에 제한된 리소스를 써야하는 환경이라면 좀 더 좋을 것이고, 대신 개발 편의성이 떨어진다.

Docker는 build, run, image관리 등에서 좀 더 편의성이 잘 제공되어있고, CI환경이나 kubernetes환경이 아닌 곳에서 더 편리하게 사용할 수 있을 것이다.

라는 뜻이다.

 

- Command 차이

실제로 사용하는 입장에서 한번 알아두면 좋을 것 같아서 정리해봤다.

아직 Docker를 Container Runtime으로 사용하는 입장에서 내가 주로 사용했던 명령어들을 생각해보면,

docker build, commit, push, run, inspect, ps, image prune... 등등이 기억나는데 대부분 crictl로 docker명령어를 대체하는 것으로 보인다.

찾아보니 몇몇 주요한 차이점이 존재하는 것같아서 해당 부분을 정리해보면

  - docker push대신 crictl push는 없고 ctr이라는 containerd 클라이언트 툴을 사용해야 한다.

  - crictl에서는 crictl pods, runp, stopp 와 같은 pod에 좀 더 친화적인 기능을 제공한다. (Docker에선 제공X)

  - 이미지를 정리하는 명령어인 docker image prune 도 crictl rmi --prune 과 같이 차이가 있다.

  - 이외에 몇몇 일부 차이가 존재할 것 같고, 대부분의 주요한 명령어는 동일했다.

내가 주요 사용하는 Command 위주로 찾아봤을 때 이런 차이점이 존재했었고, 아직 직접 사용을 해보지는 않았기 때문에 더 많은 차이가 존재할 것 같다. containerd를 사용하다보면 익숙해질 것으로 보인다.

 

- 마무리

정리를 해보니 이제 containerd도 많은 부분에서 Docker와 비슷하게 지원이 되는 것 같다. 오히려 Kubernetes cluster를 구성한다면 pod에 대한 편의성은 containerd가 더 좋은 것 같은데? 라는 생각이 들 정도였다.

아직 Docker가 익숙하기도 하고, containerd에 대한 공부가 부족하기 때문에 어색하긴 하지만 Kubernetes에 나오는 새로운 기능들을 사용하기 위해서는 꾸준히 공부하여 containerd와 친해져야 할 것 같다.