배포 전략

Source: Dev.to

Rolling Update

What it is
Kubernetes는 올바르게 구성될 경우 다운타임 없이 오래된 Pod를 새로운 Pod로 점진적으로 교체합니다.

How it works

• 일부 오래된 Pod가 종료됩니다.
• 새로운 Pod가 단계적으로 생성됩니다.
• 전환 중에 트래픽이 공유됩니다.

Key settings

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

Pros

• 다운타임이 없음(기본 동작).
• 간단하고 프로덕션에 적합합니다.

Cons

• 오래된 버전과 새로운 버전이 동시에 실행되므로 데이터베이스/스키마 변경이 복잡해질 수 있습니다.

When to use

• 대부분의 웹 앱, API, 마이크로서비스.

---

Recreate

What it is
모든 오래된 Pod를 중지한 뒤 새로운 Pod를 생성합니다.

Config

strategy:
  type: Recreate

Pros

• 매우 간단합니다.
• 버전 혼합이 없습니다.

Cons

• ❌ 다운타임 – 사용자가 서비스 중단을 경험합니다.

When to use

• 단일 인스턴스 앱.
• 개발/테스트 환경.
• 동시에 여러 버전을 실행할 수 없는 애플리케이션.

---

Blue‑Green

What it is
두 개의 환경을 유지합니다:

• Blue – 현재 버전.
• Green – 새로운 버전.

트래픽이 Blue에서 Green으로 즉시 전환됩니다.

How to implement

1. 새로운 버전을 별도의 Pod 집합(Green)으로 배포합니다.
2. Service selector(또는 Ingress)를 업데이트하여 Green Pod를 가리키게 합니다.

Pros

• 즉시 롤백 가능.
• 다운타임이 없음.
• 매우 안전한 배포.

Cons

• 두 환경이 동시에 존재하는 동안 자원이 두 배로 필요합니다.
• 일반적으로 수동이거나 도구에 의해 진행됩니다.

When to use

• 위험도가 높은 릴리스.
• 중요한 프로덕션 시스템.

---

Canary

What it is
새 버전을 소수의 사용자에게 먼저 제공하고, 이후 트래픽을 점진적으로 늘립니다.

How to implement

• 카나리 버전에 대해 복제본 수를 적게 배포 또는
• Ingress 또는 Service Mesh를 이용해 트래픽을 분할합니다.

Pros

• 위험도가 매우 낮으며, 버그를 조기에 발견할 수 있습니다.

Cons

• 설정이 복잡합니다.
• 모니터링 및 메트릭이 필요합니다.

When to use

• 대규모 사용자 기반.
• 성능에 민감한 애플리케이션.

---

A/B Testing

What it is
다른 사용자에게 헤더, 쿠키, 지역 등에 따라 서로 다른 버전을 제공합니다.

Pros

• 비즈니스 실험 및 기능 비교가 가능합니다.

Cons

• 설정이 복잡합니다.
• 순수한 “배포” 전략이라기보다는 실험 전략입니다.

When to use

• 기능 테스트.
• 제품 실험.

---

Strategy Comparison