[CKAD] Blue/Green 배포와 Canary 배포 정리

Blue/Green 배포

개념

• 두 가지 환경(Blue와 Green)을 사용하여 새 버전을 배포.
  • Blue: 현재 운영 중인 안정적인 버전.
  • Green: 새롭게 배포된 버전(테스트 중).
• 새 버전(Green)이 준비되면 트래픽을 기존 버전(Blue)에서 새로운 버전(Green)으로 한 번에 전환.

장점

1. 빠른 롤백: 문제가 발생하면 트래픽을 즉시 이전 버전으로 되돌릴 수 있음.
2. Downtime 최소화: 새로운 버전이 완전히 준비된 후 트래픽을 전환.
3. 테스트 가능: Green 환경에서 충분히 테스트 후 전환 가능.

단점

• 두 가지 환경을 동시에 운영해야 하므로 리소스 사용이 증가.
• 구현이 비교적 복잡.

---

Canary 배포

개념

• 새 버전을 점진적으로 배포.
  • 소량의 트래픽(예: 5%)을 새 버전으로 보내고, 문제가 없으면 점진적으로 트래픽 비율을 늘림.
• 기존 버전과 새 버전이 동시에 트래픽을 처리.

장점

1. 리스크 완화: 새로운 버전의 안정성을 확인하며 점진적으로 배포.
2. 사용자 피드백 수집: 실사용자 데이터를 바탕으로 새 버전 테스트 가능.
3. 유연성: 특정 사용자 그룹만 새 버전을 경험하게 설정 가능.

단점

• 배포 속도가 느림.
• Canary로 전송된 트래픽에서 문제가 발생하면 사용자 경험에 영향을 줄 수 있음.

---

Blue/Green vs Canary 비교

특성 Blue/Green 배포 Canary 배포

트래픽 전환 방식	트래픽 전체를 한 번에 전환	소량의 트래픽으로 점진적 전환
리소스 요구량	두 환경을 모두 유지해야 함	기존 환경에 새 버전만 추가
롤백 속도	즉시 롤백 가능	Canary 설정에 따라 다름
사용 사례	대규모 릴리스 또는 Zero Downtime 배포	실시간 피드백 기반의 배포

---

Kubernetes에서 구현 방법 - 배포 구현 방법 

A. Blue/Green 배포

1) Service를 활용

• 기존 Deployment를 Blue로 두고, 새 Deployment(Green)를 생성.
• Green이 준비되면 Service의 selector를 Green으로 업데이트.

예제

# Blue Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: blue
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
      - name: my-app
        image: my-app:1.0

# Green Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: green
  template:
    metadata:
      labels:
        app: my-app
        version: green
    spec:
      containers:
      - name: my-app
        image: my-app:2.0

# Service 변경 (Blue -> Green)
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
    version: green  # Blue에서 Green으로 전환
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

2) 주요 단계

1. Blue 환경에서 서비스 실행.
2. Green 환경에서 새 버전 배포.
3. Service의 selector를 변경해 트래픽을 Green으로 전환.
4. 문제가 발생하면 selector를 다시 Blue로 롤백.

---

B. Canary 배포

Kubernetes에서 Canary 배포는 Deployment를 활용하여 점진적으로 새 버전을 배포하는 방식으로 구현할 수 있습니다. Canary 배포는 트래픽의 일부를 새 버전으로 보내면서 안정성을 확인한 후, 단계적으로 트래픽 비율을 늘려가는 방식입니다.
이를 구현하려면 Deployment와 Kubernetes의 RollingUpdate 전략 또는 다중 Deployment를 활용합니다.

1) 배포 전략 활용

• Deployment의 strategy 옵션에서 RollingUpdate를 활용해 점진적으로 새 버전 배포.

 

Canary 배포의 주요 단계

1. 기존 애플리케이션(Stable Version)을 유지.
2. 새 애플리케이션 버전을 배포(Pod 수는 적게 설정).
3. 새 버전으로 소량의 트래픽을 전송.
4. 안정성이 확인되면 점진적으로 트래픽 비율을 늘림.
5. 문제가 발생하면 기존 Stable Version으로 롤백.

---

Deployment를 사용한 Canary 배포 방법

방법 1: RollingUpdate 전략 활용

RollingUpdate는 기존 Pod을 점진적으로 교체하는 Kubernetes 기본 배포 전략입니다.

예제

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10  # 총 10개의 Pod
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 추가로 생성할 수 있는 최대 Pod 수 (예: 1개)
      maxUnavailable: 1  # 비활성화될 수 있는 최대 Pod 수 (예: 1개)
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:2.0  # 새 버전 이미지

동작 방식

1. 한 번에 1개의 새 버전 Pod을 생성하고, 기존 Pod 중 1개를 종료.
2. 새 버전 Pod이 정상 상태에 도달하면 다음 Pod 교체 진행.
3. 전체 Pod이 새 버전으로 교체될 때까지 반복.

장점

• 트래픽의 점진적 전환이 자동으로 이루어짐.
• 별도의 설정 없이 Canary 배포 효과를 낼 수 있음.

단점

• Canary 트래픽 비율을 세부적으로 조정하기 어렵다.

---

방법 2: 다중 Deployment를 사용한 Canary 배포

기존 Stable Deployment와 새로운 Canary Deployment를 별도로 생성하여 Service의 트래픽 비율을 조정합니다.

1. stable deployment 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stable-app
spec:
  replicas: 8  # 트래픽의 80%를 처리
  selector:
    matchLabels:
      app: my-app
      version: stable
  template:
    metadata:
      labels:
        app: my-app
        version: stable
    spec:
      containers:
      - name: my-app
        image: my-app:1.0

2. Canary Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary-app
spec:
  replicas: 2  # 트래픽의 20%를 처리
  selector:
    matchLabels:
      app: my-app
      version: canary
  template:
    metadata:
      labels:
        app: my-app
        version: canary
    spec:
      containers:
      - name: my-app
        image: my-app:2.0

3.  Service 정의: 

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app  # app label로 트래픽 분산
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

 

요약

1. Blue/Green 배포:
   • 두 환경(Blue, Green)을 유지하며 트래픽을 한 번에 전환.
   • 빠른 롤백과 Zero Downtime 제공.
2. Canary 배포:
   • 소량의 트래픽을 점진적으로 새 버전으로 라우팅.
   • 리스크를 완화하며 안정성을 점검.
3. Kubernetes에서:
   • Blue/Green 배포는 Service selector 변경으로 구현.
   • Canary 배포는 RollingUpdate 전략과 다중 Deployment를 구성해서 구성