[Kubernetes] Deployment Object (디플로이먼트 오브젝트) 와 Rolling Update 전략

Deployment (디플로이먼트)

Deployment 는 ReplicaSet을 포함하고 있는 상위의 컨트롤러이다. Deployment는 컨트롤러나 파드와 같은 어플리케이션을 배포하고 리소스를 이용하여 컨트롤러와 파드를 제어한다. Deployment 의 하위에 ReplicaSet 이 있고, ReplicaSet은 복제된 Pod들을 관리한다. 

주의할 점은 Deployment가 관리하는 ReplicaSet과 복제본 Pod 들이 있는데, ReplicaSet을 직접 제어하지 않고 Deployment 리소스를 통해 관리해야 한다는 점이다. 

복제본 수(replicas)를 2로 지정한 Deployment 오브젝트를 생성하면 다음과 같다. Deployment 1개, ReplicaSet 1개, Pod 2개가 생성되었다. 

Deployment Controller 배포 전략 

Deployment의 배포전략은 레플리카셋과의 가장 큰 차별점이라고 이해했다. 배포 전략은 RollingUpdate 와 Recreate가 있다. 

1. RollingUpdate

기존의 어플리케이션이 배포된 Pod를 점진적으로 교체하면서 새로운 어플리케이션으로 배포하는 전략이다. 

장점: DownTime (서비스가 중단되는 시간)을 가지지 않는다. 서비스를 연속적으로 배포할 수 있다.

단점: 완전히 업데이트가 되지 않은 경우, 문제가 발생할 수 있다. 예를 들어, 클라이언트가 요청할 때, 아직 서버의 업데이트가 끝나지 않은 경우 구버전의 서버와 새로운 버전의 서버가 공존할 것이다. 이 상황에서 Service 오브젝트에 의해 이전 버전 어플리케이션으로 요청이 갈 수도 있고 새로운 버전 어플리케이션으로 요청이 갈 수도 있다.

 

위의 그림은 RollingUpdate가 진행되는 과정을 보여준다. RollingUpdate는 a-b-c-d 순으로 진행된다. 새로운 버전의 pod가 생성된 이후에 구버전의 pod를 지운다. 그리고 새로운 버전 pod 으로 대체한다.  이 과정이 모든 pod 들이 업데이트 될 때까지 점진적으로 진행하게 된다. 

RollingUpdate의 하위 필드는 다음과 같이 지정할 수 있다. 

1) maxUnavailable : 롤링업데이트를 진행하는 중에, 사용할 수 없는 Pod의 개수 또는 percentage를 지정할 수 있다. 기본값은 25%이다. 롤링업데이트는 점진적으로 파드를 하나씩 지워가고 생성하므로 이 작업을 몇개의 파드에 대해 수행할지 정할 수 있는 것이다.

2) maxSurge : 롤링 업데이트를 진행하는 중에서, 새로운 파드를 최대로 생성할 수 있는 수이다. 일시적으로 관리하고자 하는 Pod 개수 이상으로 Pod 가 늘어날 수 있는데, 이때 늘어나는 새로운 Pod의 개수에 대해 제한을 두는 것이 maxSurge 이다 . 기본 값은 25%이다. 

3) minReadySeconds : 컨테이너 최소 대기 시간. 롤링업데이트를 할때 새로운 파드가 배포되고 나서 컨테이너가 실제로 준비되기 위한 대기시간에 대해 설정할 수 있다. 새로운 파드가 바로 지워지지 않고, 실행되기 까지 delay time을 두어 기다리는 것이다. 기본값은 0초 이다. 

2. Recreate

기존의 어플리케이션이 배포된 Pod들을 일시에 모두 삭제하고, 새로운 Pod를 생성하는 전략이다. 

장점: 한번에 업데이트가 다 완료된 후 배포되므로, 버전이 일치할 것이다. 이에 따라 어플리케이션의 버전이 불일치하는 문제는 예방할 수 있다.

