쿠버네티스는 여러 서버에 컨테이너를 배치하고, 죽으면 다시 띄우고, 트래픽에 맞춰 복제 수를 조절하는 컨테이너 오케스트레이션(container orchestration) 시스템이다. 사람이 하던 서버 운영을 "원하는 상태를 선언하면 계속 맞춰 주는" 제어 루프(control loop)로 자동화한다.
선언형과 재조정(reconciliation)
"Pod를 하나 띄워라"가 아니라 "이 앱은 항상 3개 떠 있어야 한다"를 YAML로 선언한다. 컨트롤러가 현재 상태와 선언한 상태를 끊임없이 비교해 차이를 메운다. React가 선언한 UI에 맞춰 DOM을 고치는 재조정과 같은 멘탈 모델이다(선언형과 명령형 프로그래밍).
핵심 오브젝트
- Pod: 배포의 최소 단위. 보통 컨테이너 하나(때로 보조 컨테이너 포함)
- Deployment: Pod 템플릿과 복제 수(
replicas)를 선언한다. 롤링 업데이트(rolling update)와 롤백을 맡는다 - Service: 라벨로 고른 Pod 묶음 앞의 고정 이름·주소. Pod IP가 바뀌어도 Service로 접속하면 알아서 분배된다
- Ingress: 도메인·경로에 따라 외부 요청을 Service로 보내는 라우팅 규칙
- Namespace: dev·qa·prod처럼 리소스를 나누는 단위
apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
replicas: 3
selector: { matchLabels: { app: web } }
template:
metadata: { labels: { app: web } }
spec:
containers:
- name: web
image: registry.example.com/web:1.2.0
ports: [{ containerPort: 3000 }]
resources:
requests: { memory: 256Mi, cpu: 250m }
limits: { memory: 512Mi, cpu: 500m }자동으로 해 주는 것
- 자가 치유(self-healing): Pod가 죽으면 새로 띄워 개수를 맞춘다
- 롤링 업데이트·롤백: 새 버전으로 하나씩 교체해 무중단 배포, 문제가 생기면 이전 ReplicaSet으로 되돌린다
- 오토스케일링(autoscaling): 지표에 따라 Pod 수를 늘리고 줄인다(수직 확장과 수평 확장)
requests는 스케줄링 때 보장받는 양,limits는 상한이다. 메모리 limit을 넘으면 컨테이너가 강제 종료된다(OOMKilled, Out Of Memory)
kubectl apply -f로 선언을 반영하고, 그 선언을 git에서 자동 동기화하면 GitOps가 된다. 전제가 되는 컨테이너는 컨테이너와 이미지, 실제 디버깅 명령은 kubectl 디버깅 치트시트을 본다.
출처: Kubernetes 개요 · Deployment: 롤링 업데이트 · Service · requests와 limits