Canary Updates

이 글에서는 2022.01.24 - Deployment Strategy - Blue Green 에 이어서 Canary라고 불리는 Deployment Update 전략에 대해 정리한다.

 

Canary Updates

Canary Updates의 진행 방식은 아래와 같다.

 

업데이트 진행 순서

1. 기존 버전의 Deployment이 동작하고 있는 환경에 새 버전의 Deployment을 배포한다. 단, 전체 트래픽의 적은 비율만을 새 버전의 Deployment로 라우팅 되도록 한다.

즉, 이 단계에서는 대부분의 트래픽이 기존 버전의 Deployment로 라우팅되는 상태이다.

2. 새 버전의 Deployment에 대한 테스트가 완료되면, 기존 버전의 Deployment를 새 버전으로 업그레이드(Rolling update)한다.

3. 새 버전의 애플리케이션을 테스트하기 위해 배포했던 Deployment를 삭제한다.

 

Canary Updates는 Blue/Green 전략처럼 Kubernetes Deployment와 Service를 이용해 구현할 수 있다.

 

구현 방법

1. 기존 버전의 애플리케이션을 Deployment로 배포한다. 이를 deployment-primary라고 하자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-primary
  labels:
    app: myapp
    type: front-end
spec:
  templete:
    metadata:
      name: myapp-pod
      labels:
        version: v1
        app: front-end # 서비스 연결용 Label
    spec: containers
    - name: app-container
      image: myapp-image:1.0
  replicas: 5
  selector:
    matchLabels:
      type: front-end

 

2. Deployment에 트래픽을 라우팅 하는 서비스를 생성한다. 서비스를 포드와 연결하기 위해 app=front-end Label과 Selector를 이용한다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: front-end # 포드 연결용 Selector

 

3. 새 버전의 애플리케이션을 배포한다. 이를 deployment-canary라고 하자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
  labels:
    app: myapp
    type: front-end
spec:
  templete:
    metadata:
      name: myapp-pod
      labels:
        version: v2
        app: front-end
    spec: containers
    - name: app-container
      image: myapp-image:2.0
  replicas: 1
  selector:
    matchLabels:
      type: front-end

두 개의 버전의 애플리케이션에 모두 트래픽을 라우팅 할 수 있도록, Service의 Selector로 설정된 Label이 각 Deployment에 동일하게 설정되어 있어야 한다. 또한, Service는 Deployment에 관계없이 Pod 전체에 대해 트래픽을 균등하게 분배하기 때문에 deployment-canary의 replicas가 deployment-primary보다 적어야 한다.

 

4. deployment-canary의 테스트가 완료되면, deployment-primary를 업그레이드한다.

 

5. deployment-canary를 삭제한다.