Kubernetes의 다양한 배포방식 (2) Blue/Green 배포

Blue/Green 배포

출처 : https://www.weave.works/blog/kubernetes-deployment-strategies

RollingUpdate는 이전앱과 신규앱이 공존하는 시간이 발생한다. 또한 롤백을 시도할때도 복구 시간이 소요된다.

 

이번에는 Blue/Green 배포에 대해 알아보자.

 

Blue/Green 배포는 현재 버전과 새 버전이 병렬로 실행된 다음 모든 트래픽이 새 버전으로 이동하는 방식이다.

 

장점

• RollingUpdate와 달리 기존앱에서 새로운앱으로 바로 이전이 가능하다.
• 이전 앱과 새로 배포할 앱을 테스트 할 수 있다.
• 새로운 앱에서 문제가 발생할 때 이전 버전으로 빠르게 롤백할 수 있다.

단점

• 두 배의 리소스가 필요함으로 인프라 비용이 증가할 수 있다.
• PaaS 솔루션이나 argo 같은 도구를 사용하지 않으면 배포하기가 까다롭다.

Kubernetes에서는 기본적으로 RollingUpdate 방식으로 배포를 하지만, Blue/Green 는 Istio, Nginx 또는 Argo 와 같은 도구를 사용하여 Blue/Green 배포를 많이 진행한다.

 

이번에는 Kubernetes Service를 이용한 방법으로 Blue/Green 배포를 진행해 보자.

 

우선 Flask 를 이용한 간단한 앱을 작성해 보자.

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World! V1"

if __name__ == '__main__':
    app.run()

 

Dockerfile은 아래와 같이 작성한다.

FROM python:3.8-slim
MAINTAINER kmaster <kmaster8k@gmail.com>

COPY . /app
WORKDIR /app

RUN pip3 install flask 

EXPOSE 5000
CMD ["python3", "-m", "flask", "run", "--host=0.0.0.0"]

 

이제 Dockerfile을 이용하여 빌드를 한 후 Dockerhub registry에 Push해 보자.

# buildah build-using-dockerfile -t ghcr.io/kmaster8/hello:v1 .
STEP 1: FROM python:3.8-slim
Getting image source signatures
Copying blob 5c69ac0246d0 skipped: already exists
Copying blob 5eb5b503b376 skipped: already exists
...
STEP 7: CMD ["python3", "-m", "flask", "run", "--host=0.0.0.0"]
STEP 8: COMMIT ghcr.io/kmaster8/hello:v1
af7b14c2441e5f8a92fe91b5957c02f0f282263e3e5b67141899d0acbda1dad4

 

이미지 생성이 완료되었으니 이제 Kubernetes에 앱을 배포해 보자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-v1
  template:
    metadata:
      labels:
        app: hello-v1
    spec:
      containers:
      - name: hello
        image: ghcr.io/kmaster8/hello:v1
        ports:
        - containerPort: 5050

 

이제 기존앱 (v1) 에서 소스를 수정한 새로운 앱 (v2) 를 만들어보자.

(소스 및 빌드 과정은 생략)

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-v2
  template:
    metadata:
      labels:
        app: hello-v2
    spec:
      containers:
      - name: hello
        image: ghcr.io/kmaster8/hello:v2
        ports:
        - containerPort: 5050

 

이제 빌드가 완료되었고, 운영/개발에 필요한 서비스를 배포해 보자. 요약해서 그림을 보면 아래와 같다.

여기서 서비스는 Loadbalancer를 이용하거나 Ingress 호출을 할수도 있고, On-Prem 같은 경우는 NodePort를 사용할 수도 있을 것이다.

 

 

Blue/Green 배포를 위해서는 개발자 또는 QA팀에서 새로운 앱 테스트가 완료된 후 Prod-service를 hello-v2로 연결해 주면 고객/사용자는 새롭게 배포된 앱으로 모두 이동하게 될 것이다.

그럼 이제 ingress와 서비스를 배포하여 테스트를 진행해 보자.

 

[Service]

apiVersion: v1
kind: Service
metadata:
  name: prod-service
spec:
  type: ClusterIP
  selector:
    app: hello-v1
  ports:
  - protocol: TCP
    port: 5000
    targetPort: 5000

 

apiVersion: v1
kind: Service
metadata:
  name: stg-service
spec:
  type: ClusterIP
  selector:
    app: hello-v2
  ports:
  - protocol: TCP
    port: 5000
    targetPort: 5000

 

[Ingress]

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tomcat
spec:
  rules:
  - host: test.prod.10.60.200.121.sslip.io
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: prod-service
            port:
              number: 5000

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: stg-ingress
spec:
  rules:
  - host: test.stg.10.60.200.121.sslip.io
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: stg-service
            port:
              number: 5000

 

이제 서비스와 Ingress가 모두 완성되었다. 각각 호출해 보도록 하자.

 

prod-service

stg-service

 

이제 기존앱과 신규앱이 각각 정상적으로 호출됨을 확인하였다. 신규앱에 대한 테스트가 완료되었다면 이제 prod-service가 v2 를 바라보도록 변경해 보자. 우선 jmeter라는 부하 도구를 사용하여 기존 앱에 부하를 주고 난후 service변경을 해 보도록 하겠다.

 

Jmeter

 

부하를 실행한 후 서비스를 변경해 보자. 서비스 변경은 아래와 같이 한다.

kubectl patch service prod-service --patch '{"spec": {"selector": {"app": "hello-v2"}}}'

 

Serivce변경 후 JMeter를 확인해 보면 에러율 없이 정상적으로 부하가 계속 발생하는 것을 확인 할 수 있다.

 

 

그럼 서비스를 실제 확인해 보자.

 

기존 V1에서 V2 가 호출되는 것을 확인 할 수 있다.