컨테이너는 “내 컴퓨터에서는 잘 되는데”라는 오래된 문제를 상당 부분 해결했습니다. 애플리케이션과 그 실행 환경을 하나의 이미지로 묶어 어디서든 동일하게 실행할 수 있게 되었으니까요. 그런데 컨테이너를 수십, 수백 개 운영하기 시작하면 새로운 질문들이 쏟아집니다.
- 트래픽이 몰리면 컨테이너를 누가, 어떻게 늘려주나?
- 컨테이너가 죽으면 누가 다시 띄워주나?
- 새 버전을 배포하다 문제가 생기면 어떻게 되돌리나?
- 수십 개의 컨테이너가 서로를 어떻게 찾고 통신하나?
쿠버네티스(Kubernetes)는 바로 이 “컨테이너를 운영하는 문제”를 풀기 위한 컨테이너 오케스트레이션 플랫폼입니다.
왜 쿠버네티스가 필요한가
컨테이너 한두 개는 사람이 손으로 관리할 수 있습니다. 하지만 규모가 커지면 수동 운영은 곧 한계에 부딪힙니다. 컨테이너 운영에서 반복적으로 마주치는 과제와, 수동 방식의 한계를 비교하면 다음과 같습니다.
| 운영 과제 | 수동/스크립트 방식의 한계 |
|---|---|
| 스케일링 | 트래픽 변화에 맞춰 사람이 직접 컨테이너 수를 늘리고 줄여야 함 |
| 장애 복구 | 컨테이너·서버가 죽으면 누군가 감지하고 다시 띄워야 함 |
| 배포 | 무중단 배포·롤백을 매번 직접 스크립트로 구현 |
| 서비스 디스커버리 | 컨테이너 IP가 계속 바뀌어 통신 대상을 추적하기 어려움 |
| 부하 분산 | 여러 컨테이너로 들어오는 트래픽을 직접 분배 |
| 리소스 배치 | 어떤 서버에 어떤 컨테이너를 올릴지 사람이 판단 |
쿠버네티스는 이 과제들을 선언적(declarative) 으로 다룹니다. “컨테이너를 3개 띄우고, CPU가 부족하면 자동으로 늘려라”처럼 원하는 상태(desired state) 만 선언하면, 쿠버네티스가 현재 상태를 그 목표로 끊임없이 수렴시킵니다. 이 수렴을 담당하는 것이 컨트롤러(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로 점진적 배포, 문제 시 이전 버전으로 복귀 |
| 자동 빈 패킹(bin packing) | 컨테이너의 리소스 요구에 맞춰 스케줄러가 적절한 노드에 배치 |
| 확장성 | 커스텀 리소스(CRD)와 오퍼레이터로 기능을 직접 확장 |
여기서 특히 중요한 건 확장성입니다. 쿠버네티스는 “정해진 기능을 쓰는 제품”이 아니라, CRD와 오퍼레이터를 통해 나만의 리소스와 자동화 로직을 추가할 수 있는 플랫폼입니다. 이 점이 거대한 에코시스템을 만들어냈습니다.
쿠버네티스 에코시스템
쿠버네티스는 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 |
즉, 쿠버네티스를 도입한다는 것은 단일 제품을 쓰는 게 아니라 표준 위에 쌓인 생태계를 활용한다는 의미에 가깝습니다.
기존 방식에서 무엇이 바뀌는가
쿠버네티스 도입의 본질은 운영 패러다임의 전환입니다. 서버를 하나하나 이름 붙여 애지중지 관리하던 방식(“pet”)에서, 언제든 교체 가능한 균질한 자원으로 다루는 방식(“cattle”)으로 사고가 바뀝니다. 구체적으로 비교하면 다음과 같습니다.
| 영역 | 기존 방식 | 쿠버네티스 도입 후 |
|---|---|---|
| 배포 | 서버에 접속해 수동/스크립트로 갱신 | 선언적 매니페스트 적용 → 자동 반영 |
| 스케일링 | VM·서버를 수동 증설 | 선언 또는 오토스케일러로 자동 |
| 장애 복구 | 알림 받고 사람이 재기동 | self-healing으로 자동 재시작·교체 |
| 서버 관리 | 개별 서버를 직접 관리(pet) | 클러스터가 자원을 추상화(cattle) |
| 환경 이식성 | 환경마다 설정·동작 상이 | 동일 매니페스트로 어디서나 동일 |
| 릴리스 | 다운타임·수동 롤백 | 롤링 업데이트·즉시 롤백 |
결과적으로 운영자는 “어떻게(how) 할지”를 일일이 지시하는 대신 “무엇을(what) 원하는지”를 선언하고, 반복적이고 실수가 잦던 운영 작업의 상당 부분을 플랫폼에 위임하게 됩니다.
마치며
쿠버네티스는 컨테이너를 대규모로, 안정적으로, 선언적으로 운영하기 위한 플랫폼입니다. 자동 복구·확장·배포·서비스 디스커버리를 기본으로 제공하고, CRD와 오퍼레이터로 확장 가능하며, CNCF 생태계의 표준 위에서 동작합니다.
다만 쿠버네티스가 만능은 아닙니다. 강력한 만큼 학습 곡선과 운영 복잡성이라는 비용이 따르므로, 작은 서비스에는 과한 선택일 수 있습니다. “왜 필요한지”를 먼저 이해하고 도입하는 것이 중요한 이유입니다.
이 글은 큰 그림을 빠르게 훑는 입문 글입니다. 이후 글에서는 클러스터 아키텍처(Control Plane과 Node), Pod와 워크로드 컨트롤러, 네트워킹·스토리지 등을 하나씩 깊이 들여다보겠습니다.
참고: 이 글의 모든 개념은 쿠버네티스 공식 문서를 1차 출처로 작성했습니다.