쿠버네티스와 도커 차이, 파드와 오케스트레이션
쿠버네티스는 여러 서버의 컨테이너를 자동으로 배포·관리하는 오픈소스 도구다. 도커와의 차이, 컨트롤 플레인과 워커 노드로 나뉜 구조, 파드 개념, 모니터링·보안, 리눅스 기초부터 책·교육·자격증까지 학습 경로를 짚었다.
목차
쿠버네티스는 여러 서버에 흩어진 컨테이너를 자동으로 배포하고 관리해 주는 오픈소스 도구다. 컨테이너 하나를 만들어 실행하는 일이 도커의 몫이라면, 그렇게 만든 컨테이너 수십 개를 어느 서버에 몇 개나 띄울지 정하고 죽으면 다시 살리는 일이 쿠버네티스의 몫이다. 그래서 실무에서는 보통 도커로 이미지를 만들고, 쿠버네티스로 그 이미지를 여러 서버에 배포해 운영한다.
쿠버네티스와 도커는 무엇이 다른가
둘은 경쟁 상대가 아니라 역할이 다른 도구다. 도커는 컨테이너(애플리케이션과 실행 환경을 한 덩어리로 묶어 어디서나 같은 방식으로 돌아가게 만든 실행 단위)를 만들고 하나씩 실행한다. 쿠버네티스는 이렇게 만든 컨테이너를 여러 서버에 나눠 배치하고, 부하에 따라 개수를 늘리거나 줄이며, 장애가 나면 다시 띄우는 일을 맡는다. 이처럼 여러 컨테이너를 조율해 운영하는 일을 오케스트레이션이라고 부른다. 실제로 쿠버네티스 공식 블로그는 1.24 버전(2022년 5월)에서 도커 엔진 전용 연결 계층인 dockershim을 제거했다고 발표했는데, 그 뒤로도 도커로 빌드한 이미지는 표준 규격(OCI)을 따르기 때문에 containerd 같은 다른 런타임에서 그대로 돌아간다 — 이미지를 만드는 도구와 굴리는 도구가 그만큼 분리돼 있다는 뜻이다.
| 구분 | 도커 | 쿠버네티스 |
|---|---|---|
| 맡는 일 | 이미지 빌드, 컨테이너 실행 | 여러 컨테이너의 배치·복구·확장 |
| 동작 범위 | 서버 한 대 | 여러 서버를 묶은 클러스터 |
| 대표 명령 | docker build, docker run | kubectl apply, kubectl get pods |
서버 한 대에서 컨테이너 몇 개만 돌린다면 도커만으로도 충분하다. 하지만 사용자가 늘어 서버가 여러 대로 불어나면 어느 서버에 무엇을 띄웠는지 사람이 일일이 챙기기 어렵다. 쿠버네티스는 이 관리 부담을 대신 지도록 설계됐다. 구글이 사내에서 쓰던 컨테이너 운영 방식을 바탕으로 2014년 6월 공개했고, 1.0 버전을 내놓은 2015년 7월부터는 그때 설립된 클라우드 네이티브 컴퓨팅 재단(CNCF)이 관리한다. 반대로 서버 관리 자체를 클라우드에 맡겨 버리는 갈래가 궁금하다면 서버리스 아키텍처 글에서 다뤘다.
쿠버네티스 구조는 어떻게 이루어져 있나
쿠버네티스는 명령을 내리는 컨트롤 플레인과 실제 컨테이너가 도는 워커 노드로 나뉜 구조다. 이 둘을 묶은 전체를 클러스터라고 한다. 컨트롤 플레인은 클러스터의 두뇌 역할을 하며, 어떤 컨테이너를 어느 노드에 배치할지 결정하고 전체 상태를 원하는 모습으로 유지한다. 쿠버네티스 공식 문서 기준으로 컨트롤 플레인은 명령 창구인 API 서버(kube-apiserver), 클러스터 상태를 기록하는 저장소(etcd), 새 파드를 어느 노드에 둘지 고르는 스케줄러(kube-scheduler), 선언된 상태와 실제를 맞추는 컨트롤러 매니저(kube-controller-manager)로 구성되고, 각 워커 노드에서는 kubelet이 이 지시를 받아 컨테이너를 실제로 띄운다.
워커 노드는 실제로 일을 하는 서버다. 개발자가 '이 애플리케이션을 세 개 띄워라'라고 선언하면, 컨트롤 플레인이 노드들에 골고루 배치하고 하나가 죽으면 빈자리를 채운다. 사람이 상태를 일일이 맞추는 대신, 원하는 상태를 적어 두면 시스템이 알아서 그 상태로 수렴시키는 방식이다. 이 선언형 운영이 쿠버네티스를 이해하는 핵심 열쇠에 가깝다.
선언 3 · 실제 3 — 원하는 상태와 실제 상태가 일치한다. 슬라이더로 선언을 바꾸거나 파드(✕)를 눌러 죽여 보자.
파드는 컨테이너와 무엇이 다른가
파드는 쿠버네티스가 컨테이너를 다루는 가장 작은 단위다. 쿠버네티스는 컨테이너를 직접 다루지 않고 파드라는 껍데기로 한 번 감싸서 관리한다. 파드 하나에는 보통 컨테이너 하나가 들어가지만, 로그 수집기처럼 늘 함께 움직여야 하는 보조 컨테이너를 같은 파드에 묶기도 한다.
같은 파드 안의 컨테이너들은 네트워크와 저장 공간을 공유한다. 그래서 서로 가까이 붙어 동작해야 하는 것들을 한 파드로 묶는다. 파드는 언제든 사라지고 새로 뜰 수 있는 일회용에 가깝다. 그래서 실무에서는 파드를 직접 만들기보다 디플로이먼트 같은 상위 개념으로 '파드를 몇 개 유지하라'고 선언해 두는 편이 안전하다.
파드 정의는 어떻게 생겼나
파드는 YAML 매니페스트로 선언한다. 엔진엑스 컨테이너 하나를 담은 최소 예시는 이렇다.
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80
kubectl 명령으로 적용하고 상태를 살핀다.
kubectl apply -f nginx-pod.yaml
kubectl get pods
kubectl describe pod nginx-pod
앞서 말했듯 실무에서는 파드를 직접 만들기보다 디플로이먼트로 감싸 선언하지만, 쿠버네티스가 다루는 최소 단위의 생김새를 눈으로 익히는 데는 파드 정의만 한 것이 없다. 매니페스트의 각 필드 의미는 쿠버네티스 공식 문서(한국어)에 정리돼 있다.
운영에서는 모니터링과 보안을 어떻게 챙기나
컨테이너가 많아질수록 지금 무엇이 어떻게 돌고 있는지 눈으로 보는 일이 중요해진다. 그래서 운영 단계에서는 모니터링이 빠질 수 없다. 각 파드가 쓰는 자원과 응답 상태를 모아 대시보드로 보여 주고, 문제가 생기면 알림을 주도록 구성하는 것이 일반적이다. 지표 수집은 프로메테우스, 대시보드는 그라파나를 붙이는 조합이 대표적인데, CNCF는 2018년 8월 프로메테우스를 쿠버네티스에 이어 두 번째 졸업 프로젝트로 승격했다고 발표했다 — 쿠버네티스와 같은 재단이 성숙도를 검증한 도구라는 뜻이다. 도구를 갖추기 전이라도 메트릭 서버만 설치하면 kubectl top pods 한 줄로 파드별 CPU·메모리 사용량을 확인할 수 있다.
보안도 처음부터 함께 설계하는 편이 낫다. 컨테이너에 필요 이상의 권한을 주지 않고(역할 기반 접근 제어, RBAC), 서비스끼리 오가는 통신을 최소한으로 제한하며(네트워크 정책, NetworkPolicy), 비밀번호나 인증 키 같은 민감한 값은 코드가 아니라 별도의 보관 수단(시크릿, Secret)에 둔다 — 세 가지 모두 쿠버네티스가 내장 기능으로 제공한다. 규모가 커진 뒤에 보안을 덧붙이기는 훨씬 번거롭다.
쿠버네티스 학습은 어디서부터 시작하나
먼저 리눅스와 컨테이너의 기초를 다지는 편이 빠르다. 쿠버네티스는 주로 리눅스 위에서 돌아가고 컨테이너 자체가 리눅스 기술을 바탕에 두고 있어서, 명령어와 프로세스·네트워크 개념에 익숙하면 이후 학습이 한결 수월하다. 도커로 컨테이너를 직접 만들어 보는 경험을 먼저 쌓는 것도 도움이 된다. 실습 환경은 쿠버네티스 공식 튜토리얼이 안내하는 minikube면 충분하다 — minikube start 한 줄이면 노트북에 단일 노드 클러스터가 뜬다. 여러 컨테이너를 설정 파일 하나로 묶어 보는 도커 컴포즈 네트워크 구성까지 해 보면 쿠버네티스의 네트워크 개념도 한결 수월하게 잡힌다.
이론과 실습을 함께 가려면 입문용 책 한 권을 정해 처음부터 끝까지 따라 해 보는 방법이 무난하다. 온라인 교육 과정이나 공식 문서의 튜토리얼을 병행하면 개념과 손이 함께 는다. 실력을 객관적으로 확인하고 싶다면 자격증도 선택지다. 관리자용 CKA와 개발자용 CKAD 같은 인증이 대표적이다. 리눅스 재단과 CNCF가 함께 만든 이 시험들은 실제 클러스터에서 과제 15~20개를 2시간 안에 명령줄로 푸는 실기 방식이다. 다만 자격증은 목표라기보다, 작은 클러스터를 직접 굴려 보며 익힌 감각을 정리하는 이정표로 삼는 편이 오래 남는다.