쿠버네티스 업데이트 및 배포 전략

1. Rolling Update (롤링 업데이트)

• 기본 동작:

  • Pod를 점진적으로 교체하면서 새 Pod를 생성합니다.
  • 가용성을 유지하며 트래픽이 중단되지 않도록 설계.
  • 기존 Pod를 하나씩 종료하고 새 Pod를 하나씩 생성하는 방식.

• 장점:

  • 서비스 중단 없이 점진적으로 업데이트 가능.
  • 한 번에 교체하는 Pod 수를 제어 가능 (maxUnavailable, maxSurge 설정).

• 설정:

  strategy:

  type: RollingUpdate    

• rollingUpdate:

  maxUnavailable: 1 \# 최대 1개의 Pod만 비가용 상태
  maxSurge: 1 \# 최대 1개의 Pod 추가 생성

k8s에서 Rolling Update가 default 업데이트 전략이다.

2. Recreate (재생성)

동작 방식:
기존 Pod를 모두 삭제한 뒤 새로운 Pod를 생성.
서비스가 일시적으로 중단될 수 있음.

사용 사례:
상태 간 충돌(State Conflict)이 발생할 수 있는 애플리케이션.
예: 데이터베이스 업데이트나 상태 저장 애플리케이션.

설정:
strategy:
type: Recreate

장점:
새 리소스가 기존 리소스와 충돌할 가능성이 없으므로, 복잡한 동작을 피할 수 있음.

단점:
Pod 교체 중 서비스가 중단될 수 있음

3. Blue-Green Deployment (블루-그린 배포)

동작 방식:

새 버전의 Pod를 새로운 환경(그린)에 배포하고, 기존 환경(블루)과 분리.
새로운 버전이 준비되면 트래픽을 새 환경으로 스위치.

사용 사례:

다운타임 없이 새 버전을 테스트한 뒤, 모든 트래픽을 새 버전으로 전환하고 싶은 경우.
대규모 트래픽 관리 또는 민감한 애플리케이션.

장점:

새 버전 테스트가 쉬움.
문제가 발생하면 기존 버전으로 빠르게 롤백 가능.

단점:

추가적인 리소스(새로운 Pod, 노드)가 필요.
Kubernetes에서는 기본 제공되지 않으며, 서비스 라우팅이나 별도 툴(Argo Rollouts, Spinnaker 등)이 필요.

4. Canary Deployment (카나리 배포)

동작 방식:

새 버전의 일부 Pod만 배포한 뒤, 트래픽을 제한적으로 전달.
새 버전의 안정성이 확인되면 점진적으로 더 많은 트래픽을 새 버전에 전달.

사용 사례:

새 버전의 안전성을 소규모 트래픽으로 먼저 확인.
대규모 서비스 업데이트.

장점:

새 버전의 안정성을 소규모로 확인 가능.
문제가 발생해도 빠르게 롤백 가능.

단점:

추가적인 라우팅 설정 필요.
롤아웃 속도가 느릴 수 있음.

5. Shadow Deployment (섀도우 배포)
   동작 방식:

   새 버전에 실제 트래픽 복사본을 보내 테스트.
   서비스에는 영향을 미치지 않으면서 새 버전의 동작을 검증.

사용 사례:

트래픽 테스트 또는 대규모 업데이트 전 동작 검증.
예: 머신러닝 모델 업데이트 시.

장점:

새 버전을 실제 환경과 동일한 조건에서 테스트 가능.
사용자 경험에 영향을 주지 않음.

단점:

복잡한 네트워크 라우팅 및 모니터링 설정 필요.

Blue-Green 또는 Canary 배포는 서비스 라우팅 제어(예: Ingress, Service)와 추가 툴(Argo Rollouts, Istio 등)이 필요합니다.