[Container Management] Kubernetes 애플리케이션 관리

본 포스팅에서는 Kubernetes Application 관리 가이드에 대해 살펴보겠습니다.

Kubernetes의 다양한 기능 중 이미지를 관리할 수 있는 것은 굉장히 중요한 장점 중 하나입니다.

지난 Kubernetes 가이드는 아래를 참고하세요.

 

[Container Management] Kubernetes Master Node 설치

[Container Management] Kubernetes Dashboard Install & Setting

[Container Management] Kubernetes Woker Node Install & Setting

[Container Management] Kubernetes Pod 생성 가이드

[Container Management] Kubernetes Service 생성 가이드

Kubernetes Image 버전 업데이트

먼저 Image 버전 업데이트에 대해 살펴보겠습니다.

1. 신규 2.0 버전을 다운로드 받아 기존 이미지에 업데이트 하는 방식으로 진행됩니다.

[root@guruson ~]# docker tag docker.io/springio/gs-spring-boot-docker:latest nara0617/gs-spring-boot-docker:2.0  
[root@guruson ~]# docker images | grep spring 
docker.io/springio/gs-spring-boot-docker                 latest              3a7a85f42b64        2 years ago         181 MB 
nara0617/gs-spring-boot-docker                           2.0                 3a7a85f42b64        2 years ago         181 MB 
nara0617/gs-spring-boot-docker                           latest              3a7a85f42b64        2 years ago         181 MB 
[root@guruson ~]# docker push nara0617/gs-spring-boot-docker:2.0  
The push refers to a repository [docker.io/nara0617/gs-spring-boot-docker] 
d89696c8d8f7: Layer already exists  
8ed4ebdc2a2b: Layer already exists  
2fd640341bb9: Layer already exists  
5bef08742407: Layer already exists  
2.0: digest: sha256:879e37e16545d45391f30e5559dface8d90636ab330b546fa53d3ae79dfed545 size: 1163 
[root@guruson ~]#

위와 같이 이미지 push가 완료되면 docker image를 업데이트합니다. 

[root@guruson ~]# kubectl set image deployment/gs-spring-boot-docker-deployment gs-spring-boot-docker=nara0617/gs-spring-boot-docker:2.0 --record 
deployment.extensions/gs-spring-boot-docker-deployment image updated
[root@guruson ~]# kubectl get pods
NAME                                                READY     STATUS             RESTARTS   AGE
gs-spring-boot-docker-deployment-566f54d69d-w6ccc   0/1       ContainerCreating  0          3s
gs-spring-boot-docker-deployment-7455d748bc-2rlgb   1/1       Running            0          3h9m
[root@guruson ~]# kubectl get pods
NAME                                                READY     STATUS             RESTARTS   AGE
gs-spring-boot-docker-deployment-566f54d69d-w6ccc   1/1       Running            0          32s
gs-spring-boot-docker-deployment-7455d748bc-2rlgb   1/1       Terminating        0          3h9m
[root@guruson ~]# kubectl get pods
NAME                                                READY     STATUS             RESTARTS   AGE
gs-spring-boot-docker-deployment-566f54d69d-w6ccc   1/1       Running            0          45s
[root@guruson ~]#

Pod를 업데이트 하는 동안 발생 가능한 Down Time을 없애기 위해 Pod는 2개 이상을 유지하며 Pod의 Rolling Update기능을 사용하여 순차적 업데이트를 진행합니다.

변경된 Deployment Application을 반영하는 과정은 ContainerCreating => Running 상태로 변경되면, 기존 버전의 Deployment Application은 Terminating을 시작합니다.

[root@guruson ~]# kubectl get rs
NAME                                          DESIRED   CURRENT   READY     AGE
gs-spring-boot-docker-deployment-566f54d69d   1         1         1         6m20s
gs-spring-boot-docker-deployment-7455d748bc   0         0         0         3h15m
[root@guruson ~]# 

위와 같이 Deployment는 삭제되었지만, 이후 RollBack 용도로 사용할 수 있도록 Replica Set 정보는 그대로 유지합니다.

2. 변경된 버전 확인

- 버전 변경에 대한 History는 다음과 같이 kubectl rollout history 명령어로 확인이 가능합니다.

[root@guruson ~]# kubectl rollout history deployment/gs-spring-boot-docker-deployment 
deployment.extensions/gs-spring-boot-docker-deploymentdeployments "gs-spring-boot-docker-deployment"
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image deployment/gs-spring-boot-docker-deployment gs-spring-boot-docker=nara0617/gs-spring-boot-docker:2.0 --record=true

[root@guruson ~]#

 또한 수행된 Revision에 대한 명령어 상세 기록을 확인할 수 있습니다.

[root@guruson ~]# kubectl rollout history deployment/gs-spring-boot-docker-deployment --revision=2
deployments "gs-spring-boot-docker-deployment" with revision #2
Pod Template:
  Labels:       app=gs-spring-boot-docker
        pod-template-hash=566f54d69d
  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/gs-spring-boot-docker-deployment gs-spring-boot-docker=nara0617/gs-spring-boot-docker:2.0 --record=true
  Containers:
   gs-spring-boot-docker:
    Image:      nara0617/gs-spring-boot-docker:2.0
    Port:       8080/TCP
    Host Port:  0/TCP
    Limits:
      cpu:      500m
      memory:   1Gi
    Requests:
      cpu:      200m
      memory:   256Mi
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

