Kubernetes Without Docker Is the Future — Are You Ready?

도커는 이제 쿠버네티스에서 제외됐습니다 — 그 의미와 당신이 준비해야 할 것들을 알아보세요.

수년간 Docker와 Kubernetes는 컨테이너 세계의 대표적인 듀오였습니다. 튜토리얼, 부트캠프, DevOps 파이프라인 어디에서든 둘은 떼려야 뗄 수 없는 존재였죠.

그러나 많은 사람들을 놀라게 한 변화가 있었습니다. Kubernetes는 1.20 버전부터 Docker를 컨테이너 런타임으로 더 이상 권장하지 않으며, 결국 공식 지원을 완전히 중단했습니다.

여기서 중요한 점은, Kubernetes가 컨테이너 자체를 버린 것이 아니라 Docker를 버린 것이라는 사실입니다. 이건 전혀 다른 이야기입니다.

이 변화는 많은 개발자들을 혼란스럽게 했고, 일부 팀에서는 혼란과 불안감마저 일으켰습니다.

이제 이 변화가 정확히 어떤 의미인지, 그리고 왜 이것이 컨테이너 오케스트레이션의 미래에 오히려 긍정적인 변화인지 알아보겠습니다.

---

먼저, 오해부터 풀고 갑시다

“쿠버네티스가 도커를 제거한다”는 말을 들으면 많은 사람들이 이렇게 생각합니다:

“그럼 이제 쿠버네티스에서 도커 컨테이너를 실행할 수 없는 건가요?”

그건 사실이 아닙니다.

쿠버네티스는 여전히 도커 이미지(Docker images)를 문제없이 실행할 수 있습니다.

도커 이미지는 OCI(Open Container Initiative) 표준을 따르며,

쿠버네티스는 OCI 호환 이미지를 실행할 수 있는 어떤 컨테이너 런타임도 지원합니다.

이번 변경 사항은 이미지에 관한 것이 아니라, 런타임에 관한 이야기입니다.

---

Docker와 containerd: 무엇이 다른가요?

사실 Docker 자체도 내부적으로는 containerd를 사용합니다.

containerd는 이미지 다운로드, 컨테이너 생성, 스토리지 관리 등을 담당하는 가볍고 효율적인 컨테이너 런타임입니다.

즉, 우리가 docker run 명령어를 실행하면, Docker는 실제로 뒤에서 containerd를 호출하고 있는 셈입니다.

Kubernetes는 이 과정에서 중간 단계를 없애기로 한 것입니다.

기존에는 Docker → containerd → Linux의 흐름이었다면, 이제는 Kubernetes가 containerd와 직접 통신하게 됩니다.

그 결과는?

불필요한 오버헤드 감소, 더 나은 성능, 그리고 장기적인 유지관리 측면에서의 이점이 생깁니다.

---

Kubernetes가 이 결정을 내린 이유

이번 아키텍처 변경에는 다음과 같은 주요 배경이 있습니다:

1. Docker는 CRI(컨테이너 런타임 인터페이스) 호환 런타임이 아니다

Kubernetes는 컨테이너 런타임과 통신하기 위해 CRI(Container Runtime Interface)라는 플러그인 인터페이스를 사용합니다.

하지만 Docker는 CRI를 직접 지원하지 않기 때문에, Kubernetes와 연결하려면 dockershim이라는 중간 계층(shim layer)이 필요했습니다.

이 dockershim을 유지보수하는 일은 복잡하고 불안정했으며, 결국 Kubernetes 팀은 이렇게 선언했습니다: “더 이상 유지하지 않겠습니다.”

2. containerd는 오케스트레이션을 위해 설계된 런타임이다

Docker와 달리, containerd는 처음부터 프로덕션 환경의 오케스트레이션을 염두에 두고 설계되었습니다.

더 가볍고 빠르며, Docker CLI나 이미지 빌더, 데스크탑 도구 같은 불필요한 기능이 포함되지 않아 Kubernetes와의 통합에 훨씬 적합합니다.

3. 더 깔끔하고 단순한 아키텍처

Docker를 생략함으로써 Kubernetes 컨트롤 플레인에서의 계층 구조와 의존성을 줄일 수 있습니다. 그 결과, 클러스터는 더 예측 가능하고, 문제 발생 시 디버깅도 훨씬 쉬워집니다.

---

개발자인 당신에게 영향이 있을까요?

당신이 만약 아래 작업을 하고 있다면:

• Docker를 사용해 이미지를 빌드하고,
• 레지스트리(예: Docker Hub, ECR 등)에 이미지를 푸시하며,
• 그 이미지를 Kubernetes에 배포하고 있다면,

걱정하지 않으셔도 됩니다. 아무것도 깨지지 않습니다.

Dockerfile을 다시 작성할 필요도 없고,

다른 이미지 포맷으로 전환할 필요도 없습니다.

하지만 몇 가지 측면에서는 이번 변경이 영향을 줄 수 있습니다.

---

바꿔야 할 수도 있는 것들

1. 로깅 및 디버깅 방식

많은 개발자들이 docker logs, docker exec 같은 Docker CLI 명령어를 디버깅에 활용합니다.

하지만 containerd는 기본적으로 그런 친숙한 CLI를 제공하지 않습니다.

