deployment strategy - blue&green / rolling / canary

# 블루/그린 배포전략

맨처음은 deployment가 blue만 있다. 신버전인 rel: green 태그가 달린 deployment를 배포할때, service의 app: main셀렉터는 유지한채, 각각 deployment에서 rel: blue, rel: green으로 두개의 deployment를 생성하여 배포한다.

만약 신버전인 green버전에서 문제가 생기면, rel: green의 디플로이먼트를 삭제해서 롤백시키면 된다.

하지만 단점은 기존 blue버전말고 green버전을 새로 생성해야하기때문에 리소스가 두 배로 많이 든다.

만약 리소스 3개로 제한할거면.. blue를 2개로 하고, green을 한개로 해서 배포하는것도 맞는것같다. 이게 카나린가.

 

 

# 블루그린 실제로 해보기

blue버전 deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: main
  template:
    metadata:
      labels:
        app: main
        rel: blue
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl create -f blue.yaml

이렇게 만들게되면 뭐 이런식으로 생겼을거다.

이제 service를 생성해주자.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: main
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

kubectl create -f svc.yaml

단일진입점이자 로드벨런서 역할을 하는 service가 생성되었다.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: green-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: main
  template:
    metadata:
      labels:
        app: main
        rel: green
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl create -f green.yaml

이제 green버전을 배포해주면, service로는 총 여섯개의 pod에 로드벨런서로 진입할 수 있고, 신버전에 오류가 있는지 체크 할 수 있다. 또한 신 버전이 잘 동작한다고 판단하였을때는, blue deployment를 삭제하고 green버전만 남겨둘 수 있고, 만약 신버전에 오류가 발견되면 blue deployment를 남겨두면 된다.

 

 

꼭 blue, green을 동일하게 둘 필요가 없다.

 

scale명령으로 예를들어 4:2로 조절할 수도 있다.

kubectl scale deployment blue-deployment --replicas 2

kubectl scale deployment green-deployment --replicas 4

 

 

 

 

# rolling update deployment 롤링배포

이건 deployment의 주요기능이다. 하나 업뎃하고 하나 지우고 이런식으로 되는거다.

포스팅은 이걸 참조하면 된다.

controller/ replicaSet & deployment

 

 

 

 

 

# 카나리 배포

얘는 pod들중 하나만 신버전으로 배포해서 날려보는것이다.

 

 

 

# 테스트 해보기

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stable-deployment
spec:
  replicas: 4
  selector:
    matchLabels:
      app: main
  template:
    metadata:
      labels:
        app: main
        rel: stable
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80

얘는 기존에 있던 stable 버전의 deployment이다.

kubectl create -f stable.yaml

kubectl create -f canary-pod.yaml

 

각각 생성해준다면, 

 

그리고 service를 생성해주자. 위에 블루 그린배포랑 똑같다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: main
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

kubectl create -f svc.yaml

서비스는 app: main이라는 라벨링을 가진 pod들 다섯개에 모두 연결되어있다.

사실 canarypod도 replicas=1인 deployment로 하는게 더 낫긴하다.

 

이렇게 카나리 배포를 살짝키워서 배포를 할 수 있따.

 

 

 

 

 

# 블루/그린 배포와 카나리배포의 차이점

내가 이해한 바로는 블루/그린배포는 그만큼 더 pod들을 생성하게되니 리소스가 많이 소비된다. 하지만 그린버전이 오류가 있을경우 롤백이 용이해진다. green버전 deployment를 걍삭제해버리면되니까..

반면에 canary배포는 하나의 canary버전 pod를 끼워넣고 로드벨런서로 진입하는 pod갯수는 일정하게 유지한다. 리소스낭비가 적다는 뜻이다. 근데 뭐 그게 그거같음..

아래 포스팅을 참조했다.

 

블루/그린, 롤링, 카나리 배포의 차이점과 어떤 경우에 각각의 배포방식을 시도하는지 조사해보