[root@guruson ~]#

Kubernetes Image 버전 롤백

다음으로 Image 버전 Rollback 방법에 대해 살펴보겠습니다.

1. undo로 Rollback하기

[root@guruson ~]# kubectl rollout undo deployment/gs-spring-boot-docker-deployment 
deployment.extensions/gs-spring-boot-docker-deployment
[root@guruson ~]#

- 기존 Container로 변경된 것을 확인할 수 있습니다.

2. --to-revision으로 Rollback하기

[root@guruson ~]# kubectl rollout undo deployment/gs-spring-boot-docker-deployment --to-revision=2
deployment.extensions/gs-spring-boot-docker-deployment
[root@guruson ~]#

- 위와 같이 undo를 실행할 때 --to-revision을 명시하여 해당 버전으로 Rollback을 수행할 수 있습니다.

Kubernetes Image 버전 삭제

마지막으로 애플리케이션 삭제 과정에 대해 살펴보겠습니다.

1. deployment name으로 삭제하기

[root@guruson ~]# kubectl get deploy
NAME                               READY     UP-TO-DATE   AVAILABLE   AGE
apache-docker-deployment           1/1       1            1           7h10m
gs-spring-boot-docker-deployment   1/1       1            1           3h28m
[root@guruson ~]# kubectl delete deployment apache-docker-deployment
deployment.extensions "apache-docker-deployment" deleted
[root@guruson ~]# kubectl get deploy
NAME                               READY     UP-TO-DATE   AVAILABLE   AGE
gs-spring-boot-docker-deployment   1/1       1            1           3h28m
[root@guruson ~]#

- 위와같이 정상적으로 deploy가 제거된 것을 확인할 수 있습니다.

2. yaml 파일로 삭제하기

[root@guruson ~]# kubectl get deploy
NAME                               READY     UP-TO-DATE   AVAILABLE   AGE
gs-spring-boot-docker-deployment   1/1       1            1           3h28m
[root@guruson springBootDocker]# kubectl delete -f ./gs-spring-boot-docker-deployment.yaml 
deployment.apps "gs-spring-boot-docker-deployment" deleted 
[root@guruson ~]# kubectl get deployment 
No resources found. 
[root@guruson ~]# 

- 마찬가지로 정상적으로 deployment가 제거된 것을 볼 수 있습니다.

Kubernetes Image Rolling Update

1. Rolling Update 관련 deployment yaml 파일을 작성합니다.

apiVersion: apps/v1beta1 # for versions before 1.8.0 use apps/v1beta1
kind: Deployment
metadata:
  name: gs-spring-boot-docker-deployment
  labels:
    app: gs-spring-boot-docker
spec:
  replicas: 3
  minReadySeconds: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: gs-spring-boot-docker
  template:
    metadata:
      labels:
        app: gs-spring-boot-docker
    spec:
      containers:
      - name: gs-spring-boot-docker
        image: dtlabs/gs-spring-boot-docker:1.0
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

- 생성 방법은 cli 또는 대시보드에서 생성할 수 있습니다. 이전 포스팅을 참고하시구요.

Rolling Update 관련 주요 설정은 다음과 같습니다.

---

- spec.strategy : RollingUpdate에 대한 상세 설정을 합니다.

- spec.strategy.type

“Recreate” or “RollingUpdate”를 설정 가능 합니다. 기본값은 “RollingUpdate” 입니다. Recreate의 경우 Pod가 삭제된 후 재생성 됩니다.

- spec.strategy.rollingUpdate

spec.strategy.type에서 “RollingUpdate”를 설정한 경우, RollingUpdate에 대한 상세 설정을 합니다.

- spec.strategy.rollingUpdate.maxSurge rolling update 중 정해진 Pod 수 이상으로 만들 수 있는 Pod의 최대 개수입니다. 기본값은 25% 입니다.

- spec.strategy.rollingUpdate.maxUnavailable

rolling update 중 unavailable 상태인 Pod의 최대 개수를 설정 합니다. rollgin update 중 사용할 수 없는 Pod의 최대 개수입니다. 값은 0보다 큰 정수를 통해 Pod의 절대 개수 설정이 가능하고, “25%“와 같이 percentage 표현 또한 가능합니다.

maxUnavailable에서 percentage 계산은 rounding down(내림) 방식이며 기본값은 25% 입니다.

maxSurge와 maxUnavailable 값이 동시에 0이 될 수는 없습니다.

replica: 3인 경우, 25%는 0.75개 이지만, 최소값이 1이기 때문에 maxUnavailable은 1개로 계산 됩니다.

replica: 9인 경우, 25%는 2.25개 이지만, rounding down(내림) 하여 maxUnavailable은 2개로 계산 됩니다.

---

이번 포스팅에서는 Kubernetes Application Image 버전 관리를 위한 Update와 Rollback 그리고 삭제 과정에 대해 살펴보았습니다.