이제는 crictl, ctr 같은 대체 도구들을 사용해야 하며,

이들 도구는 새롭게 학습이 필요합니다.

2. CI/CD 파이프라인

일부 커스텀 CI/CD 파이프라인은 Kubernetes 노드 내부에서 Docker를 실행해 이미지를 빌드하거나 특정 부작용을 유발하는 방식에 의존하고 있을 수 있습니다.

하지만 이제는 노드에 Docker가 설치되어 있지 않기 때문에 그런 방식은 더 이상 동작하지 않습니다.

✅ 해결책:

Docker가 없어도 Kubernetes 내에서 이미지를 빌드할 수 있는 Kaniko, BuildKit, img 같은 도구를 사용하는 것입니다.

3. 로컬 개발 환경

Minikube나 kind(Kubernetes IN Docker)를 사용 중이라면,

이미지를 빌드하고 로드하는 방식에 변화가 생겼음을 느낄 수 있습니다.

이러한 툴들은 빠르게 최신화되고 있지만,

지금 사용하는 환경이 잘 작동하는지 한 번 더 점검해보는 것이 좋습니다.

---

개발 워크플로우를 미래 지향적으로 만들기 위한 팁

앞으로 변화에 앞서 나가고 싶다면, 아래와 같은 방식들을 도입해보세요:

✅ OCI 호환 이미지 빌더 사용하기:

BuildKit, Kaniko, img는 Docker 없이도 이미지를 빌드할 수 있습니다.

✅ containerd 기초 익히기:

특히 crictl은 Kubernetes 노드에서 컨테이너를 직접 다룰 때 유용합니다.

✅ Docker-in-Docker 방식 피하기:

편리해 보여도 매우 불안정한 방식입니다.

가능하면 컨테이너 친화적인 대안을 사용하는 것이 좋습니다.

✅ Kubernetes 릴리스 노트 주기적으로 확인하기:

특히 런타임 인터페이스(CRI)와 관련된 변경 사항을 챙겨보세요.

---

마무리

Kubernetes가 Docker 지원을 중단한 것은 Docker의 끝이 아니라,

대규모 컨테이너 실행 방식의 진화라고 볼 수 있습니다.

오히려 이번 변화는 우리를 더 가볍고, 표준화되고, 프로덕션 중심적인 컨테이너 워크플로우로 이끌고 있습니다.

Docker는 여전히 로컬 개발과 이미지 빌드에 훌륭한 도구입니다.

하지만 오케스트레이션의 미래는 containerd와 CRI 호환 런타임에게 있습니다.

그러니, 도커 없는 쿠버네티스는 곧 현실이자 미래입니다.

진짜 중요한 질문은 이것이겠죠, 당신은 그 미래를 맞이할 준비가 되어 있나요?

요약과 추가로 공부하면 좋은 개념들

---

🐳 Kubernetes Without Docker Is the Future — 요약본

📌 핵심 요약

• Kubernetes는 1.20부터 Docker 런타임을 deprecated, 현재는 완전히 제거됨
• 그러나 Docker 이미지 사용은 계속 가능 (OCI 표준 준수)
• 변경된 것은 이미지 런타임(runtime) 방식, 이미지 포맷은 그대로

---

🔍 왜 Kubernetes가 Docker를 제외했나?

1. Docker는 CRI 호환 런타임이 아님
   • Kubernetes는 CRI(Container Runtime Interface)를 통해 런타임과 통신
   • Docker는 CRI를 지원하지 않아 중간 계층 dockershim이 필요했음 → 유지보수가 복잡
2. containerd는 오케스트레이션에 최적화
   • Docker 내부에서도 사용하는 경량 런타임
   • CLI, 데스크탑 등 불필요한 요소 없음
3. 더 단순하고 예측 가능한 아키텍처
   • 중간 계층 제거로 디버깅과 유지보수가 쉬워짐

---

👨‍💻 개발자가 바꿔야 할 수 있는 부분

항목	영향	대체 방법
Docker CLI 기반 디버깅	docker logs, docker exec 사용 불가	crictl, ctr 학습
CI/CD 파이프라인에서 Docker 사용	노드 내 Docker 필요 시 작동 안 함	Kaniko, BuildKit, img 사용
로컬 Kubernetes 환경	Minikube, kind 설정 변화 가능성	구성 확인 및 최신화 필요

---

✅ 미래지향적 워크플로우 추천

• 이미지 빌더: BuildKit, Kaniko, img
• 런타임 도구: crictl, ctr
• 안티패턴 피하기: Docker-in-Docker는 불안정 → 대체 도구 사용
• 릴리스 노트 주기적 확인: Kubernetes의 CRI 관련 변경사항 파악

---

📘 추가로 공부하면 좋은 개념들

주제	설명
🔹 CRI(Container Runtime Interface)	Kubernetes와 런타임 사이의 인터페이스. CRI 이해는 필수
🔹 containerd vs Docker 차이	런타임 계층 구조 및 역할 비교
🔹 crictl / ctr 명령어	디버깅 및 컨테이너 제어를 위한 CLI 도구
🔹 Kaniko / BuildKit 사용법	Docker 없는 환경에서 이미지 빌드하는 방법
🔹 kind, Minikube 설정 구조	로컬 개발환경에서 이미지 로딩 방식 변경 이해

---