본문 바로가기
CSP (Cloud Service Provider)/GCP

GKE로 배포 관리하기 (3) Blue/Green 배포

by BTC_yljo 2022. 5. 26.

안녕하세요 BTC Hallo 팀입니다. 이번 주에는 'Canary 배포'에 이어서 GKE로 배포 관리하는 방법 중 'Blue/Green 배포'에 대해 포스팅 하겠습니다.

 

Blue/Green 배포

순차적 업데이트는 최소한의 오버헤드, 최소한의 성능 영향, 최소한의 다운타임으로 애플리케이션을 배포할 수 있기 때문에 가장 좋은 업데이트 방식이지만, 배포를 모두 완료한 후에 부하 분산기를 수정하여 새 버전을 가리키도록 하는 것이 유리한 경우도 있다. 이 경우에는 Blue/Green 배포가 사용될 수 있습니다.

Kubernetes에서는 이전의 'blue' 버전용 배포와 새로운 'green' 버전용 배포를 만들어 업데이트할 수 있습니다. 'blue' 버전에 기존 hello 배포를 사용하면 라우터 역할을 하는 서비스를 통해 배포에 액세스하게 됩니다. 새 'green' 버전이 가동 및 실행되면 서비스를 업데이트하여 이 버전을 사용하도록 전환하게 됩니다.

Blue/Green 배포의 주요 단점은 애플리케이션을 호스팅하려면 클러스터에 최소 2배의 리소스가 필요하다는 점입니다. 그러므로 한 번에 두 버전의 애플리케이션을 배포하려면 먼저 클러스터에 충분한 리소스가 있는지 확인할 필요가 있습니다.

 

서비스

기존의 hello 서비스를 사용하되 app:hello, version: 1.0.0으로 선택기를 업데이트한다. 선택기는 기존의 'blue' 배포를 선택하지만 그러나 다른 버전을 사용할 것이기 때문에 'green' 배포는 선택하지 않습니다.

#서비스 업데이트
kubectl apply -f services/hello-blue.yaml

 

Blue/Green 배포를 사용하여 업데이트하기

Blue/Green 배포 스타일을 지원하기 위해 새 버전용으로 새로운 'green' 배포를 만들고, Green 배포에서 버전 라벨과 이미지 경로를 업데이트합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
        track: stable
        version: 2.0.0
    spec:
      containers:
        - name: hello
          image: kelseyhightower/hello:2.0.0
          ports:
            - name: http
              containerPort: 80
            - name: health
              containerPort: 81
          resources:
            limits:
              cpu: 0.2
              memory: 10Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 81
              scheme: HTTP
            initialDelaySeconds: 5
            periodSeconds: 15
            timeoutSeconds: 5
          readinessProbe:
            httpGet:
              path: /readiness
              port: 81
              scheme: HTTP
            initialDelaySeconds: 5
            timeoutSeconds: 1

Green 배포를 생성합니다.

kubectl create -f deployments/hello-green.yaml

Green 배포가 있고 제대로 시작된 경우 현재 1.0.0 버전이 아직 사용되고 있는지 확인합니다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

서비스가 새 버전을 가리키도록 업데이트합니다.

kubectl apply -f services/hello-green.yaml

서비스가 업데이트되면 'green' 배포가 즉시 사용되고, 항상 새 버전이 사용되고 있는지 확인할 수 있습니다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

 

Blue/Green 롤백

필요한 경우 같은 방법으로 이전 버전으로 롤백할 수 있다. 'blue' 배포가 아직 실행 중일 때 서비스를 이전 버전으로 다시 업데이트하면 됩니다.

kubectl apply -f services/hello-blue.yaml

서비스를 업데이트하면 롤백이 성공적으로 완료되며, 사용 중인 버전이 정확한지 다시 확인힙니다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

 

 

 

[출처]

https://www.cloudskillsboost.google/focuses/639?parent=catalog 

 

Kubernetes Engine으로 배포 관리 | Google Cloud Skills Boost

Dev Ops 권장사항에서는 여러 배포를 사용하여 애플리케이션 배포 시나리오를 관리합니다. 이 실습에서는 여러 이기종 배포가 사용되는 일반적인 시나리오를 처리할 수 있도록 컨테이너를 확장

www.cloudskillsboost.google

 

댓글