쿠버네티스(Kubernetes, 줄여서 K8s)는 여러 컨테이너를 여러 서버에 걸쳐 자동으로 배치·관리하는 컨테이너 오케스트레이션 도구다. 컨테이너 수가 늘고 서버가 여러 대로 흩어지면 일일이 손으로 띄우고 감시하기 어려운데, 쿠버네티스는 “원하는 상태(desired state)”만 정의해 두면 그 상태를 항상 유지하도록 컨테이너를 만들고 복구한다. 이 글에서는 쿠버네티스가 왜 필요한지부터 클러스터 구조(컨트롤 플레인·노드), 핵심 오브젝트(Pod·ReplicaSet·Deployment·Service 등), 그리고 전체 동작 흐름까지 입문자 기준으로 정리한다.
목차
쿠버네티스란 무엇인가
쿠버네티스는 컨테이너화된 애플리케이션의 배포·확장·운영을 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼이다. 여기서 오케스트레이션이란 여러 대의 컨테이너가 여러 대의 서버에 걸쳐 실행되는 상황을 한곳에서 통괄하고 관리하는 일을 말한다. 즉 흩어진 컨테이너들을 지휘하는 도구라고 보면 된다.
쿠버네티스는 도커 컴포즈 파일과 비슷한 매니페스트 파일(manifest)만 작성하면, 이 파일에 정의된 내용에 따라 여러 서버에 컨테이너를 생성하고 관리해 준다. 이 매니페스트에는 “컨테이너는 몇 개, 볼륨은 몇 개로 구성하라” 같은 바람직한 상태(desired state)가 기록된다.
그리고 이렇게 정의된 바람직한 상태를 만들고 항상 그 상태로 유지하는 것이 쿠버네티스의 기본 아이디어다. 어떤 컨테이너가 죽으면 쿠버네티스가 알아서 새 컨테이너를 띄워 정의된 수를 맞춘다.
쿠버네티스가 필요한 이유
컨테이너 하나를 단일 서버에서 돌리는 정도라면 도커만으로 충분하다. 하지만 서비스 규모가 커지면 상황이 달라진다. 수십~수백 개의 컨테이너가 여러 서버에 분산되고, 일부가 죽거나 트래픽이 몰릴 때 사람이 일일이 대응하기란 사실상 불가능하다. 쿠버네티스는 이런 운영 부담을 자동화로 해결한다.
- 자가 복구(self-healing) — 컨테이너나 노드가 죽으면 자동으로 다시 띄워 정의된 상태를 복원한다.
- 자동 스케일링 — 부하에 따라 컨테이너(Pod) 수를 늘리거나 줄인다.
- 로드 밸런싱·서비스 디스커버리 — 여러 컨테이너로 트래픽을 분산하고, 변하는 IP를 추상화한다.
- 무중단 배포·롤백 — 새 버전을 점진적으로 교체하고, 문제가 생기면 이전 버전으로 되돌린다.
- 선언적 관리 — 명령 절차가 아니라 “원하는 결과”만 정의하면 쿠버네티스가 그 상태로 수렴시킨다.
쿠버네티스 클러스터 구조
쿠버네티스는 전체를 제어하는 컨트롤 플레인(Control Plane)과, 실제 컨테이너가 동작하는 노드(Node, 워커 노드)로 구성된다. 이렇게 컨트롤 플레인과 노드가 모인 하나의 쿠버네티스 시스템 전체를 클러스터(Cluster)라고 부른다.
예전에는 컨트롤 플레인을 “마스터 노드”라고 불렀지만, 현재 공식 문서는 컨트롤 플레인이라는 용어를 사용한다. 컨트롤 플레인은 클러스터의 상태를 관리·결정하는 두뇌이고, 노드는 그 지시에 따라 실제 컨테이너를 실행하는 일꾼이다.
컨트롤 플레인 구성 요소
컨트롤 플레인은 클러스터 전체에 대한 결정을 내리고, 이벤트를 감지해 대응한다. 주요 구성 요소는 다음과 같다.
| 구성 요소 | 역할 |
|---|---|
| kube-apiserver | 쿠버네티스 HTTP API를 노출하는 핵심 창구. 모든 명령과 통신이 이곳을 거친다. |
| etcd | 클러스터의 모든 데이터를 저장하는 일관성·고가용성 키-값 저장소. |
| kube-scheduler | 아직 노드에 배정되지 않은 Pod를 찾아 적절한 노드에 할당한다. |
| kube-controller-manager | 여러 컨트롤러를 실행해 API에 정의된 동작(자가 복구 등)을 구현한다. |
| cloud-controller-manager (선택) | 클라우드 제공자와 연동하는 컨트롤러. 클라우드 환경에서만 사용한다. |
노드(워커 노드) 구성 요소
노드는 실제 컨테이너(Pod)가 동작하는 서버다. 컨트롤 플레인의 명령을 받아 컨테이너를 실행하고, 실행 환경을 유지한다. 모든 노드에는 다음 구성 요소가 설치된다.
| 구성 요소 | 역할 |
|---|---|
| kubelet | 노드에서 Pod와 그 안의 컨테이너가 정상 실행되도록 보장하는 에이전트. |
| kube-proxy (선택) | 노드의 네트워크 규칙을 관리해 Service 통신을 구현한다. |
| 컨테이너 런타임 | 실제로 컨테이너를 실행하는 소프트웨어(containerd, CRI-O 등). |
정리하면, 컨트롤 플레인이 “클러스터를 어떤 상태로 둘지”를 결정하면, 각 노드의 kubelet이 그 결정을 받아 컨테이너 런타임을 통해 실제 컨테이너를 실행한다.
쿠버네티스 핵심 오브젝트
쿠버네티스는 클러스터의 상태를 오브젝트(object)라는 단위로 표현한다. 매니페스트 파일에 어떤 오브젝트를 어떻게 둘지 정의하면, 쿠버네티스가 그 상태를 맞춰 준다. 입문 단계에서 꼭 알아야 할 핵심 오브젝트는 다음과 같다.
| 오브젝트 | 설명 |
|---|---|
| Pod | 배포 가능한 가장 작은 단위. 하나 이상의 컨테이너를 묶어 스토리지·네트워크를 공유한다. |
| ReplicaSet | 지정한 수의 동일한 Pod 복제본(레플리카)이 항상 실행되도록 유지한다. |
| Deployment | ReplicaSet을 관리하며 선언적 업데이트·롤아웃·롤백을 제공한다. |
| Service | 여러 Pod를 하나의 고정된 네트워크 엔드포인트로 노출한다. |
| Namespace | 하나의 클러스터 안에서 리소스를 논리적으로 격리·그룹화한다. |
| ConfigMap | 설정 데이터를 키-값으로 저장해 이미지와 설정을 분리한다. |
Pod — 가장 작은 배포 단위
Pod는 쿠버네티스가 생성·관리하는 가장 작은 배포 단위다. 하나의 Pod는 한 개 이상의 컨테이너와 그 컨테이너들이 공유하는 스토리지·네트워크 자원으로 구성된다. 가장 흔한 형태는 컨테이너 하나에 Pod 하나지만, 서로 강하게 결합된 컨테이너 여러 개를 한 Pod에 묶을 수도 있다. Pod는 일회성(ephemeral)으로 설계돼 있어, 보통 직접 만들지 않고 Deployment 같은 워크로드 리소스를 통해 생성한다.
ReplicaSet과 Deployment — 복제본과 배포 관리
ReplicaSet은 정의된 수만큼의 Pod 복제본이 항상 떠 있도록 보장한다. 장애로 Pod가 종료되면 모자란 만큼 새로 띄우고, 정의된 수를 3에서 2로 줄이면 실제 Pod 수도 줄인다. 이렇게 ReplicaSet이 관리하는 동일 구성의 Pod들을 레플리카(replica)라고 부른다.
다만 ReplicaSet은 보통 단독으로 쓰지 않고 Deployment를 통해 관리한다. Deployment는 Pod의 배포(deploy)를 관리하는 상위 오브젝트로, 어떤 이미지를 쓸지 등 Pod에 대한 정보를 갖고 있으며 내부에서 ReplicaSet을 정의한다. Deployment를 사용하면 새 버전을 점진적으로 교체하는 롤아웃, 문제 발생 시 이전 버전으로 되돌리는 롤백, 복제본 수 조정(스케일링)을 선언적으로 처리할 수 있다. 즉 Deployment → ReplicaSet → Pod의 계층으로 동작한다.
Service — 변하는 Pod를 고정 엔드포인트로
Pod는 죽고 새로 생기면서 IP가 계속 바뀐다. Service는 이런 Pod 집합을 하나의 안정적인 네트워크 엔드포인트로 노출하는 추상화다. 레이블 셀렉터(label selector)로 대상 Pod를 식별하며, Pod가 생기거나 사라져도 자동으로 추적해 연결을 유지한다. Service 타입에는 클러스터 내부 통신용 ClusterIP(기본값), 노드 포트로 외부 노출하는 NodePort, 클라우드 로드 밸런서와 연동하는 LoadBalancer, 외부 DNS 이름에 매핑하는 ExternalName이 있다.
외부에서 들어오는 요청은 LoadBalancer나 인그레스(Ingress)가 먼저 받아 적절한 Service로 분배하고, Service는 다시 자신이 관리하는 Pod들에 요청을 나눠 준다.
Namespace와 ConfigMap — 격리와 설정 분리
Namespace는 하나의 클러스터 안에서 리소스를 논리적으로 나누는 메커니즘이다. 같은 이름의 리소스라도 네임스페이스가 다르면 공존할 수 있어, 개발·스테이징·운영 환경을 분리하거나 팀별로 리소스를 격리할 때 유용하다. 쿠버네티스는 기본으로 default, kube-system, kube-public, kube-node-lease 네임스페이스를 제공한다.
ConfigMap은 기밀이 아닌 설정 데이터를 키-값 쌍으로 저장하는 오브젝트다. 환경별 설정을 컨테이너 이미지에서 분리해 두면, 같은 이미지를 환경에 따라 다른 설정으로 재사용할 수 있다. 단, 비밀번호·토큰 같은 민감 정보는 ConfigMap이 아니라 Secret 오브젝트에 저장해야 한다.
쿠버네티스 동작 흐름
지금까지의 구성 요소가 어떻게 맞물려 동작하는지, “Deployment로 Pod 3개 실행”이라는 매니페스트를 적용하는 과정을 따라가 보자.
- 요청 접수 — 사용자가
kubectl apply로 매니페스트를 제출하면 kube-apiserver가 받아 etcd에 “원하는 상태”를 저장한다. - 복제본 생성 — controller-manager의 Deployment·ReplicaSet 컨트롤러가 정의된 수(3개)만큼 Pod를 만들어야 한다고 판단한다.
- 스케줄링 — kube-scheduler가 아직 노드가 배정되지 않은 Pod들을 적절한 노드에 할당한다.
- 컨테이너 실행 — 해당 노드의 kubelet이 배정을 감지하고, 컨테이너 런타임에 지시해 실제 컨테이너를 띄운다.
- 네트워크 연결 — Service가 레이블로 이 Pod들을 묶고, kube-proxy가 네트워크 규칙을 설정해 트래픽이 분배되도록 한다.
- 상태 유지 — 이후 Pod 하나가 죽으면 ReplicaSet이 이를 감지해 새 Pod를 띄워 다시 3개를 맞춘다.
핵심은 사용자가 “어떻게 실행하라”는 절차가 아니라 “어떤 상태가 되어야 한다”만 선언하고, 나머지 수렴·복구는 쿠버네티스의 컨트롤러들이 자동으로 처리한다는 점이다.
자주 묻는 질문
쿠버네티스와 도커는 무엇이 다른가?
도커는 컨테이너를 만들고 실행하는 도구이고, 쿠버네티스는 그 컨테이너들을 여러 서버에 걸쳐 배치·관리하는 오케스트레이션 도구다. 둘은 경쟁 관계가 아니라 보완 관계로, 쿠버네티스는 내부에서 containerd 같은 컨테이너 런타임을 통해 컨테이너를 실행한다.
Pod와 컨테이너는 같은 것인가?
아니다. Pod는 쿠버네티스가 관리하는 가장 작은 단위이고, 컨테이너는 그 Pod 안에서 실행되는 실체다. 보통 Pod 하나에 컨테이너 하나지만, 한 Pod에 여러 컨테이너를 두고 스토리지·네트워크를 공유시킬 수도 있다.
왜 ReplicaSet을 직접 쓰지 않고 Deployment를 쓰나?
ReplicaSet만으로도 Pod 수는 유지되지만, 버전 교체(롤아웃)와 롤백 같은 배포 기능은 없다. Deployment가 ReplicaSet을 관리하면서 이런 배포 흐름을 선언적으로 제공하기 때문에, 실무에서는 Deployment를 통해 ReplicaSet을 간접적으로 사용한다.
정리
쿠버네티스는 컨테이너 오케스트레이션을 통해 “원하는 상태를 정의하면 항상 유지”하는 방식으로 동작한다. 클러스터는 결정을 내리는 컨트롤 플레인(kube-apiserver·etcd·scheduler·controller-manager)과 실제 컨테이너를 실행하는 노드(kubelet·kube-proxy·컨테이너 런타임)로 나뉜다. 그 위에서 Pod·ReplicaSet·Deployment·Service·Namespace·ConfigMap 같은 오브젝트로 애플리케이션을 표현하면, 쿠버네티스가 배치·복구·확장·노출을 자동으로 처리한다. 개념을 잡았다면, 다음 단계로 직접 미니쿠브(minikube)나 kind로 단일 노드 클러스터를 띄워 Deployment와 Service를 적용해 보며 동작 흐름을 눈으로 확인해 보길 권한다.
Reference
💬 댓글 0