PaaS/Kubernetes

(Kubernetes) Deployment 전략 들

armyost 2021. 6. 28. 21:40
728x90

1. Rolling Stratege

아래와 같은 일반 Deployment 구분에서 특별한 spec을 정의하지 않으면 Default로 Rolling 전략으로 배포된다.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
        metadata:
           labels:
             app: awesomeapp
        spec:
          containers:
            - name: awesomeapp
              image: imagerepo-user/awesomeapp:new
              ports:
                - containerPort: 8080

 

strategy라는 파라미터를 추가로 주어서 명시적으로 정의할 수 도 있다. 

- spec.strategy.rollingUpdate.maxUnavilable : Rolling Update중 Unavailable한 최대 Pod의 갯수

- spec.strategy.rollingUpdate.maxSurge : Rolling Update중 정해진 Pod 수 이상으로 만들 수 있는 Pod의 최대 개수

spec:
  replicas: 3
  strategy:
        type: RollingUpdate
        rollingUpdate:
           maxSurge: 25%
           maxUnavailable: 25%  
  template:
  ...

 

관련 kubectl

kubectl set image deployment/gs-spring-boot-docker-deployment gs-spring-boot-docker=nara0617/gs-spring-boot-docker:2.0 --record 
//새로운 이미지로 Deployments를 업데이트 하는것, -recording중

kubectl rollout history deployment/gs-spring-boot-docker-deployment
//버전 변경에 대한 History는 다음과 같이 kubectl rollout history 명령어로 확인이 가능

kubectl rollout history deployment/gs-spring-boot-docker-deployment --revision=2
//수행된 Revision에 대한 명령어 상세 기록을 확인.

kubectl rollout undo deployment/gs-spring-boot-docker-deployment
//과거 버전으로 롤백할 때


 

 

2. Recreate

spec:
  replicas: 3
  strategy:
        type: Recreate
  template:
  ...

 

 

3. Blue/Green

아래의 순서로 진행된다.

1) 02버전의 Deployment를 생성

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
        metadata:
           labels:
             app: awesomeapp
             version: "02"

 

2) 02버전의 Deployment의 서비스가 완전히 생성되고 서비스가 괜찮아 보이면 frontend 역할인 Service의 라우팅을 02버전 Deployment로 변경

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

 

위 과정을 자동화 하기위한 Jenkins 스크립트도 있다. 아래 링크를 참고바람

 

적용방법 : https://www.powerupcloud.com/automate-blue-green-deployment-on-kubernetes-in-a-single-pipeline-part-10/

스크립트 파일 : https://github.com/powerupcloud/TaxiCabApplication/blob/master/Jenkinsfile

 

4. Canary

 

적용순서는 다음과 같다.

1) Blue Deployment 생성
2) Ingress를 다이렉트 Traffic으로 Blue Deployment의 Service로 향하게 함
3) Green Deployment 생성
4) canary ingress로 10%만 Green Deployment의 Service로 향하게 함

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: canary-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: kubesphere.io
    http:
      paths:
      - backend:
          serviceName: green-service
          servicePort: 80

 

적절하게 로드벨런싱 되는지 테스트

for i in $(seq 1 10); do curl -s --resolve kubesphere.io:30205:192.168.0.88 kubesphere.io:30205 | grep "Hostname"; done


5) Green Deployment 에서 돌아가는 애플리케이션이 정상적이라고 판단되면 Ingress를 100% Green Deployment의 Service로 향하게함

= canary 옵션을 날려버리고 green-service로 향하게 ingress를 수정한다.

 

위 과정을 자동화 하기 위해서는Flagger, Istio and GitOps Pipelines 등으로 리소스를 만들어야 하는데 아래 링크를 참고하기 바란다.(추후 실제 구축과정을 상세히 설명하겠음)

https://www.weave.works/blog/automated-canary-management-to-kubernetes-with-flagger-istio-and-gitops-pipelines