단일 도커 컨테이너에서 쿠버네티스 오케스트레이션 전환 시 네트워크·스토리지 오류 해결법
단일 서버에서 Docker 실행만으로 깔끔하게 돌아가던 웹 서비스가 트래픽 급증으로 다운되었을 때, 무작정 쿠버네티스를 도입했다가 Pod가 무한 재시작 상태에 빠져 주말 내내 밤을 새운 경험이 있습니다. 인터넷을 검색해 봐도 단순히 Docker Compose 파일을 K8s YAML로 변환하라는 일반론만 나올 뿐, 막상 배포하면 왜 로컬 이미지를 못 찾고 스토리지 연결이 터지는지 명확한 원인을 찾기 어렵습니다. 찾아보니 컨테이너 런타임과 오케스트레이션 엔진이 작동하는 레이어 자체가 달라서 발생하는 지점이 바로 여기인데요, 이 글에서는 Docker v29와 Kubernetes v1.36 최신 스펙을 기준으로 두 기술의 차이점과 마이그레이션 도중 발생하는 실무 오류 해결법을 확실히 정리해 드립니다. 단일 컨테이너(Docker)와 클러스터 오케스트레이션(Kubernetes)의 역할 차이 많은 개발자가 도커와 쿠버네티스를 하나를 선택하면 다른 하나를 버려야 하는 경쟁 관계처럼 오해하곤 합니다. 하지만 실무 측면에서 도커는 애플리케이션과 그 의존성을 하나의 이미지로 패키징하고 단일 호스트 노드에서 '컨테이너를 실행'하는 런타임 및 이미지 빌드 도구입니다. 반면 쿠버네티스는 수십~수천 대의 서버(노드 클러스터)를 하나의 거대한 컴퓨팅 자원으로 묶어, 그 위에서 실행되는 수백 개의 컨테이너를 배치하고, 노드 장애 시 자동 복구(Self-healing)하며, 트래픽에 맞춰 수평 확장(Auto-scaling)을 지휘하는 '오케스트레이터'입니다. 결국 두 기술은 대립하는 것이 아니라 쿠버네티스라는 지휘자가 도커 방식으로 만들어진 컨테이너라는 연주자들을 통제하는 상호 보완 구조입니다. Docker: 단일 서버 중심의 컨테이너 패키징, 빌드, 로컬 테스트, 이미지 표준 제공 Kubernetes: 다중 서버(클러스터) 환경에서의 자동 배포, 롤링 업데이트, 자가 치유, 로드밸런싱 전담 컨테이너 런타임 변화: 최신 쿠버네티스는 Docker Eng...