[k8s] Deployment: Blue/Green 배포해보기

본 포스트에서는 자동화까지 전부 다루지는 않고, 원리에 대해서만 정리한다.

블루그린은 Rolling Update에서 조금 발전한 형태의 배포 기법이다.

아래의 프로세스를 따른다.

  1. 구버전의 파드를 Blue, 새버전의 파드를 Green으로 가정한다.
  2. 일단 Green 파드를 먼저 띄운다.
  3. 메인 서비스(로드밸런서 등)는 아직 Blue를 가리킨다.
  4. Green이 성공적으로 다 떴다면, 메인 서비스는 한번에 가리키는 대상을 Green으로 교체하고, Blue는 버린다.

Rolling에서 발생할 수 있는 구버전과 신버전의 공존 문제를 해결했다는게 장점이다.




Deployment 기본 구성

만약 이런 형태의 단일 Deployment가 있었다면

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-server
spec:
  replicas: 3
  selector: 
    matchLabels: 
      app: test-server
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template: 
    metadata: 
      labels: 
        app: test-server
    spec: 
      containers: 
        - name: test-server
          image: myyrakle/node-server-for-test:1

이걸 blue와 그린 2개의 Deployment로 분리해야한다.

구분되게 메타데이터만 다르게 하면 되고, 다른건 그냥 그대로 복붙하면 된다.
그럼 이제 저걸 배포할때마다 blue->green, green->blue, ... 돌아가면서 써먹게 된다.




Service 기본 구성

원래 그냥 하나의 서버에 고정되어있던 것을

apiVersion: v1
kind: Service
metadata:
  name: test-service
spec:
  selector:
    app: test-server
  ports:
    - protocol: TCP
      port: 80
  type: LoadBalancer

일단 초기에 사용할 deployment에 먼저 묶어준다.

그리고 서비스에서 셀렉터를 바꿔주는 것으로 배포 교체를 수행할 것이다.




Blue-Green 배포하기

먼저 docker container의 새 버전을 push한다.
그리고 현재 프로덕션 서버가 blue라면, 서비스와 연결되어있지 않은 green 버전에 새 컨테이너를 달아서 파드를 띄운다.

그리고 잘 뜰때까지 기다린다.

그리고 다 떴다면 health check 등을 통해 동작 여부를 추가로 확인할 수 있을 것이다.
여기서는 생략한다.

blue 버전의 pod들이 다 성공적으로 떴다는게 확실하다면, 서비스의 selector를 수정한다.

그러면

중단 없이 한번에 교체가 될 것이다.



참조
https://velog.io/@miewone/kubernetes-Blue-Green-deployment