Kubernetes 롤링 업데이트와 롤백 안전하게 하는 법

kubectl set image로 새 버전을 올렸는데 절반쯤 배포되다가 새 Pod가 전부 CrashLoopBackOff에 빠진 적 있을 겁니다. 쿠버네티스의 기본 배포 전략인 롤링 업데이트는 구버전 Pod를 한 번에 죽이지 않고 새 Pod를 조금씩 띄우며 교체합니다. 핵심은 "얼마나 빠르게 바꿀지"와 "터졌을 때 얼마나 빨리 되돌릴지"를 미리 정해두는 것입니다.

롤링 업데이트가 실제로 하는 일

Deployment는 새 ReplicaSet을 만들고, 구 ReplicaSet의 Pod를 하나씩 줄이면서 새 것을 하나씩 늘립니다. 이 속도를 두 값이 제어합니다.

maxUnavailable: 0으로 두면 항상 정상 Pod 수를 유지하므로 무중단에 가깝고, maxSurge를 키우면 교체가 빨라지지만 순간 자원 사용량이 늘어납니다.

1단계 — 전략 명시

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  minReadySeconds: 10

minReadySeconds는 새 Pod가 Ready가 된 뒤에도 이 시간만큼 안정적이어야 다음 교체로 넘어가게 해, 기동 직후 죽는 Pod가 전체로 번지는 것을 늦춰줍니다.

2단계 — 배포와 진행 확인

kubectl set image deployment/web web=myapp:v2
kubectl rollout status deployment/web    # 완료까지 블로킹 대기

rollout status는 모든 Pod가 새 버전으로 Ready가 될 때까지 기다렸다가 성공/실패를 알려줍니다. CI 파이프라인에서 이 명령의 종료 코드로 배포 성공을 판정하면 좋습니다.

3단계 — 실패하면 즉시 롤백

새 버전이 안 뜨면 망설이지 말고 직전 버전으로 되돌립니다.

kubectl rollout undo deployment/web         # 직전 리비전으로
kubectl rollout history deployment/web      # 리비전 목록
kubectl rollout undo deployment/web --to-revision=3  # 특정 리비전으로

rollout status가 진행 중 멈춰 있으면 progressDeadlineSeconds(기본 600초) 초과 시 자동으로 실패 처리되며, 이때도 undo로 안전하게 복구됩니다.

readinessProbe가 없으면 위험하다

readinessProbe가 없으면 쿠버네티스는 컨테이너가 뜨자마자 "준비됨"으로 보고 트래픽을 보냅니다. 앱이 아직 부팅 중이면 사용자에게 에러가 갑니다. 롤링 업데이트의 안전성은 사실상 readinessProbe 정확도에 달려 있습니다.

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

배포 체크리스트

kubectl rollout status deployment/web      # 진행/완료 판정
kubectl get rs -l app=web                  # 구·신 ReplicaSet 비율
kubectl rollout undo deployment/web        # 실패 시 즉시 복구

readinessProbe와 maxUnavailable: 0만 갖춰도 대부분의 배포 사고는 사용자에게 도달하기 전에 막힙니다.

롤링 업데이트를 일부러 깨뜨려 보고 rollout undo로 복구하는 실습은 쿠버네티스 트랙에서 직접 해볼 수 있습니다 — 회원가입 없이 무료로.