Knowledge
컨테이너 오케스트레이션 기초 — 왜 필요한가
컨테이너 오케스트레이션이 해결하는 문제와 Kubernetes가 사실상 표준이 된 배경을 실무 관점에서 정리합니다.
Infrastructure · Architecture
컨테이너 오케스트레이션 기초
컨테이너를 하나 띄우는 것은 간단합니다. 하지만 수십 개의 컨테이너가 서로 통신하고, 장애 시 자동 복구되며, 트래픽에 따라 스케일링되어야 한다면 이야기가 달라집니다. 이것이 오케스트레이션이 필요한 이유입니다.
배포 모델은 어떻게 바뀌었나
전통적인 배포에서는 애플리케이션이 서버 위에서 바로 실행됩니다. 컨테이너를 쓰면 서버 위에 컨테이너 계층이 생기고, 그 안에서 애플리케이션이 동작합니다. Kubernetes에서는 Cluster → Node → Pod → Container 계층으로 애플리케이션을 배치합니다. 단계가 늘어나는 대신 표준화, 격리, 확장, 자동화가 쉬워집니다.
오케스트레이션이 해결하는 세 가지 문제
- 배포 자동화: 새 버전을 무중단으로 롤아웃하고, 문제가 생기면 즉시 롤백합니다.
- 서비스 디스커버리: 컨테이너 IP가 동적으로 바뀌는 환경에서 서비스 간 통신을 안정적으로 유지합니다.
- 자가 복구(Self-Healing): 컨테이너가 죽으면 자동으로 재시작하거나 다른 노드에 재배치합니다.
자가 복구의 전형적인 흐름은 다음과 같습니다.
- Pod Failure: 노드가 Pod가 비정상(크래시· readiness 실패 등)임을 감지합니다.
- Control Plane 감지: 컨트롤 플레인이 상태를 확인하고 새 Pod를 스케줄합니다.
- 새 Pod 생성: 다른 노드에 새 Pod가 기동되어 Ready 상태가 됩니다.
- Traffic 재연결: Service가 엔드포인트를 갱신해 트래픽을 정상 Pod로 보냅니다.
Kubernetes가 표준이 된 이유
Docker Swarm, Mesos 등 대안이 있었지만, CNCF 생태계와 클라우드 벤더의 매니지드 서비스(EKS, GKE, AKS) 지원이 결정적이었습니다. 운영 현장에서 Kubernetes를 선택하는 가장 실용적인 이유는 채용 시장에서 경험자를 찾기 가장 쉽기 때문입니다.
다음 단계
인프라 설계에서 "언제 Kubernetes를 도입하지 않아야 하는가"도 중요합니다. 소규모 서비스라면 단일 VM + Docker Compose로 충분한 경우가 많습니다.
