Containerd란?

Overview

오늘은 Containerd에 대해 학습하며, Docker에서 분리된 컨테이너 런타임으로서의 Containerd의 역할과
Kubernetes와의 연결 구조, 그리고 OCI(Open Container Initiative)와의 관계 등을 정리해보았다.

 

 

특히, Docker의 복잡성과 종속성 문제를 해결하기 위해 어떻게 Containerd가 등장했는지,
그리고 Kubernetes에서는 어떻게 OCI 기반의 컨테이너 런타임을 지원하게 되었는지를 통해 컨테이너 생태계의 발전 과정을 이해할 수 있었다.

 

 

 

 

---

 

 

 

 

 

Containerd 등장 배경

• 초기 Docker는 엔진 하나로 모든 기능(CLI, API, Network, Storage, Runtime)을 포함한 복합 구조였음.
• Kubernetes는 Docker에 의존하고 있었고, Docker 버전 변화에 따라 문제가 발생하곤 했음.
• 이에 따라 표준화된 인터페이스(OCI, CRI) 필요성이 대두됨.

출처 :https://blog.siner.io/2021/10/23/container-ecosystem/

 

 

 

 

Open Container Initiative (OCI)

• Docker를 포함한 여러 기술 집단이 컨테이너의 이미지 및 실행 방식에 대한 공통 표준을 만들기 위해 구성.
• 주요 표준
  • OCI Runtime Spec
  • OCI Image Spec

 

 

 

 

Containerd란?

• Docker가 만든 컨테이너 런타임
• OCI Runtime Spec을 구현하는 경량 런타임으로, Docker의 하위 레이어를 독립시킨 구조.
• Docker는 현재도 내부적으로 containerd를 사용하고 있으며, containerd → runc로 이어지는 구조를 가진다.

 

 

Kubernetes에서의 활용

• Kubernetes는 v1.5부터 **CRI(Container Runtime Interface)**를 도입하여
  Docker에 직접 의존하지 않고, 표준 인터페이스를 통해 containerd 등 다양한 런타임과 연결 가능하게 되었음.
• Kubernetes에서는 CRI를 지원하는 containerd를 사용하여 직접 Pod 실행이 가능하다.

 

 

 

Containerd의 구조 (요약)

[ Kubernetes ]
     │
[ CRI Shim (containerd-shim-runc-v2) ]
     │
[ containerd ]
     │
[ runc ]
     │
[ Linux Kernel (Namespaces, Cgroups, etc.) ]

 

• containerd-shim: Pod 단위의 실행 컨텍스트를 유지하며, containerd와 runc 사이에서 실행 역할 담당
• runc: 실제로 컨테이너를 실행하는 표준 런타임 (OCI Runtime)

 

 

 

 

 

 

---

 

 

 

 

마무리 

Containerd는 컨테이너 기술의 표준화, 경량화, 독립성 확보라는 관점에서 중요한 전환점을 만들어준 런타임이다.

Docker에서 containerd를 분리하면서 런타임 계층이 모듈화되었고, Kubernetes에서도 특정 런타임에 종속되지 않는 구조가 가능해졌다.

 

현재는 Docker 없이도 Kubernetes에서 containerd를 통해 직접 컨테이너 실행이 가능한 시대이며,

이를 통해 더 안정적이고 유연한 클러스터 환경 구성이 가능하다.

즉, Kubernetes 환경에서 더 이상 Docker가 필수는 아니다.
중요한 건 OCI 기반 컨테이너 이미지와 이를 실행할 수 있는 Runtime(containerd, CRI-O 등)이다.

 

 

 

 

 

 

 

 

 

---

 

 

 

 

Reference

https://github.com/containerd/containerd/blob/main/docs/getting-started.md