Deployment

• ReplicaSet — "라벨이 맞는 파드가 N개 있어야 한다" 만 책임진다

• Deployment — ReplicaSet 을 여러 세대 관리해 '전환' 과 '롤백' 을 책임진다

• 직접 ReplicaSet 을 만들지 않는다 — Deployment 가 대신 만든다

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

이미지를 바꾸면

• ① 새 ReplicaSet 을 만든다 (replicas: 0 에서 시작)
• ② 새 것을 늘리고 옛 것을 줄인다 — maxSurge · maxUnavailable 규칙대로
• ③ 다 넘어가면 옛 ReplicaSet 은 replicas: 0 으로 남는다 (롤백용)

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%          # 원하는 수보다 얼마나 더 띄울 수 있나
    maxUnavailable: 25%    # 얼마나 부족해도 되나

maxUnavailable: 0 + maxSurge: 1

• 항상 원하는 수를 유지하며 하나씩 교체 (가장 안전, 가장 느리다) maxSurge: 0 + maxUnavailable: 1

• 자원을 더 쓰지 않지만 잠시 용량이 준다

자원 여유가 있으면 앞쪽을, 빡빡하면 뒤쪽을 고른다

롤아웃이 멈추는 것은 안전장치다

새 파드가 Ready 가 안 되면 롤아웃은 거기서 멈춘다

• 옛 파드는 살아 있으므로 서비스는 계속된다
• progressDeadlineSeconds(기본 600초)를 넘기면 실패로 표시된다

rollout status 가 안 끝나면 새 파드의 상태를 본다

• Pending · ImagePullBackOff · CrashLoopBackOff · Ready 안 됨

kubectl rollout status deploy/web
kubectl rollout history deploy/web
kubectl rollout undo deploy/web --to-revision=3
kubectl rollout restart deploy/web      # 이미지 그대로 파드만 교체

rollout restart 의 쓰임

설정(ConfigMap)이 바뀌었을 때 파드를 새로 띄워 다시 읽게 하는 표준 방법이다 환경변수로 넣은 설정은 재생성 없이는 절대 안 바뀌기 때문이다

내부적으로는 파드 템플릿에 애너테이션(재시작 시각)을 추가해 템플릿 해시를 바꾸는 방식이다 → 정상적인 롤링 업데이트가 일어난다

배포 전략을 바깥에서 만든다

쿠버네티스 기본은 RollingUpdate 와 Recreate 둘뿐이다 블루-그린·카나리는 기본 제공되지 않는다

만드는 방법

• 라벨과 서비스 셀렉터를 조작한다 (수동 블루-그린)
• Gateway API 의 가중치 기반 트래픽 분할
• Argo Rollouts · Flagger 같은 도구
  • 지표를 보고 자동으로 승격·롤백까지 한다

"쿠버네티스가 카나리를 해 준다" 는 오해다

구·신 버전이 공존한다는 사실

롤링 중에는 두 버전이 동시에 돈다

깨지는 지점

• DB 스키마 — 컬럼을 지우면 구버전이 죽는다
  • 추가 → 양쪽 지원 → 제거 의 3단계로 나눈다
• API 응답 필드를 지우면 구버전 클라이언트가 깨진다
• 캐시·세션 직렬화 형식이 바뀌면 서로 못 읽는다

"배포는 무중단인데 데이터가 깨진다" 가 여기서 나온다

면접 함정

• ❌ "롤아웃이 멈추면 장애" → 옛 파드가 살아 있다. 오히려 안전한 동작이다.
• ❌ "ConfigMap을 바꾸면 자동 반영" → 환경변수는 안 되고, 파일도 앱이 다시 읽어야 한다.