Containerd VS Docker

평소 모든 작업을 Docker에서 진행하고 있지만, 컨테이너 기술의 개념과 이론적인 지식이 많이 부족하다고 생각되어 찾아보게 된 내용을 정리한 글로 내용을 계속 추가할 예정이다.

Docker

- Docker의 기본 아이디어는 프로세스, CPU, Memory, disk I/O, Network 등의 리소스들을 컨테이너라는 독립적인 하나의 그룹으로 묶어서 관리하자는 것으로 Namespace, cgroup 등 Linux의 여러 커널 기능들을 조합해서 만들어졌다.

- 대규모 컨테이너 오케스트레이션인 Kubernetes는 초기에 Docker의 영향을 많이 받았다, 초기 Docker는 하나의 완성된 컨테이너 사용자경험을 만드는데 집중하여 하나의 패키지에 API, CLI, Network, Storage 등 여러 기능을 담게 되었고, Docker에 의존하고 있던 Kubernetes는 Docker가 업데이트될 때마다 크게 영향을 받는 일이 빈번하게 발생하였다.

- 이러한 이유로 여러 집단에서 모여 OCI ( Open Container Initiative : 컨테이너 표준 )을 정하게 되었고, Docker에서 이러한 표준을 준수하는 containerd라는 Container Runtime을 만들고, Kubernetes에서는 OCI 포준을 준수하는 이미지를 실행할 수 있는 Container Runtime Interface (CRI) 스펙을 제공하여 Docker 버전과 무관하게 모든 컨테이너 이미즈를 실행가능한 환경을 제공할 수 있게 되었다.

- 컨테이너를 실행할 때 무거운 Docker Engine을 사용할 때가 가변운 Container Runtime인 containerd를 사용하면 Pod는 더 빨리 실행되고, CPU/Memory를 절약할 수 있게 된다. 하지만 이러한 장점이 있는 만큼 containerd를 사용하는 방법은 Docker에 비해 까다롭다. ==> 개발자 입장에서는 docker build만 사용하는 것으로 동일하나 kubernetes 인프라를 담당하는 사람은 runc, containerd, ctr 등 여러 라이브러리들을 익혀야한다.

- Kubernetes 1.23부터는 Container Runtime으로 Docker Engine의 지원이 중단되었다.

 

 

 

참고 : https://www.linkedin.com/pulse/containerd%EB%8A%94%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-sean-lee/?originalSubdomain=kr