[k8s] Deployment: Blue/Green 배포해보기
본 포스트에서는 자동화까지 전부 다루지는 않고, 원리에 대해서만 정리한다.
블루그린은 Rolling Update에서 조금 발전한 형태의 배포 기법이다.
아래의 프로세스를 따른다.
- 구버전의 파드를 Blue, 새버전의 파드를 Green으로 가정한다.
- 일단 Green 파드를 먼저 띄운다.
- 메인 서비스(로드밸런서 등)는 아직 Blue를 가리킨다.
- 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