[Kubernetes] Rolling Update를 위한 Deployment

Deployment Controller

• Deplyment가 ReplicaSet을 컨트롤해서 Pod 수를 조절
• Deployment → ReplicaSet → Pod
• Rolling update와 Rolling back 지원

 

이전에 배운 ReplicaSet과는 yaml 파일내의 kind 부분만 다르고 나머지는 동일하다.

apiVersion: apps/v1
kind: ReplicaSet -> Deployment
metadata:
  name: rs-mainui
spec:
  replicas: 2
  selector:
    matchLabels:
      name: apache
      app: main
      rel: stable
  template:
    metadata:
      name: httpd-pod
      labels:
        name: apache
        app: main
        rel: stable
    spec:
      containers:
      - name: httpd-container
        image: httpd:2.2

 

dp_nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dp-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.13

kubectl create -f dp_nginx.yaml

위의 파일을 생성 후 create 명령어로 deployment 를 생성한 하면 deploy 컨트롤러가 생성된다.

 

kubectl get deploy,rs,pod

그 후 해당 명령어를 작성하면 아래와 같은 결과를 확인할 수 있는데,

deploy 하나를 생성하면서 replica set과 지정한 수 만큼의 pod가 생성된 것을 확인할 수 있다.

 

그림에서 mydb-node1은 다른 실습때 staticpod로 만든 pod이니 무시하도록한다.

이런 상황에서 pod를 지우면 rs이 pod를 생성하고, rs를 지우면 deploy가 rs를 생성하여 pod의 개수를 보장하게 된다.

 

Rolling Update

 

Rolling Update 란?

파드를 점진적으로 새로운 버전으로 업데이트하여
디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 하는 것

Rolling Update 방법

kubectl set image deployment <deploy_name> <container_name>=<new_version_image>

 

RollBack 방법

kubectl rollout history deployment <deploy_name>

kubectl rollout undo deploy <deploy_name>

 

예시

먼저 앞서 생성한 deploy를 모두 지우고 다시 생성한다.

kubectl create -f dp-nginx.yaml --record

record 옵션은 업데이트 과정을 history로 기록한다.

 

Rolling Update

현재 nginx의 버전은 1.13이다. 아래의 명령어를 통해 확인할 수 있다.

kubectl describe pod pod_name

 

아래의 명령어를 통해 nginx 버전이 1.14로 업데이트 된다.

kubectl set image deployment dp-nginx nginx-container=nginx:1.14 --record

기존 rs의 replicas= 3 이면 새로운 rs를 replicas = 1 로 생성하고 새로운 rs가 컨트롤하는 파드가 완전 실행되면 기존 rs replicas를 2로 줄여서 기존 파드 하나 삭제

기존 파드 완전 삭제되면 다시 새로운 rs의 replicas=2로 수정하여 새로운 파드 생성, 기존 rs replicas를 1로 변경하여 기존 파드 하나 삭제

위의 과정을 반복하여 새로운 버전의 컨테이너로 서비스 중단 없이 rolling update를 가능하게 한다.

rolling update 과정 녹화

[Rollout 과정 컨트롤]

kubectl rollout status deploy dp-nginx

→ rollout 과정 확인

 

kubectl rollout pause deploy dp-nginx

→ rollout 과정 중지

 

kubectl rollout resume deploy dp-nginx

→ rollout 과정 재시작

 

 

• Update 속도 조절
  • maxSurge
    • 예를 들어 replicas가 4이면 rolling update 시 1개씩 차례로 만들며 진행할 수 있다.
      rolling update 중 지정한 pod의 수 이상으로 생성할 수 있는 컨테이너 수를 지정. 기본값은 25%
  • maxUnavailable
    
    • rolling update 중 unavailable 상태의 pod의 최대 개수. 
    • 개수나 퍼센트로 지정할 수 있다.
  • 두 값은 동시에 0이 될 수 없다.

 

• 업데이터 제한 시간 지정
  • progressDeadlineSeconds
    • 지정한 시간 내에 업데이트를 완료하지 못하면 undo

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dp-nginx
  annotations:
    kuberetes.io/change-cause: version 1.13
spec:
  progressDeadlineSeconds: 600
  revisionHistoryLimit: 10
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.13

 

 

Roll Back

히스토리 확인

kubectl rollout history deploy dp-nginx

1.14에서 업데이트를 한 번 더 수행하여 1.15인 것을 history를 통해 확인할 수 있다.

 

kubectl rollout undo deploy dp-nginx

이 명령어를 통해 바로 전 실행 단계(revision)로 돌아갈 수 있고,

 

kubectl rollout undo deploy dp-nginx --to-revision=2

이 명령어처럼 돌아갈 revision을 지정할 수 있다.

 

해당 명령어 입력 후 history를 확인하면 다음과 같은 결과를 출력한다. Revision 번호가 1, 3, 4인 것을 확인하자!

 

 

기록을 파일로 남기며 update 하기

위와 같은 방식으로 rolling update를 하면 기록이 파일로 남지 않는다.

yaml 파일을 이용해서 rolling update를 하는 방법이 있는데, 이렇게 하면 업데이트 과정의 옵션을 쉽게 파악할 수 있을 듯하다. 또한 로그가 간단하다는 장점이 있다.

 

먼저 파일을 두 개 준비한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dp-nginx
  annotations:
    kuberetes.io/change-cause: version 1.14
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14
# dp-nginx14.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dp-nginx
  annotations:
    kubernetes.io/change-cause: version 1.15
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.15
# dp-nginx15.yaml

 

그리고 아래 명령어들을 차례로 입력하며 과정을 확인해보면 된다.

kubectl delete deployment --all

kubectl apply -f dp-nginx14.yaml

kubectl apply -f dp-nginx15.yaml

kubectl rollout history deploy dp-nginx

앞서 조회한 히스토리보다 change-cause가 간단한 것을 확인할 수 있다.

 

create 와 apply의 차이

create : 새로운 리소스 생성
replace : 실행 중인 클러스터 업데이트
apply : create + replace

https://stackoverflow.com/questions/47369351/kubectl-apply-vs-kubectl-create