단점 : DownTime (서비스 중단 시간) 이 발생할 수밖에 없다. 따라서 DownTime 이 허용되지 않는 서비스의 경우 Recreate 전략을 적용하기 어려울 것이다. ex) 메신저 서비스 

 

Deployment 에 RollingUp 전략을 적용시킨 경우 오브젝트 파일 예시 

apiVersion: apps/v1          
kind: Deployment             
metadata:                    
  name: test-deploy    # deployment name      
  labels:                    # label of deployment 
    app: test-deploy        # key: value
spec:                        
  strategy:                  # deployment strategy 
    type: RollingUpdate      # 서비스 중단 없이 점진적으로 업데이트하기 (RollingUpdate)
    rollingUpdate:           
      maxUnavailable: 1      # 사용할 수 없는 Pod의 최대 개수 
      maxSurge: 1            # 롤링업데이트 중에 새로 생성가능한 Pod최대 개수 
  minReadySeconds: 5       # 즉 총 3+1 어떤 시점에 4개의 파드가 있을 수 있다. 
  replicas: 3                # minReadySeconds: Pod가 생성되고 나서 대기 시간 (초 단위)
  selector:                  
    matchLabels:             # 레플리카셋의 레이블 셀릭터 
      app: test-deploy      
  template:                  # Pod 복제본의 템플릿 
    metadata:                
      labels:                
        app: test-deploy    
    spec:                    
      containers:            
      - image: nginx:latest
        name: myapp          
        ports:               
        - containerPort: 8080

 

Deployment 배포 확인 명령어 

디플로이먼트의 배포 및 롤링업데이트 상태(= rollout 상태)를 확인할 수 있다. 

$kubectl rollout status deployment DEPLOYMENT_NAME

디플로이먼트가 배포된 히스토리를 확인할 수 있다. 

$ kubectl rollout history deployment DEPLOYMENT_NAME

예시)

$ kubectl rollout history deployments myapp-deploy
deployment.apps/myapp-deploy 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         kubectl set image deployments myapp-deploy myapp=ghcr.io/c1t1d0s7/go-myweb:v3.0 --record=true

CHANGE-CAUSE 에 annotation을 남기기 위해서는 업데이트 시에 --record 옵션을 사용하거나, 오브젝트 파일에 annotation 을 지정해줄 수 있다. 

Deployment 롤링 업데이트 관련 명령어 

원하는 버전으로 roll back 할 수 있다. 버전은 rollout history 명령어로 확인할 수 있다. 

$ kubectl rollout undo deployments DEPLOYMENT_NAME --to-version=NUMBER

 

디플로이먼트에서는 간단하게 이미지만 교체하여 버전을 업데이트 할 수 있다

 

$ kubectl set image deployment DEPLOYMENT_NAME CONTAINER_NAME=NEW_IMAGE
$ kubectl set image -f DEPLOYMENT_FILE CONTAINER_NAME=NEW_IMAGE

혹은 오브젝트 파일을 사용하여 업데이트 할 수 있다. 

kubectl apply -f DEPLOYMENT_FILE.yaml

 

Deployment 롤링 업데이트 후 주의사항 

Deployment 버전 업데이트를 진행한 후 , 다음과 같이 껍데기 레플리카셋들이 남아있다. 새로운 버전의 디플로이먼트가 배포되면 새로운 레플리카 셋과 파드들이이 생성되고 기존의 파드들은 지워지게 되기 때문이다.  이 남아있는 레플리카셋을 지우게 되면 이전의 버전으로 돌아갈 수가 없게 된다. 

$ kubectl get replicasets -o wide
NAME                               DESIRED   CURRENT   READY   AGE    CONTAINERS                                                                        
test-deploy-66c777f866             0         0         0       41m     myapp                                                    
test-deploy-7495f5c57b             0         0         0       20m     myapp                                                  
test-deploy-b6449f747              0         0         0       25m     myapp              
test-deploy-d4969fd59              3         3         3       3m39s   myapp