“도커 이미 쓰고 있는데 쿠버네티스는 왜 또 배워야 하나요?” 스터디나 사내 교육에서 이 질문, 정말 자주 받습니다. 컨테이너 하나 띄우는 것과 그 컨테이너를 수백 개 안정적으로 운영하는 건 완전히 다른 차원의 문제거든요. 오늘은 쿠버네티스가 정확히 뭘 해결해주는 도구인지, 도커와는 어떤 관계인지부터 차근차근 정리해보겠습니다.
핵심 요약
1. 도커는 컨테이너를 “만들고 실행”하는 도구, 쿠버네티스는 그 컨테이너들을 대규모로 “관리하고 운영”하는 오케스트레이션 플랫폼입니다.
2. 쿠버네티스의 핵심 가치는 자동 복구(Self-healing), 자동 확장(Auto-scaling), 무중단 배포(Rolling Update)입니다.
3. 둘은 경쟁 관계가 아니라, 도커로 만든 컨테이너를 쿠버네티스가 관리하는 협업 관계입니다.
왜 컨테이너 하나로는 부족한가
도커로 컨테이너 하나 띄우는 건 사실 어렵지 않습니다. docker run 명령어 한 줄이면 끝나니까요. 문제는 서비스가 커지면서 시작됩니다. 트래픽이 몰리면 컨테이너를 더 띄워야 하고, 컨테이너 하나가 죽으면 누군가는 그걸 감지해서 다시 살려야 하고, 새 버전을 배포할 때는 서비스가 끊기지 않게 순차적으로 교체해야 하죠.
이걸 사람이 수동으로 하면 어떻게 될까요? 새벽에 컨테이너 하나 죽었다고 알람이 울리고, 담당자가 일어나서 SSH 접속해서 수동으로 재시작하는 상황이 반복됩니다. 컨테이너가 10개, 100개로 늘어나면 이 방식은 물리적으로 불가능해집니다. 쿠버네티스는 바로 이 “많은 컨테이너를 사람 손 없이 안정적으로 굴리는” 문제를 풀기 위해 구글 내부에서 쓰던 시스템(Borg)을 오픈소스화한 결과물입니다.
쿠버네티스가 실제로 하는 일
쿠버네티스를 한 문장으로 정의하면, “컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 플랫폼”입니다. 근데 이 정의만 봐서는 감이 잘 안 오죠. 실제로 쿠버네티스가 하는 일을 풀어보면 이렇습니다.
- 컨테이너가 죽으면 자동으로 새 컨테이너를 띄워서 대체합니다 (Self-healing)
- 트래픽이 늘면 컨테이너 개수를 자동으로 늘리고, 줄면 다시 줄입니다 (Auto-scaling)
- 새 버전 배포 시 기존 컨테이너를 순차적으로 하나씩 교체해서 서비스 중단 없이 업데이트합니다 (Rolling Update)
- 여러 서버(노드)에 컨테이너를 적절히 분산 배치해서 자원을 효율적으로 씁니다 (Scheduling)
이 모든 걸 사람이 명령어로 하나하나 지시하는 게 아니라, “이 상태를 유지해줘”라고 선언만 해두면 쿠버네티스가 알아서 그 상태를 맞춰줍니다. 이게 바로 쿠버네티스의 핵심 철학인 선언적 관리(Declarative Configuration)입니다.
핵심 개념 4가지만 먼저 이해하기
쿠버네티스 문서를 처음 열면 파드, 디플로이먼트, 서비스, 노드… 용어가 쏟아져서 압도당하기 쉬운데요, 입문 단계에서는 딱 4개만 확실히 이해하면 됩니다.
파드(Pod)
쿠버네티스에서 가장 작은 배포 단위입니다. 컨테이너 하나 또는 밀접하게 연관된 여러 컨테이너를 묶은 그룹이에요. 도커에서는 컨테이너 자체가 최소 단위였다면, 쿠버네티스에서는 이 파드가 최소 단위입니다. “왜 컨테이너를 바로 안 쓰고 파드로 감싸나” 궁금하실 텐데, 로그 수집용 사이드카 컨테이너처럼 메인 애플리케이션과 함께 항상 붙어 다녀야 하는 컨테이너들을 하나의 네트워크·스토리지 공간으로 묶기 위해서입니다.
디플로이먼트(Deployment)
“파드를 몇 개 유지할지, 어떤 이미지로 띄울지”를 선언하는 설정입니다. 디플로이먼트에 “이 이미지로 파드 3개를 항상 유지해줘”라고 적어두면, 파드 하나가 죽어도 쿠버네티스가 알아서 새 파드를 만들어서 3개를 맞춰줍니다.
서비스(Service)
파드는 죽었다 살아나면서 IP가 계속 바뀝니다. 이 상태에서 다른 애플리케이션이 파드에 접속하려면 고정된 접근 지점이 필요한데, 그게 바로 서비스입니다. 서비스는 파드들 앞에서 트래픽을 분산해주는 로드밸런서 겸 고정 주소 역할을 합니다.
노드(Node)
파드가 실제로 실행되는 물리 서버 또는 가상 머신입니다. 여러 노드가 모여서 하나의 클러스터를 구성하고, 쿠버네티스는 이 노드들 사이에서 파드를 어디에 배치할지 자동으로 결정합니다.
도커 vs 쿠버네티스, 정확한 관계
여기서 많은 분들이 헷갈리는 부분을 정리해볼게요. 도커와 쿠버네티스는 경쟁 제품이 아니라 역할이 다른 도구입니다.
| 구분 | 도커(Docker) | 쿠버네티스(Kubernetes) |
|---|---|---|
| 역할 | 컨테이너 이미지 생성 및 개별 실행 | 다수의 컨테이너 오케스트레이션(관리·확장·복구) |
| 다루는 단위 | 컨테이너 | 파드(컨테이너의 묶음) |
| 장애 대응 | 수동 재시작 필요 | 자동 감지 후 자동 재생성 |
| 확장 방식 | 수동으로 컨테이너 추가 실행 | 정책 기반 자동 확장(Auto-scaling) |
| 적합한 규모 | 단일 서버, 소규모 프로젝트, 로컬 개발 | 다수 서버에 걸친 대규모 프로덕션 환경 |
실무에서는 보통 도커(또는 containerd 같은 다른 컨테이너 런타임)로 애플리케이션을 이미지로 만들고, 그 이미지를 쿠버네티스가 클러스터 전체에 배포하고 관리하는 조합으로 씁니다. 참고로 최근 버전의 쿠버네티스는 도커 자체를 컨테이너 런타임으로 직접 쓰지 않고 containerd 같은 CRI(Container Runtime Interface) 호환 런타임을 사용합니다.
이 부분 때문에 “쿠버네티스가 도커를 버렸다”는 얘기가 나오는 건데, 정확히는 도커로 빌드한 이미지(OCI 표준 이미지)는 여전히 문제없이 쿠버네티스에서 실행됩니다. 이미지 빌드 도구로서의 도커와, 컨테이너 실행 런타임으로서의 도커 엔진을 구분해서 이해하시면 헷갈리지 않습니다.
쿠버네티스가 주는 진짜 장점
흔히 “쿠버네티스 쓰면 좋다”고들 하는데, 정확히 뭐가 좋은지 짚어보겠습니다.
무중단 배포가 가장 체감이 큽니다. 새 버전을 배포할 때 기존 파드를 하나씩 순서대로 교체하면서, 새 파드가 정상 동작하는 걸 확인한 뒤에야 다음 파드를 교체합니다. 중간에 문제가 생기면 자동으로 이전 버전으로 롤백할 수도 있고요.
자원 효율화도 중요합니다. 여러 노드에 걸쳐 파드를 적절히 분산 배치해서, 특정 서버만 과부하되고 다른 서버는 놀고 있는 상황을 줄여줍니다.
클라우드 이식성 역시 실무에서 크게 체감하는 부분입니다. AWS EKS, GCP GKE, Azure AKS 어디서든 동일한 YAML 설정 파일로 배포할 수 있어서, 특정 클라우드 벤더에 종속되는 위험을 줄여줍니다.
입문자가 자주 하는 착각
“쿠버네티스를 배우면 도커는 몰라도 된다” — 아닙니다. 쿠버네티스 위에서 돌아가는 이미지는 결국 도커(또는 유사 도구)로 빌드합니다. Dockerfile 작성법과 이미지 최적화는 여전히 필수 지식입니다.
“작은 프로젝트에도 쿠버네티스를 써야 최신 기술이다” — 트래픽이 적은 개인 프로젝트나 사이드 프로젝트에 쿠버네티스를 도입하면 오히려 관리 복잡도만 늘어납니다. 인터넷에 도는 “요즘은 다 쿠버네티스”라는 말만 믿고 무작정 도입했다가, 클러스터 관리 자체가 새로운 골칫거리가 되는 경우를 실무에서 꽤 봤습니다. 파드가 몇 개인지, 확장이 실제로 필요한 규모인지부터 따져보는 게 순서입니다.
“쿠버네티스만 있으면 장애가 안 난다” — 쿠버네티스는 컨테이너 레벨의 장애를 자동 복구해줄 뿐, 애플리케이션 로직 자체의 버그나 데이터베이스 병목 같은 문제는 여전히 사람이 해결해야 합니다.
결국 핵심은 ‘자동화’입니다
쿠버네티스를 처음 접할 때 가장 중요한 건 개별 명령어를 외우는 게 아니라, “왜 이 도구가 필요한가”라는 배경을 이해하는 것입니다. 결국 쿠버네티스는 사람이 수동으로 하던 반복적인 운영 작업(재시작, 확장, 배포)을 선언적으로 자동화해주는 도구라는 것, 이 한 문장만 확실히 이해하고 나면 나머지 개념들은 그 위에 자연스럽게 쌓입니다.
여러분은 실무나 사이드 프로젝트에서 쿠버네티스 도입을 고민해보신 적 있으신가요? 있다면 그 결정 기준이 무엇이었나요? 그리고 도커만으로 충분했던 경험이 있다면 어떤 규모의 프로젝트였는지 댓글로 공유해주시면 좋겠습니다.
이어서 읽으면 좋은 글로는 쿠버네티스 파드와 디플로이먼트 YAML 파일 실전 작성법, 도커파일(Dockerfile) 최적화로 이미지 용량 줄이는 5가지 방법을 준비하고 있습니다.