1. Rolling Update
개요
Kubernetes의 기본 배포 전략으로, 기존 Pod를 점진적으로 교체하면서 새 버전을 배포합니다.
설정 예시
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
실무 포인트
- maxUnavailable=0: 기존 Pod가 모두 살아있는 상태에서 새 Pod가 올라오도록 설정 → 무중단 보장
- maxSurge=1: 새 Pod를 하나씩 추가하여 점진적으로 교체
- readinessProbe가 성공해야 트래픽을 받음 → 트래픽 안정성 확보
주의사항
- readinessProbe가 없으면 새 Pod가 준비되지 않은 상태에서 트래픽을 받을 수 있음
- StatefulSet에는 RollingUpdate가 제한적 → 별도 전략 필요
2. Blue-Green / Canary 배포
개요
새 버전의 서비스를 기존과 병렬로 배포하여 트래픽을 점진적으로 전환하거나, 테스트 후 전면 전환하는 전략
구현 방식
- Blue-Green: 두 개의 환경(Blue: 현재, Green: 새 버전)을 운영 → 전환 시점에 전체 트래픽 이동
- Canary: 일부 트래픽만 새 버전으로 보내고, 점진적으로 비율 증가
실무 도구
- Istio / Linkerd: 서비스 메쉬 기반 트래픽 분할
- Azure DevOps / GitHub Actions: 배포 파이프라인 자동화
- Flagger: Canary 배포 자동화 도구 (Istio, NGINX 등과 연동)
예시 (Istio VirtualService)
http:
- route:
- destination:
host: my-service
subset: v1
weight: 90
- destination:
host: my-service
subset: v2
weight: 10
주의사항
- Canary 배포 시 모니터링 필수 (에러율, 응답시간 등)
- Blue-Green은 리소스 이중화로 비용 증가 가능
3. Auto Healing
개요
서비스 장애 발생 시 자동으로 복구되도록 설정하여 무중단 운영을 지원
핵심 기능
- Liveness Probe: 컨테이너가 죽었는지 확인 → 실패 시 재시작
- Readiness Probe: 컨테이너가 트래픽 받을 준비가 되었는지 확인 → 실패 시 트래픽 차단
- Horizontal Pod Autoscaler (HPA): CPU/메모리/Custom Metric 기반 자동 스케일링
설정 예시
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
주의사항
- Probe 경로는 실제 서비스 상태를 반영해야 함
- HPA는 Pod 수 증가만 가능 → Pod 수 감소 시에도 안정성 확보 필요
참고
