Kubernetes의 다양한 배포방식 (1) RollingUpdate

개발자가 만든 소스를 개발/운영 서버에 배포하는 과정을 보통 CI/CD 라고 부른다.

 

Kubernetes에서는 보통 CI과정에 소스 빌드, TestCase 수행, Code Inspect 등을 거친 후 Container Image 생성 및

Container Registry 에 저장 (Push) 하는 과정까지 이루어진다.

 

그럼 CD는 어떻게 이루어지는가? CD 과정에 앞서 잠시 CD라는 용어를 인터넷에서 검사하는 Continuous Delivery,  Continuous Deployment 라는 용어가 같이 보인다. 이 둘은 뭐가 차이일까? 

 

Continuous Delivery (지속적인 전달) : 개발된 최종 변경 사항을 운영기까지 푸시(전달)하기 위한 수동적인 과정을 보통 Continuous Delivery 라고 부릅니다.

Continuous Deployment (지속적인 배포) : Continuous Delivery의 과정을 자도으로 배포하기 위한 방식을 Continuous Deployment 라고 부릅니다.

 

실제 용어가 중요한 것이 아니라 이러한 CI/CD 과정을 자동화 하는 것도 중요하지만 운영기까지 배포하는 과정이 지속적이어야 한다는 것이다. 즉 운영기에 배포되어 사용자가 접속하기까지의 과정이 장애없이 신속히 이루어 질수 있도록 해야 한다. 또한 운영기에 배포 후 장애가 발생하는지 지속적으로 모니터링하고 장애시에는 롤백을 신속히 할 수 있는 아키텍처를 가지고 있어야 한다.

 

RollingUpdate

Kubernetes는 기본적으로 2가지 배포 전략을 가지고 있다.

(참고 : https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/ )

 

1) RollingUpdate : 운영중인 Pod를 순차적으로 교체하는 방식

참고 :https://www.weave.works/blog/kubernetes-deployment-strategies

2) Recreate : 운영중인 Pod를 모두 삭제한 다음 새로운 Pod를 생성하는 방식 ( 이 방식은 무중단이 아님 )

참고 :https://www.weave.works/blog/kubernetes-deployment-strategies

RollingUpdate는 기존앱과 신규앱이 교차하는 방식에서 서버의 리소스 여유분이 반드시 있어야 하지만, Recreate는 기존앱이 중단된 후 새로운 Pod가 실행되기 때문에 리소스가 부족하다면 Recreate를 사용한다.

 

• RollingUpdate의 장점

  - 현재 버전이 라이브 상태를 유지함으로 지속적인 배포가 가능

  - 최소 추가 자원으로 배포가능 ( Blue/Green 배포 방식은 배포된 앱의 전체 리소스가 추가로 필요하다. )

• RollingUpdate의 단점

   - RollingUpdate는 순차적으로 교체하는 방식이라서 운영중인 Pod개수, maxSurge, maxUnavailable 등의 옵션에  따라 지연 시간이 다르겠지만 이 시간 동안에는 기존앱과 신규앱이 사용자에게 동시에 서비스된다.

   - 문제가 있을 경우 롤백을 진행해야 하는데 이 또한 문제가 발생된 앱을 즉각적으로 중단하기에는 어려움이 있다.

 

예제

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rollingupdate-web
  namespace: test
  labels:
    app: rollingupdate-web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: rollingupdate-web
  template:
    metadata:
      labels:
        app: rollingupdate-web
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: Always
        ports:
          - containerPort: 80

위의 yaml을 수행하면 기본적으로 아래와 같이 spec 이 정의된다.

 

# kubectl create -f rolling.yaml
deployment.apps/rollingupdate-web created

#kubectl get deployments -n test rollingupdate-web -o yaml
...
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: rollingupdate-web
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
...

• maxSurge : 의도한 파드의 수에 대해 생성할 수 있는 최대 파드의 수를 지정하는 선택적 필드이다. (백분율 또는 절대숫자)
• maxUnavailable : 업데이트 프로세스 중에 사용할 수 없는 최대 파드의 수를 지정하는 선택적 필드이다. (백분율 또는 절대숫자)
• progressDeadlineSeconds : 롤링 이벤트가 시간 초과되기를 기다리는 시간(초). 지정된 시간에 도달하면 자동으로 이전 배포로 롤백된다. (기본값 : 600초)
• minReadySeconds : 새롭게 생성된 파드의 컨테이너가 어떤 것과도 충돌하지 않고 사 용할 수 있도록 준비되어야 하는 최소 시간(초)을 지정하는 선택적 필드이다. (기본값 : 0)

배포된 상태를 조회해보자

# kubectl get deployments -n test rollingupdate-web
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
rollingupdate-web   3/3     3            3           5h22m

 

방금 배포했던 deployment를 수정해도 되지만, 그냥 restart를 해보자

# kubectl rollout restart deployment/rollingupdate-web -n test
deployment.apps/rollingupdate-web restarted

 

restart 후 바로 pod의 생각를 보면

# kubectl get po -n test
NAME                                 READY   STATUS              RESTARTS   AGE
rollingupdate-web-5cf88f8db5-b7bkd   0/1     Terminating         0          33s
rollingupdate-web-5cf88f8db5-bjszq   1/1     Running             0          30s
rollingupdate-web-5cf88f8db5-xmckz   1/1     Running             0          45s
rollingupdate-web-889f46689-4dpvf    1/1     Running             0          5s
rollingupdate-web-889f46689-tclwp    0/1     ContainerCreating   0          1s

# kubectl get po -n test
NAME                                 READY   STATUS        RESTARTS   AGE
rollingupdate-web-5cf88f8db5-xmckz   0/1     Terminating   0          54s
rollingupdate-web-889f46689-4dpvf    1/1     Running       0          14s
rollingupdate-web-889f46689-scttz    1/1     Running       0          7s
rollingupdate-web-889f46689-tclwp    1/1     Running       0          10s

# kubectl get po -n test
NAME                                 READY   STATUS        RESTARTS   AGE
rollingupdate-web-5cf88f8db5-xmckz   0/1     Terminating   0          59s
rollingupdate-web-889f46689-4dpvf    1/1     Running       0          19s
rollingupdate-web-889f46689-scttz    1/1     Running       0          12s
rollingupdate-web-889f46689-tclwp    1/1     Running       0          15s

# kubectl get po -n test
NAME                                READY   STATUS    RESTARTS   AGE
rollingupdate-web-889f46689-4dpvf   1/1     Running   0          115s
rollingupdate-web-889f46689-scttz   1/1     Running   0          108s
rollingupdate-web-889f46689-tclwp   1/1     Running   0          111s

순차적으로 pod들의 상태가 변경됨을 확인할 수 있다.