Kubernetes에서 Docker가 사라진 이유와 Podman의 부상

최근 Kubernetes 환경에서 Docker 대신 Podman을 사용하는 사례가 늘어나고 있다. 이는 단순한 트렌드가 아니라, Kubernetes의 구조적 변화와 운영 효율성에 대한 깊은 고민이 반영된 결과다. (Docker의 부분 유료화도 ..! 💸)

이 글에서는 Docker가 Kubernetes에서 제외된 이유, Podman의 구조적 장점, 그리고 두 도구의 철학적 차이와 실무적 활용 차이를 설명한다.

📖 용어 정리

---

🐳 Docker와 Kubernetes의 결별

❓ 왜 Kubernetes에서 Docker가 제외됐을까?

Kubernetes는 1.20부터 Docker 지원 종료 예정을 발표했고, 1.24부터는 공식적으로 Docker 런타임을 제거했다. 이 결정은 많은 사람들에게 충격이었지만, 기술적으로는 매우 타당한 변화였다.

이유: Kubernetes는 CRI 기반, Docker는 CRI를 직접 지원하지 않음

• Kubernetes는 컨테이너 런타임과의 통신을 CRI(Container Runtime Interface) 라는 표준으로 처리한다.
• Docker는 CRI를 직접 지원하지 않고, dockershim이라는 중간 계층을 통해 연동됐다.
• 이 중간 계층은 유지보수가 어렵고 비표준적이기 때문에 Kubernetes 커뮤니티는 dockershim을 제거하기로 결정한 것.

요약 : Docker 자체가 싫어서가 아니라, 비표준 중간 계층을 제거하기 위해서 Docker 런타임을 제외한 것이다.

---

그럼 대체 런타임은?

런타임	특징
containerd	Docker에서 분리된 핵심 런타임. 가장 널리 사용됨
CRI-O	OpenShift, Red Hat 기반에서 채택한 경량 런타임
Podman	Daemonless, Rootless, CLI 기반. 개발 환경에서 강력

Kubernetes 클러스터에서는 대부분 containerd 또는 CRI-O를 사용한다. 하지만 개발과 운영의 중간 단계에서 Podman이 매우 강력한 도구로 자리 잡고 있다.

---

Docker vs Podman: 구조적 차이

🔥 핵심 정리

Docker는 데몬(dockerd)에게 REST API로 명령을 위임하는 방식이고,
Podman은 CLI에서 직접 명령을 수행하는 방식이다.

항목	Docker	Podman
구조	Client ↔ dockerd (daemon)	단일 실행 프로세스 (daemonless)
실행 방식	REST API로 데몬에게 위임	명령어가 바로 runc 호출
데몬 필요 여부	✅ 필수	❌ 필요 없음
rootless 지원	❌ 기본 root 데몬 사용	✅ 일반 사용자로도 실행 가능
상태 관리 방식	데몬 메모리에 상태 저장	파일 기반 상태 저장 (/var/lib/...)
보안 측면	데몬이 root 권한을 요구	보안 우수 (사용자 권한 격리)
컨테이너 실행 방식	docker run → 데몬이 실행	podman run → 직접 실행

---

데몬의 역할과 Podman의 설계 철학

🐳 Docker의 데몬(dockerd)은 무슨 일을 할까?

• 모든 CLI 명령은 실제로 REST API 요청으로 변환되어 dockerd에 전달된다.
• dockerd는 이미지 관리, 컨테이너 생성/중지, 상태 추적, 네트워크 설정 등을 총괄한다.
• 모든 컨테이너 상태는 데몬 메모리에서 유지되므로, dockerd가 죽으면 모든 것이 위험해진다.

Podman은 어떻게 가능한가?

• Podman은 데몬 없이 CLI가 직접 runc를 호출한다.
• 상태 추적은 파일 기반으로 처리되며, 명령 실행 시 lock 파일 등을 활용해 충돌이나 데드락을 방지한다.
• systemd와의 통합으로 컨테이너 상태 복원도 가능하다.

데몬이 없지만, 더 안전하고 유연한 구조로 실행이 가능하다.

---

데드락? 충돌? daemonless는 위험하지 않나?

Podman은 다음 방식으로 데드락이나 리소스 충돌 없이 동작한다:

1. 파일 시스템 기반 상태 관리 (containers/storage)
2. lock 파일을 통한 충돌 방지
3. atomic 명령 실행: 실행 중인 컨테이너에 동시에 명령이 들어올 경우 대기 또는 실패 처리
4. systemd 통합 가능: podman generate systemd, podman play kube로 복구 가능

🔐 Podman은 daemon이 없어도 안정성과 동시성 제어를 완벽하게 처리할 수 있는 구조다.

---

Kubernetes와 Podman의 실제 관계

❓ Kubernetes에서 Podman을 런타임으로 직접 쓰는가?
❌ 아니요, Kubernetes는 containerd 또는 CRI-O만 사용한다.

