핵심 인사이트 (3줄 요약)
- 본질: 쿠버네티스(Kubernetes, K8s)는 컨테이너의 배포, 스케일링, 자가 치유(Self-Healing)를 자동화하는 오케스트레이션 플랫폼이며, 선언적(Declarative) 방식으로 '원하는 상태(Desired State)'를 명세한다.
- 가치: Pod → ReplicaSet → Deployment 계층 구조로 롤링 업데이트, 롤백, 오토스케일링을 코드 한 줄 없이 YAML 선언만으로 실현한다.
- 판단 포인트: K8s 운영 복잡성은 학습 비용과 맞바꾸는 것이므로, 소규모 서비스는 ECS나 Cloud Run 같은 매니지드 서비스가 더 적합할 수 있다.
Ⅰ. 개요 및 필요성
수백~수천 개의 컨테이너를 수동으로 관리하는 것은 불가능하다. 컨테이너가 죽으면 재시작해야 하고, 트래픽이 늘면 복제해야 하며, 업데이트 시 무중단을 보장해야 한다. 이 모든 자동화를 담당하는 플랫폼이 Kubernetes다.
K8s가 해결하는 핵심 문제:
-
자가 치유: 컨테이너 비정상 종료 시 자동 재시작, 노드 장애 시 다른 노드로 재배치
-
선언적 관리: YAML로 "원하는 상태"를 선언하면 K8s가 현재 상태를 그 상태로 지속 유지
-
서비스 디스커버리: Pod IP가 변경되어도 Service 오브젝트가 안정적인 엔드포인트 제공
-
오토스케일링: 부하에 따라 Pod 수를 자동으로 증감
-
📢 섹션 요약 비유: 쿠버네티스는 대형 물류 창고의 관리 시스템이다 — 박스(컨테이너)가 어디 있어야 하는지, 몇 개여야 하는지 자동으로 정리하고, 박스가 부서지면 새 박스를 즉시 보충한다.
Ⅱ. 아키텍처 및 핵심 원리
K8s 아키텍처:
┌──────────────────────────────────────────────────────────────┐
│ Control Plane (컨트롤 플레인) │
│ ┌───────────┐ ┌──────────┐ ┌──────────────────────────┐ │
│ │ API Server│ │ etcd │ │ Scheduler │ Ctrl Manager │ │
│ │(진입점/검증)│ │(분산 KV) │ │(배치 결정) │(상태 유지) │ │
│ └───────────┘ └──────────┘ └──────────────────────────┘ │
├──────────────────────────────────────────────────────────────┤
│ Data Plane (워커 노드) │
│ Node 1: [ Pod A ][ Pod B ] ← Kubelet + Kube-proxy │
│ Node 2: [ Pod C ][ Pod D ] ← Kubelet + Kube-proxy │
└──────────────────────────────────────────────────────────────┘
| 컴포넌트 | 역할 |
|---|---|
| API Server | 모든 요청의 진입점, 인증/인가, 검증 |
| etcd (분산 KV) | 클러스터 상태 저장소, 리더 선출 |
| Scheduler | 새 Pod를 어느 노드에 배치할지 결정 |
| Controller Manager | ReplicaSet 수 유지, Node 상태 감시 등 제어 루프 실행 |
| Kubelet | 노드의 에이전트, Pod 실행 및 상태 보고 |
| Kube-proxy | iptables/IPVS 기반 서비스 로드밸런싱 |
배포 오브젝트 계층:
- Pod: 1개 이상의 컨테이너 묶음, 동일 네트워크/스토리지 공유, 최소 배포 단위
- ReplicaSet: Pod 복제본 수 보장 (지정 수 미달 시 자동 생성)
- Deployment: ReplicaSet 롤링 업데이트, 롤백 관리
오토스케일링:
-
HPA(Horizontal Pod Autoscaler): CPU/메모리 기준 Pod 수 자동 증감
-
VPA(Vertical Pod Autoscaler): Pod의 CPU/메모리 할당량 자동 조정
-
KEDA(Kubernetes Event-Driven Autoscaling): 이벤트 기반(Queue 길이, HTTP 요청 수) 스케일링
-
📢 섹션 요약 비유: Deployment는 레스토랑 매니저다 — 주문이 몰리면 서빙 직원(Pod)을 더 부르고, 한가하면 줄이며, 직원이 쓰러지면 즉시 새 직원을 대기석에서 불러낸다.
Ⅲ. 비교 및 연결
서비스 유형(외부 접근 방법):
| 서비스 타입 | 접근 범위 | 사용 사례 |
|---|---|---|
| ClusterIP | 클러스터 내부만 | 마이크로서비스 간 통신 |
| NodePort | 노드 IP:포트 | 개발/테스트 환경 |
| LoadBalancer | 외부 로드밸런서 연동 | 프로덕션 외부 트래픽 |
| Ingress | HTTP 라우팅 규칙 | 멀티 서비스 단일 도메인 |
etcd(분산 KV): Raft 합의 알고리즘 기반, 홀수 개(3 또는 5) 노드로 HA 구성. 클러스터의 "두뇌 저장소" — 이 데이터가 손실되면 클러스터 전체 복구 불가.
- 📢 섹션 요약 비유: etcd는 회사의 인사 서류 창고다. 누가 어디 배치됐는지, 몇 명이 필요한지 기록한 문서가 타면 회사 전체가 혼란에 빠진다.
Ⅳ. 실무 적용 및 기술사 판단
기술사 시험 판단 포인트:
- 컨트롤 플레인과 데이터 플레인 분리를 그림과 함께 설명할 수 있어야 한다.
- HPA vs KEDA의 차이(메트릭 기반 vs 이벤트 기반 스케일링)를 명확히 구분한다.
- Pod 직접 생성을 지양하고 Deployment를 사용해야 하는 이유(자동 복구, 롤링 업데이트)를 논리적으로 기술한다.
실무 시나리오: 이커머스 플랫폼의 주문 서비스 배포 시 — Deployment(replicas: 3), HPA(CPU 70% 기준, max: 20), PodDisruptionBudget(PDB, 최소 2개 유지)을 함께 설정하여 정기 점검 중에도 서비스 무중단을 보장.
- 📢 섹션 요약 비유: PodDisruptionBudget은 공사 현장 안전 규정이다 — 건물(서비스)을 리모델링하는 동안에도 최소 몇 개의 방(Pod)은 항상 사용 가능하도록 보장한다.
Ⅴ. 기대효과 및 결론
Kubernetes 도입으로:
- 운영 자동화: 수동 재시작, 수동 스케일링 작업 90% 감소
- 배포 안전성: 롤링 업데이트로 무중단 배포, 이상 감지 시 자동 롤백
- 자원 효율: bin packing으로 노드 자원 활용률 극대화
- 이식성: EKS/AKS/GKE 어디서나 동일한 운영 경험
K8s는 클라우드 네이티브 생태계의 사실상 표준(De Facto Standard)이며, 서비스 메시, GitOps, 서버리스 프레임워크 모두 K8s를 기반으로 동작한다.
- 📢 섹션 요약 비유: Kubernetes는 컨테이너 세계의 '항공 관제탑'이다 — 수백 개의 비행기(컨테이너)가 충돌 없이 이착륙(배포/종료)할 수 있도록 전체 공역을 자동으로 조율한다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 도커 컨테이너 (Docker Container) | 이미지, Namespace, OCI · 501 |
| HPA (Horizontal Pod Autoscaler) | 오토스케일링, CPU 메트릭 · 503 |
| etcd (분산 KV 저장소) | Raft 합의, 클러스터 상태 · 506 |
| 서비스 메시 (Service Mesh) | Istio, 사이드카, mTLS · 505 |
| GitOps | ArgoCD, Flux, 선언적 배포 · 504 |
📈 관련 키워드 및 발전 흐름도
[이미지 · Namespace] → [쿠버네티스 Pod 오케스트레이션 배포] → [ArgoCD · Flux]
👶 어린이를 위한 3줄 비유 설명
- 쿠버네티스는 로봇 장난감 공장 관리자예요 — 로봇(컨테이너)이 몇 개 있어야 하는지 계속 확인하고, 부서진 게 있으면 새 로봇을 바로 만들어요.
- API 서버는 공장 정문이에요 — 모든 지시는 이 문을 통해서만 들어올 수 있어요.
- etcd는 공장 설계도 창고예요 — 이 창고가 불타면 공장 전체가 어떻게 돌아가야 할지 아무도 몰라요.