컨테이너는 “내 컴퓨터에서는 잘 되는데”라는 오래된 문제를 상당 부분 해결했습니다. 애플리케이션과 그 실행 환경을 하나의 이미지로 묶어 어디서든 동일하게 실행할 수 있게 되었으니까요. 그런데 컨테이너를 수십, 수백 개 운영하기 시작하면 새로운 질문들이 쏟아집니다.
- 트래픽이 몰리면 컨테이너를 누가, 어떻게 늘려주나?
- 컨테이너가 죽으면 누가 다시 띄워주나?
- 새 버전을 배포하다 문제가 생기면 어떻게 되돌리나?
- 수십 개의 컨테이너가 서로를 어떻게 찾고 통신하나?
쿠버네티스(Kubernetes)는 이런 컨테이너 운영을 자동화하는 플랫폼입니다. 여러 서버에 컨테이너를 배치하고, 문제가 생기면 다시 실행하며, 필요한 수만큼 늘리고 줄이는 일을 맡습니다. 이를 컨테이너 오케스트레이션이라고 합니다.
컨테이너가 많아지면 무엇이 어려울까?
컨테이너 한두 개는 사람이 손으로 관리할 수 있습니다. 하지만 규모가 커지면 수동 운영은 곧 한계에 부딪힙니다. 컨테이너 운영에서 반복적으로 마주치는 과제와, 수동 방식의 한계를 비교하면 다음과 같습니다.
| 운영 과제 | 수동/스크립트 방식의 한계 |
|---|---|
| 스케일링 | 트래픽 변화에 맞춰 사람이 직접 컨테이너 수를 늘리고 줄여야 함 |
| 장애 복구 | 컨테이너·서버가 죽으면 누군가 감지하고 다시 띄워야 함 |
| 배포 | 무중단 배포·롤백을 매번 직접 스크립트로 구현 |
| 서비스 디스커버리 | 컨테이너 IP가 계속 바뀌어 통신 대상을 추적하기 어려움 |
| 부하 분산 | 여러 컨테이너로 들어오는 트래픽을 직접 분배 |
| 리소스 배치 | 어떤 서버에 어떤 컨테이너를 올릴지 사람이 판단 |
쿠버네티스에서는 실행 순서를 하나씩 명령하기보다 원하는 상태를 적습니다. 예를 들어 “컨테이너를 3개 실행한다”라고 선언하면, 쿠버네티스는 실제 상태가 이 목표와 같아지도록 계속 확인하고 조치합니다. 이 방식을 선언적 구성이라고 하며, 컨트롤러(Controller)가 확인과 조치를 반복합니다.
flowchart LR
A["원하는 상태 선언<br/>(YAML 매니페스트)"] --> B["API Server"]
B --> C{"현재 상태 =<br/>원하는 상태?"}
C -- 다름 --> D["조치<br/>생성 · 교체 · 스케일"]
D --> C
C -- 같음 --> E["그대로 유지"]
쿠버네티스가 해 주는 일
공식 개요 문서가 설명하는 쿠버네티스의 대표 특성을 정리하면 다음과 같습니다.
| 특성 | 설명 |
|---|---|
| 선언적 구성 | 명령 절차가 아닌 “원하는 상태”를 YAML로 선언 → 시스템이 알아서 수렴 |
| 자동 복구(self-healing) | 죽은 컨테이너 재시작, 응답 없는 컨테이너 교체, 헬스체크 통과 전 트래픽 차단 |
| 수평 확장 | 명령 한 줄 또는 오토스케일러로 컨테이너 수 자동 조절 |
| 서비스 디스커버리 / 로드밸런싱 | Service가 안정적인 이름·가상 IP를 제공하고 트래픽을 분산 |
| 자동 롤아웃 / 롤백 | Deployment로 점진적 배포, 문제 시 이전 버전으로 복귀 |
| 자동 배치 | 컨테이너가 요청한 CPU와 메모리에 맞춰 스케줄러가 적절한 Node를 선택 |
| 확장성 | 커스텀 리소스(CRD)와 오퍼레이터로 기능을 직접 확장 |
여기서 확장성은 쿠버네티스에 새로운 종류의 리소스와 자동화 규칙을 추가할 수 있다는 뜻입니다. CRD와 오퍼레이터를 이용하면 기본 기능에 없는 운영 작업도 Kubernetes API를 통해 관리할 수 있습니다.
쿠버네티스와 함께 쓰는 도구
쿠버네티스는 CNCF(Cloud Native Computing Foundation)가 관리하는 오픈소스 프로젝트이며, 그 주변에는 표준 인터페이스(CRI·CNI·CSI)를 중심으로 수많은 도구가 모여 있습니다. 쿠버네티스 스스로는 “핵심”만 담당하고, 나머지는 표준에 맞춘 컴포넌트가 끼워지는 구조입니다.
flowchart TB
subgraph CORE["쿠버네티스 코어"]
API["API Server"]
SCH["Scheduler"]
CM["Controller Manager"]
end
CORE -->|CRI| RT["컨테이너 런타임<br/>containerd · CRI-O"]
CORE -->|CNI| NET["네트워킹<br/>Calico · Cilium"]
CORE -->|CSI| STO["스토리지<br/>CSI 드라이버"]
CORE -. 확장 .-> EXT["Helm · Argo CD<br/>Prometheus · Istio"]
| 레이어 | 역할 | 대표 도구 |
|---|---|---|
| 컨테이너 런타임 | 실제 컨테이너 실행 (CRI 표준) | containerd, CRI-O |
| 네트워킹 | Pod 간 네트워크 (CNI 표준) | Calico, Cilium |
| 스토리지 | 영속 볼륨 연결 (CSI 표준) | 각 클라우드/스토리지 드라이버 |
| 패키징 | 애플리케이션 배포 패키지 | Helm |
| GitOps / 배포 | Git을 단일 소스로 한 지속 배포 | Argo CD, Flux |
| 관측성(Observability) | 메트릭·모니터링 | Prometheus |
| 서비스 메시 | 서비스 간 통신 제어·관측 | Istio, Linkerd |
| 배포판 / 매니지드 | 설치·운영 부담 완화 | EKS, GKE, AKS, k3s |
즉 쿠버네티스는 모든 기능을 혼자 제공하지 않습니다. 공통 인터페이스에 맞는 네트워크, 스토리지, 배포 도구를 환경에 맞게 골라 함께 사용합니다.
기존 운영 방식과 비교하기
쿠버네티스를 도입하면 개별 서버에 접속해 작업하기보다, 클러스터에 원하는 상태를 선언하고 결과를 확인하는 방식으로 운영이 바뀝니다.
| 영역 | 기존 방식 | 쿠버네티스 도입 후 |
|---|---|---|
| 배포 | 서버에 접속해 수동/스크립트로 갱신 | 선언적 매니페스트 적용 → 자동 반영 |
| 스케일링 | VM·서버를 수동 증설 | 선언 또는 오토스케일러로 자동 |
| 장애 복구 | 알림 받고 사람이 재기동 | self-healing으로 자동 재시작·교체 |
| 서버 관리 | 개별 서버에 접속해 직접 관리 | 클러스터가 여러 서버를 묶어 관리 |
| 환경 이동 | 환경마다 배포 방식을 따로 구성 | 공통 Kubernetes API를 쓰되 환경별 차이는 별도 설정 |
| 릴리스 | 다운타임·수동 롤백 | 롤링 업데이트·즉시 롤백 |
결과적으로 운영자는 “어떻게(how) 할지”를 일일이 지시하는 대신 “무엇을(what) 원하는지”를 선언하고, 반복적이고 실수가 잦던 운영 작업의 상당 부분을 플랫폼에 위임하게 됩니다.
핵심 정리
쿠버네티스는 컨테이너를 대규모로, 안정적으로, 선언적으로 운영하기 위한 플랫폼입니다. 자동 복구·확장·배포·서비스 디스커버리를 기본으로 제공하고, CRD와 오퍼레이터로 확장 가능하며, CNCF 생태계의 표준 위에서 동작합니다.
다만 쿠버네티스가 만능은 아닙니다. 강력한 만큼 학습 곡선과 운영 복잡성이라는 비용이 따르므로, 작은 서비스에는 과한 선택일 수 있습니다. “왜 필요한지”를 먼저 이해하고 도입하는 것이 중요한 이유입니다.
이 글은 큰 그림을 빠르게 훑는 입문 글입니다. 이후 글에서는 클러스터 아키텍처(Control Plane과 Node), Pod와 워크로드 컨트롤러, 네트워킹·스토리지 등을 하나씩 깊이 들여다보겠습니다.
참고: 이 글의 모든 개념은 쿠버네티스 공식 문서를 1차 출처로 작성했습니다.