그러나 Podman은 다음과 같은 방식으로 Kubernetes와 매우 잘 통합된다:

• podman build → OCI 호환 이미지 생성 → ECR 등에 푸시 → Kubernetes에서 그대로 사용
• podman generate kube → Kubernetes YAML 자동 생성
• podman play kube → 로컬에서 K8s 배포 테스트

Github Action을 사용한다면, .github/workflows/ 디렉토리 아래에 yaml파일에 docker을 대신하여 podman으로 빌드하고 푸시하도록 하면 된다.

---

🖥️ 실무에서의 Podman 활용 사례

• 개발 환경에서 Docker를 완전히 대체
• CI 환경에서 rootless로 이미지 빌드
• 보안이 중요한 시스템에서 데몬 없는 구조로 운영
• Kubernetes 배포 전에 로컬 테스트 자동화

---

마무리

Kubernetes에서 Docker는 사라졌지만, 컨테이너의 시대는 끝나지 않았다.
Podman은 Docker의 뒤를 이을 차세대 개발/운영 도구로서 점점 더 많은 관심을 받고 있으며, 특히 보안성, 유연성, 표준 호환성 측면에서 강력한 대안이 되고 있다.

‼️이제 컨테이너의 미래는, 데몬이 없는 세상에서 더욱 빠르고 안전하게 진화하고 있다.

---

🔗 참고

• Kubernetes 공식 dockershim 제거 안내
• Podman 공식 문서
• containerd vs Docker vs Podman 비교

용어 정리

---

🐳 Docker Engine

컨테이너를 쉽게 다룰 수 있게 만들어주는 컨테이너 플랫폼의 진입점

• 개발자가 사용하는 명령어(docker run, docker build 등)를 처리하는 전체 시스템
• CLI와 데몬(dockerd), 이미지/컨테이너 관리 기능들을 포함하는 포괄적 용어
• 사용자가 명령을 내리면 실제 컨테이너 실행은 내부적으로 containerd와 runC가 수행

📌 즉, Docker Engine은 컨테이너 플랫폼의 프론트엔드 역할이다.

---

😈 dockerd

Docker의 데몬 프로세스

• Docker Engine의 핵심 구성요소로, 백그라운드에서 항상 실행됨
• docker CLI가 명령을 내리면, dockerd가 이를 받아 실행
• 실제 컨테이너 실행은 containerd에게 위임

📌 dockerd는 Docker 시스템의 지휘자로, 실행 흐름을 조율한다.

---

⚙️ containerd

컨테이너의 실행을 책임지는 고성능 런타임 관리자

• Docker에서 분리된 독립 런타임 관리 시스템
• 컨테이너 이미지 다운로드, 저장, 압축 해제
• 컨테이너 파일 시스템 구성
• runC를 호출해 실제 컨테이너를 시작함
• Kubernetes에서도 표준 런타임(back-end) 으로 채택됨

📌 containerd는 컨테이너 실행을 위한 핵심 실행 관리자이다.

---

🚀 runC

컨테이너를 실제로 실행하는 리눅스 프로그램

• OCI(Open Container Initiative) 표준 런타임
• cgroup, namespace를 설정해 격리된 환경 구성
• 컨테이너 내부에서 프로세스가 실제로 실행되도록 함

📌 runC는 배우가 무대에 오르는 것처럼 컨테이너 프로세스를 실행하는 주체다.

---

🧱 CRI-O

Kubernetes 전용 컨테이너 런타임

• Kubernetes의 표준 런타임 인터페이스(CRI)를 구현
• Docker 없이 K8s에서 직접 컨테이너를 실행하기 위한 경량 런타임
• 내부적으로 runC를 사용

📌 CRI-O는 Kubernetes 전용의 가볍고 효율적인 런타임 대체제

---

🧠 namespace (리눅스 커널)

컨테이너 간 격리를 구현하는 리눅스 커널 기술

• 프로세스, 네트워크, 사용자, 파일 시스템 등 보이는 세계를 분리
• 종류:
  • pid: 프로세스 번호 분리
  • net: 네트워크 인터페이스 격리
  • mnt: 파일시스템 마운트 격리
  • uts: 호스트명 격리
  • ipc: 공유 메모리 격리
  • user: 사용자/권한 격리

📌 namespace는 컨테이너끼리 서로 다른 우주에 살게 해주는 기술

---

⚖️ cgroup (control group)

컨테이너 리소스를 제한·관리하는 리눅스 커널 기술

• 컨테이너마다 CPU, 메모리, 디스크 I/O 등을 얼마나 사용할 수 있는지 제한
• 자원 사용량을 추적하거나, 초과 시 종료 처리도 가능

cgroup은 각 컨테이너에 얼마만큼의 파워를 쓸 수 있는지 정해주는 안전벨트

---