Docker vs containerd 정리

Kubernetes에서 컨테이너 런타임이 바뀐 이유 ??

Kubernetes를 처음 학습하다 보면 “예전에는 Docker를 썼다는데, 왜 요즘은 containerd를 쓰는지”
혼란스러울 수 있습니다.

이 글에서는 Docker → containerd로 변화한 흐름과 함께 CRI, OCI, ctr, nerdctl, crictl까지 기본 개념을 정리합니다.

 

---

1. Kubernetes와 컨테이너 런타임의 관계

Kubernetes는 컨테이너를 직접 실행하는 도구가 아닙니다.
컨테이너를 어디서, 몇 개, 어떤 상태로 실행할지 관리하는 오케스트레이터입니다.

실제로 컨테이너를 실행하는 역할은 컨테이너 런타임(Container Runtime) 이 담당합니다.

구조는 다음과 같습니다.

• Kubernetes(kubelet) → 컨테이너 런타임 → 컨테이너 실행

---

2. 초기 Kubernetes에서 Docker를 사용했던 이유

초기 Kubernetes 환경에서는 Docker가 사실상 표준처럼 사용되었습니다.

그 이유는 Docker가 다음과 같은 기능을 한 번에 제공했기 때문입니다.

• 컨테이너 이미지 빌드
• 이미지 다운로드 및 업로드
• 컨테이너 실행 및 관리
• 네트워크, 볼륨 등 부가 기능

Kubernetes는 “컨테이너 실행”이 필요했고,
Docker가 이를 이미 잘 수행하고 있었기 때문에 자연스럽게 함께 사용되었습니다.

---

3. Kubernetes 입장에서 Docker의 한계

문제는 Docker가 컨테이너 실행 외의 기능까지 너무 많이 포함하고 있다는 점이었습니다.

Kubernetes가 런타임에게 요구하는 기능은 단순합니다.

• 이미지 가져오기
• 컨테이너 실행 / 중지 / 상태 확인

하지만 Docker는 “런타임”이라기보다 종합 컨테이너 플랫폼에 가까웠습니다.

또, 하나의 중요한 문제는
Docker가 Kubernetes 표준 인터페이스인 CRI를 직접 지원하지 않았다는 점입니다.

---

4. OCI와 CRI 개념 정리

OCI (Open Container Initiative)

• 컨테이너 이미지와 런타임의 표준 규격
• 특정 기술(Docker)에 종속되지 않도록 하기 위한 목적
• 현재 Docker 이미지도 OCI 규격을 따릅니다

CRI (Container Runtime Interface)

• Kubernetes(kubelet)와 컨테이너 런타임 사이의 표준 통신 규약
• kubelet은 CRI를 통해 런타임에 명령을 전달합니다

즉,

• OCI는 “컨테이너 표준”
• CRI는 “Kubernetes와 런타임 사이의 약속”이라고 이해하시면 됩니다.

---

5. dockershim과 Docker 지원 중단

Docker가 CRI를 직접 지원하지 않았기 때문에 Kubernetes는 dockershim이라는 중간 계층을 사용했습니다.

구조는 다음과 같았습니다.

• kubelet → dockershim → Docker → containerd → runc

이 구조는 계층이 많고 유지보수가 어려웠습니다.
결국 Kubernetes는 다음과 같은 결정을 내립니다.

• Docker를 직접 사용하지 않는다
• 대신 Docker 내부에서 이미 사용 중이던 containerd를 직접 사용한다

이로 인해 Kubernetes v1.24부터 dockershim이 완전히 제거되었습니다.

---

6. containerd란 무엇인가요?

containerd는 컨테이너 실행에 필요한 핵심 기능만 제공하는 런타임입니다.

특징은 다음과 같습니다.

• Docker에서 분리된 독립 프로젝트
• Kubernetes와 CRI로 직접 연동
• 구조가 단순하고 안정적
• 운영 환경에 적합

 

현재 Kubernetes 환경에서는
Docker 없이 containerd만 설치해도 정상적으로 클러스터를 운영할 수 있습니다.

---

7. Docker가 없어도 Kubernetes를 사용할 수 있나요?

네, 가능합니다.

• Kubernetes는 Docker가 필수가 아닙니다
• containerd 또는 CRI-O만 있으면 충분합니다
• 실제 운영 환경에서는 containerd 단독 구성이 일반적입니다

Docker 이미지는 OCI 규격을 따르기 때문에
containerd 환경에서도 그대로 사용할 수 있습니다.

---

8. containerd 관련 CLI 도구 정리

containerd 환경에서는 목적에 따라 서로 다른 CLI 도구를 사용합니다.

ctr

• containerd 기본 CLI
• 저수준 도구
• 디버깅 및 내부 확인 목적
• 실사용에는 불편

nerdctl

• Docker와 거의 동일한 사용 경험 제공
• containerd 기반
• 실습 및 운영에 적합
• Docker 대체 용도로 가장 많이 사용

crictl

• Kubernetes(CRI) 디버깅 전용 CLI
• kubelet 기준의 실제 상태 확인
• Pod 장애 분석 시 필수 도구

---

9. crictl이 중요한 이유

Kubernetes는 Docker 기준으로 동작하지 않고
CRI 기준으로 컨테이너 상태를 관리합니다.

따라서 장애 상황에서

• docker ps → 의미 없는 경우가 많음
• crictl ps → kubelet이 인식하는 실제 상태 확인 가능

CKA 시험과 실무 환경 모두에서
crictl 사용 능력은 매우 중요합니다.

10. A note on Docker deprecation

Kubernetes에서 Docker가 완전히 사라진 것은 아닙니다.
다만, Kubernetes가 Docker 엔진을 직접 사용하던 방식(dockershim) 이 더 이상 필요하지 않게 되었을 뿐입니다.

 

Kubernetes v1.24부터 dockershim이 제거되었고, 대신 containerd나 CRI-O 같은 CRI 호환 런타임을 직접 사용합니다.

중요한 점은 Docker 이미지 자체는 OCI 표준을 따르기 때문에 containerd 환경에서도 그대로 사용 가능하다는 것입니다.

 

즉, Docker는 “지원 종료”가 아니라
Kubernetes 내부 구조에서의 역할이 변경된 것으로 이해하시면 됩니다.

---

11. 핵심 요약

• Kubernetes는 컨테이너를 직접 실행하지 않음
• Docker는 과거에 사용되었지만 현재는 필수 아님
• Kubernetes는 containerd를 직접 사용
• 실습/운영: nerdctl
• 장애 분석: crictl
• 내부 확인: ctr

Docker를 아는 것도 중요하지만,
Kubernetes 환경에서는 containerd와 crictl 이해가 더 중요합니다.