07. 쿠버네티스 핵심 개념 (2)

이 문서는 인프런 강의 "데브옵스를 위한 쿠버네티스 마스터"을 듣고 작성되었습니다. 최대한 요약해서 강의 내용을 최소로 하는데 목표를 두고 있어서, 더 친절하고 정확한 내용을 원하신다면 강의를 구매하시는 것을 추천드립니다. => 강의 링크

ReplicationController

ReplicationController는 Pod을 감시하고 있다가 문제가 발생할 때 대체 Pod을 생성하는 리소스이다.

가용성과 자가 치유를 할 수 있으며, 수동/자동으로 수평 스케일링도 가능하다. ReplicationController의 필수 요소는 다음과 같다.

1. Label Selector
2. Replicas
3. Pod Template

어떻게 설정할 수 있는지 살펴보자

 

src/ch07/k8s/simple-app-rc-v1.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: simple-app
spec:
  replicas: 3
  selector:
    app: simple-app
  template:
    metadata:
      name: simple-app
      labels:
        app: simple-app
    spec:
      containers:
      - name: simple-app
        image: gurumee92/simple-app:v1
        ports:
        - containerPort: 8080

 

 

위 코드에서 제일 먼저 살펴볼 부분은 kind이다

 

src/ch07/k8s/simple-app-rc-v1.yaml

apiVersion: v1
kind: ReplicationController
# ...

 

여기서 리소스 종류를 ReplicationController를 지정한다. 그 후 spec을 살펴보자.

 

src/ch07/k8s/simple-app-rc-v1.yaml

# ...
spec:
  replicas: 3
  selector:
    app: simple-app
  template:
    # ...

 

아까 말한 3가지 요소가 위의 코드에 작성되어있다. replicas는 관리할 Pod의 총 개수를 뜻한다. 그리고 selector는 해당 Label을 지닌 Pod을 관리 대상으로 한다. 즉, template에 작성된 label과 selector는 반드시 동일해야 한다.

 

src/ch07/k8s/simple-app-rc-v1.yaml

# ...
spec:
  # ...
  # template > metadata > labels와 일치해야 함.
  selector:
    app: simple-app
  template:
    metadata:
      name: simple-app
      # selector와 일치해야 함.
      labels:
        app: simple-app
    # ...

 

그리고 template은 기존에 Pod을 알아보면서 작성했던 코드와 동일하다. 이제 다음 명령어를 이용하여 리소스를 생성해보자.

# resource create
$ kubectl create -f simple-app-rc-v1.yaml 
replicationcontroller/simple-app created

# replicationController monitoring
$ kubectl get rc -w
NAME         DESIRED   CURRENT   READY   AGE
simple-app   3         3         0       7s
# -w 옵션으로 인해 변경되는 모습을 확인 할 수 있다.
simple-app   3         3         1       19s
simple-app   3         3         2       21s
simple-app   3         3         3       28s

 

Pod도 3개가 띄어져 있는지 확인해보자.

$ k get pod -o wide
NAME               READY   STATUS    RESTARTS   AGE   IP          NODE     NOMINATED NODE   READINESS GATES
simple-app-bplk4   1/1     Running   0          97s   10.32.0.3   slave2   <none>           <none>
simple-app-jnmt7   1/1     Running   0          97s   10.40.0.2   slave1   <none>           <none>
simple-app-rbrcd   1/1     Running   0          97s   10.32.0.4   slave2   <none>           <none>

 

각 노드에 잘 분배되서 띄어진 것을 확인할 수 있다. 이제 한 번 한 Pod의 Label을 삭제해보자

# pod 1개 레이블 삭제
$ kubectl label pod simple-app-bplk4 app-
pod/simple-app-bplk4 labeled

이제 다음 명령어를 입력해보자.

$ kubectl get pod --show-labels
NAME               READY   STATUS    RESTARTS   AGE     LABELS
simple-app-bplk4   1/1     Running   0          9m24s   <none>
simple-app-jnmt7   1/1     Running   0          9m24s   app=simple-app
simple-app-rbrcd   1/1     Running   0          9m24s   app=simple-app
simple-app-sztjq   1/1     Running   0          11s     app=simple-app

 

Label이 삭제된 Pod은 그대로 실행중이나 Label "app" 을 가진 Pod은 3개로 유지되었다. 시간을 보면 simple-app-sztjq은 띄어진지 얼마 안된 것을 확인할 수 있다. 이는 ReplicationController가 Pod의 Label이 삭제되었음을 감지해서 app=simple-app을 가진 Pod의 개수를 3개로 유지하기 위해서 1개를 새로 만든 것을 보여준다.

 

이번엔 Pod을 아예 하나 삭제해보자.

$ kubectl delete pod simple-app-jnmt7
pod "simple-app-jnmt7" deleted

 

자 이제 터미널에 다음을 입력해서 Pod개수를 확인해보자.

$ kubectl get pod -o wide
NAME               READY   STATUS    RESTARTS   AGE     IP          NODE     NOMINATED NODE   READINESS GATES
simple-app-47hhw   1/1     Running   0          12s     10.32.0.5   slave2   <none>           <none>
simple-app-bplk4   1/1     Running   0          13m     10.32.0.3   slave2   <none>           <none>
simple-app-rbrcd   1/1     Running   0          13m     10.32.0.4   slave2   <none>           <none>
simple-app-sztjq   1/1     Running   0          4m16s   10.40.0.3   slave1   <none>           <none>

 

4개이다. 삭제된 Pod이 없는 것을 보니 역시 ReplicationController가 이를 감지하고 복구한 것을 확인할 수 있다. 이를 확인하기 위해서 터미널에 다음을 입력해보자.

$ kubectl describe replicationcontrollers simple-app 
Name:         simple-app
Namespace:    default
Selector:     app=simple-app
Labels:       app=simple-app
Annotations:  <none>
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=simple-app
  Containers:
   simple-app:
    Image:        gurumee92/simple-app:v1
    Port:         8080/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age    From                    Message
  ----    ------            ----   ----                    -------
  Normal  SuccessfulCreate  16m    replication-controller  Created pod: simple-app-bplk4
  Normal  SuccessfulCreate  16m    replication-controller  Created pod: simple-app-jnmt7
  Normal  SuccessfulCreate  16m    replication-controller  Created pod: simple-app-rbrcd
  Normal  SuccessfulCreate  7m46s  replication-controller  Created pod: simple-app-sztjq
  Normal  SuccessfulCreate  3m42s  replication-controller  Created pod: simple-app-47hhw

 

처음에 총 3개가 만들어지고 그 이후에 Label을 제거했을 때 1개, Pod이 제거되었을 때 1개가 다시 추가된 것을 확인할 수 있다. 마지막으로 Node 1개가 갑자기 에러가 나면 어떻게 될까? Slave2(data-node2)를 한 번 네트워크에서 제거해보자.

$ kubectl get node -w
NAME     STATUS   ROLES                  AGE   VERSION
master   Ready    control-plane,master   10d   v1.21.2
slave1   Ready    <none>                 10d   v1.21.2
slave2   Ready    <none>                 10d   v1.21.2
# 떨어져 나간 것을 확인할 수 있다.
slave2   NotReady   <none>                 10d   v1.21.2

 

이제 한 번 터미널에 다음을 입력하고 5분을 기다려보자.

$ kubectl get pod -o wide -w
NAME               READY   STATUS               RESTARTS   AGE    IP          NODE     NOMINATED NODE   READINESS GATES
simple-app-47hhw   1/1     Running              0          7m7s   10.32.0.5   slave2   <none>           <none>
simple-app-bplk4   1/1     Running              0          20m    10.32.0.3   slave2   <none>           <none>
simple-app-rbrcd   1/1     Running              0          20m    10.32.0.4   slave2   <none>           <none>
simple-app-sztjq   1/1     Running              0          11m    10.40.0.3   slave1   <none>           <none>
# 5분 후
simple-app-47hhw   1/1     Terminating          0          11m    10.32.0.5   slave2   <none>           <none>
simple-app-rbrcd   1/1     Terminating          0          24m    10.32.0.4   slave2   <none>           <none>
simple-app-bplk4   1/1     Terminating          0          24m    10.32.0.3   slave2   <none>           <none>
simple-app-f7vhl   0/1     Pending              0          0s     <none>      <none>   <none>           <none>
simple-app-f7vhl   0/1     Pending              0          0s     <none>      slave1   <none>           <none>
simple-app-t2lb2   0/1     Pending              0          0s     <none>      <none>   <none>           <none>
simple-app-f7vhl   0/1     ContainerCreating    0          0s     <none>      slave1   <none>           <none>
simple-app-t2lb2   0/1     Pending              0          0s     <none>      slave1   <none>           <none>
simple-app-t2lb2   0/1     ContainerCreating    0          0s     <none>      slave1   <none>           <none>
simple-app-f7vhl   1/1     Running              0          3s     10.40.0.2   slave1   <none>           <none>
simple-app-t2lb2   1/1     Running              0          3s     10.40.0.4   slave1   <none>           <none>

 

5분 후에 Slave2에 있던 Pod들이 Terminating 상태로 변경되고 Slave1에 2개가 새롭게 생성된다. 노드의 인터넷을 복구하면 5분 후에 다시 Pod을 노드에 골고루 재배치하는 것을 확인할 수 있다. 나는 리소스가 충분하기에 Slave1에 몰려있는 채로 운영된다.

$ kubectl get pod -o wide
NAME               READY   STATUS    RESTARTS   AGE     IP          NODE     NOMINATED NODE   READINESS GATES
simple-app-f7vhl   1/1     Running   0          8m57s   10.40.0.2   slave1   <none>           <none>
simple-app-sztjq   1/1     Running   0          24m     10.40.0.3   slave1   <none>           <none>
simple-app-t2lb2   1/1     Running   0          8m57s   10.40.0.4   slave1   <none>           <none>

 

왜 5분일까? 기본적으로 ReplicationController는 쿠버네티스 클러스터에서 어떤 노드가 변경되면 5분을 기다린다. 그 이전에 변경된걸 감지해서 컨테이너를 재배치할 수가 있다. 그러나 그렇게 할 경우, 트래픽이 몰려서 리소스가 부족한 경우에도 노드가 죽은 줄 알고 바로 Pod들을 복구하고 이게 반복이 되면 모든 노드가 리소스가 부족해지고 결국 클러스터가 망가진다.

 

따라서 시간 조절은 가능하지만 최대한 위의 상황은 벌어지지 않도록 조절해주는 것이 중요하다.

ReplicaSet

ReplicaSet은 ReplicationController의 새로운 버전이다. 쿠버네티스 버전 1.8 이후에 보다 운영을 쉽게 하기 위해서 다음 4개의 리소스를 추가하였다.

• Deployment
• ReplicaSet
• StatefulSet
• DaemonSet

그 중 ReplicaSet은 ReplicationController처럼 Pod의 개수를 관리하며, 더 강력한 레이블 매칭을 지원한다. 개인적으론 둘 다 비슷하다. 하지만 ReplicaSet은 Deployment라는 상위 리소스에 관리 받는다는 큰 차이점이 있다. 먼저 다음과 같이 작성해보자.

 

src/ch07/k8s/simple-app-rs-v1.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: simple-app-rs
  labels:
    app: simple-app
spec:
  replicas: 3
  selector:
    matchExpressions:
    - {key: app, operator: In, values: [simple-app]}
  template:
    metadata:
      labels:
        app: simple-app
    spec:
      containers:
      - name: simple-app
        image: gurumee92/simple-app:v1
        ports:
        - containerPort: 8080

 

거의 비슷하다. apiVersion, kind가 바뀌었고 selector에 이상한 표현식을 사용할 수 있다. 역시 다음 명령어로 리소스를 생성할 수 있다.

$ kubectl create -f simple-app-rs-v1.yaml 
replicaset.apps/simple-app-rs created

 

그 후 ReplicaSet을 확인하려면 다음 명령어를 입력하면 된다.

$ kubectl get rs simple-app-rs 
NAME            DESIRED   CURRENT   READY   AGE
simple-app-rs   3         3         3       45s

 

이제 Pod도 확인해보자.

$ kubectl get pod
NAME                  READY   STATUS    RESTARTS   AGE
simple-app-rs-gktlj   1/1     Running   0          20s
simple-app-rs-lxv2h   1/1     Running   0          20s
simple-app-rs-wvxzz   1/1     Running   0          20s

 

ReplicaSet은 ReplicationController가 할 수 있는 모든 것을 똑같이 할 수 있다. 이번 절에서는 스케일하는 방법을 알아보자. 먼저 명령어 kubectl scale rs로 스케일 할 수 있다.

$ kubectl scale rs simple-app-rs --replicas=5
replicaset.apps/simple-app-rs scaled

 

터미널에 다음을 입력하면 늘어난 Pod 개수를 확인할 수 있다.

$ kubectl get pod
NAME                  READY   STATUS    RESTARTS   AGE
simple-app-rs-8vbqz   1/1     Running   0          4s
simple-app-rs-gktlj   1/1     Running   0          2m30s
simple-app-rs-lxv2h   1/1     Running   0          2m30s
simple-app-rs-w5x8d   1/1     Running   0          4s
simple-app-rs-wvxzz   1/1     Running   0          2m30s

 

또한 kubectl edit rs 명령어로도 스케일이 가능하다

$ kubectl edit rs simple-app-rs

 

이 명령어를 치면 vim이 켜진다.

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  creationTimestamp: "2021-07-13T12:11:30Z"
  generation: 2
  labels:
    app: simple-app
  name: simple-app-rs
  namespace: default
  resourceVersion: "23912"
  uid: d27082ab-baa3-4a3f-8ef4-155a305626cd
spec:
  # 이 부분을 2로 줄여보자.
  replicas: 5
  selector:
    matchExpressions:
    - key: app
      operator: In
      values:
      - simple-app
  template:
...

 

저 부분에서 spec 밑에 replicas 개수를 5에서 2로 줄여보자.

$ kubectl edit rs simple-app-rs 
# vim에서 돌아오면
replicaset.apps/simple-app-rs edited

 

이제 Pod 개수가 줄어드나 확인해보자.

$ kubectl get pod
NAME                  READY   STATUS    RESTARTS   AGE
simple-app-rs-gktlj   1/1     Running   0          7m20s
simple-app-rs-wvxzz   1/1     Running   0          7m20s

 

마지막으로 바꿔치는 방법이 있다.

$ cp simple-app-rs-v1.yaml simple-app-rs-v2.yaml

 

그 후 simple-app-rs-v2.yaml을 다음처럼 replicas를 10개로 지정한다.

 

src/ch07/k8s/simple-app-rs-v2.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: simple-app-rs
  labels:
    app: simple-app
spec:
  replicas: 10
  selector:
    matchExpressions:
    - {key: app, operator: In, values: [simple-app]}
  template:
    metadata:
      labels:
        app: simple-app
    spec:
      containers:
      - name: simple-app
        image: gurumee92/simple-app:v1
        ports:
        - containerPort: 8080

 

그 후 터미널에 다음을 입력한다.

$ kubectl apply -f simple-app-rs-v2.yaml
Warning: resource replicasets/simple-app-rs is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
replicaset.apps/simple-app-rs configured

 

뭐라 경고문이 뜨지만 무시하자. 터미널에 다음을 입력해서 Pod 개수를 확인해보자.

$ kubectl get pod
NAME                  READY   STATUS    RESTARTS   AGE
simple-app-rs-4srcc   1/1     Running   0          11s
simple-app-rs-gktlj   1/1     Running   0          10m
simple-app-rs-jhjh2   1/1     Running   0          11s
simple-app-rs-ph75k   1/1     Running   0          11s
simple-app-rs-r9pkh   1/1     Running   0          11s
simple-app-rs-s6wwm   1/1     Running   0          11s
simple-app-rs-wvxzz   1/1     Running   0          10m
simple-app-rs-x5hkl   1/1     Running   0          11s
simple-app-rs-z7bl5   1/1     Running   0          11s
simple-app-rs-zb5pb   1/1     Running   0          11s

 

10개가 다 올라왔다.

Deployment

Deployment는 ReplicaSet의 상위 개념이며 일반적으로 위에처럼 ReplicaSet을 바로 생성하는 것이 아닌 Deployment를 생성해서 ReplicaSet을 자동으로 생성하게끔 만든다.

뭐 만드는 방법은 비슷하다.

 

src/ch07/k8s/simple-app-dep.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: simple-app-dep
  labels:
    app: simple-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: simple-app
  template:
    metadata:
      labels:
        app: simple-app
    spec:
      containers:
      - name: simple-app
        image: gurumee92/simple-app:v1
        ports:
        - containerPort: 8080

 

kind에 Deployment가 할당되었고 나머지 템플릿은 RepliaSet 만들 듯이 만들면 된다. 한 번 다음을 입력해서 만들어보자.

$ kubectl create -f simple-app-dep.yaml

 

그 후 다음을 입력해서 세부 내용을 확인해보자.

$ kubectl describe deployment simple-app-dep
Name:                   simple-app-dep
Namespace:              default
CreationTimestamp:      Wed, 14 Jul 2021 20:11:15 +0900
Labels:                 app=simple-app
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=simple-app
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=simple-app
  Containers:
   simple-app:
    Image:        gurumee92/simple-app:v1
    Port:         8080/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   simple-app-dep-5d4c8d678b (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  52s   deployment-controller  Scaled up replica set simple-app-dep-5d4c8d678b to 3

 

StrategyType, RollingUpdateStrategy 같은 것이 나와 있다. 이게 Deployment의 업데이트 전략인데 이는 다음 절에서 자세히 알아보자.

Deployment 롤링 업데이트 해보기

 

Deployment가 좋은 것은 바로 업데이트 전략에 있다. ReplicationController의 경우 버전 업데이트가 있으면 수동으로 명령해서 업데이트를 해주어야 했다. 다운타임도 생각보다 존재했으며, 실수가 생길 수 있다. 하지만 Deployment는 여기까지 자동화를 지원해준다. 버전 업데이트 전략은 크게 2가지이다.

1. Recreate
2. RollingUpdate

Recreate 전략은 모든 Pod을 제거한 후 새로운 Pod으로 갈아치우는 전략이다. 다운타임이 생기는 업데이트이지만 클러스터의 부하가 매우 적다. 따라서 사람이 들어오지 않는 새벽 혹은 서버 점검 시간이 주어졌을 때 버전 업데이트를 해야 하는 경우, 이 전략을 추천한다. 반면 RollingUpdate는 다운 타임 없이 버전을 업데이트한다. 하지만 Recreate보다는 부하가 큰 편이다. 이렇게 하면 잘 안와닿으니까 그림을 살펴보자.

이렇게 Pod들이 구성되었다고 해보자. 이제 버전 업데이트를 해야 하는 상황이다. 어떻게 될까?

먼저 새 버전의 Pod이 하나 생성된다. 그리고 같은 노드에 있던 오래된 Pod이 제거된다.

이렇게 순차적으로 구성된 노드에서 오래된 Pod들을 새로운 Pod으로 갈아치운다.

결국 이렇게 모든 Pod들이 새롭게 버전 업데이트가 되는 것이다. 이제 실제로 업데이트를 진행해보자. 먼저 Deployment를 삭제한 후 다시 만든다.

# yaml 파일 작성 후 Deployment 실행
$ kubectl create -f simple-app-dep.yaml --record=true

 

중요한 게 하나 있다. 업데이트 이력을 확인하려면 --record=true 옵션을 지정해주어야 한다. 이제 외부에 Curl을 입력해서 결과를 확인하기 위해서 다음과 같이 Service를 생성해둔다.

$ kubectl expose deployment simple-app-dep --name simple-app-svc --type=LoadBalancer --port=8080

 

그 다음 Service가 EXTERNAL-IP가 생성될 때까지 기다린다.

$ kubectl get svc simple-app-svc -w
NAME             TYPE           CLUSTER-IP   EXTERNAL-IP      PORT(S)          AGE
simple-app-svc   LoadBalancer   10.8.12.56   <pending>        8080:30081/TCP   19s
# 기다리면 다음이 출력된다.
simple-app-svc   LoadBalancer   10.8.12.56   35.198.197.192   8080:30081/TCP   52s

 

이제 다음 스크립트를 생성한다.

 

src/ch07/scripts/test.sh

#!/bin/bash
while true
do
    # <CLUSTER_IP>
    curl 35.198.197.192:8080 
    sleep 1
done

 

그 후 로컬 머신에서 다음 명령어를 입력해보자.

$ bash scripts/test.sh
Hello World v1Hello World v1Hello World v1Hello World v1Hello World v1Hello World v1....

 

이제 터미널에 다음을 입력해보자.

$ kubectl patch deploy simple-app-dep -p '{"spec": {"minReadySeconds": 10}}'
deployment.apps/simple-app-dep patched

 

이는 업데이트 되는 것을 잘 확인하기 위해서 속도를 일부러 늦춘 것이다. 이제 업데이트를 해보자. 터미널에 다음을 입력한다.

$ kubectl set image deploy simple-app-dep simple-app=gurumee92/simple-app:v2 --record-true
deployment.apps/simple-app-dep image updated

 

역시 --record=true를 꼭 붙여주어야 한다. 이제 curl 결과를 확인해보자.

...
Hello World v1Hello World v2Hello World v2Hello World v2Hello World v1Hello World v1Hello World v1Hello World v2Hello World v1Hello World v2Hello World v1Hello World v2Hello World v2Hello World v2Hello World v1Hello World v1Hello World v2Hello World v2Hello World v1Hello World v2...

 

잘 보면 어느 순간 v2가 출현하더니 출현 비율이 점점 높아지다가 완전히 v2만 보이게 된다. 이 떄 이 비율은 RollingUpdateStrategy의 maxSurge와 maxUnavailable의 설정에 영향을 받게 된다. maxSurge는 최대 추가로 배포되는 Pod의 개수 혹은 비율, maxUnavailable은 최소로 유지되는 Pod의 개수 혹은 비율을 나타낸다. 이제 변경 이력을 확인해보자.

$ kubectl rollout history deploy simple-app-dep
deployment.apps/simple-app-dep
REVISION  CHANGE-CAUSE
1         kubectl create --filename=simple-app-dep.yaml --record=true
2         kubectl set image deploy simple-app-dep simple-app=gurumee92/simple-app:v2 --record=true

 

이렇게 변경 이력을 확인할 수 있다. 이제 다른 방식으로 또 버전 업데이트를 해보자. 터미널에 다음을 입겨한다.

$ kubectl edit deploy simple-app-dep --record=true

 

그럼 vim이 켜지면서 다음이 출력된다.

$ kubectl edit deploy simple-app-dep --record=true

 

여기서 빗금친 곳, 이미지를 명시하는 곳에 v2에서 v3로 변경해준다. 그럼 curl에서 다시 결과를 확인할 수 있다.

...
Hello World v2Hello World v2Hello World v2Hello World v3Hello World v2Hello World v2Hello World v3Hello World v2Hello World v3Hello World v3Hello World v2Hello World v3Hello World v3Hello World v3Hello World v2Hello World v3Hello World v2Hello World v2Hello World v3Hello World v3Hello World v3Hello World v3Hello World v2Hello World v2Hello World v2Hello World v3Hello World ...

 

역시 v3로 변경되는 것을 확인할 수 있다. 역시 업데이트 이력을 확인해보자.

$ kubectl rollout history deploy simple-app-dep
deployment.apps/simple-app-dep
REVISION  CHANGE-CAUSE
1         kubectl create --filename=simple-app-dep.yaml --record=true
2         kubectl set image deploy simple-app-dep simple-app=gurumee92/simple-app:v2 --record=true
3         kubectl edit deploy simple-app-dep --record=true

 

이렇게 3개의 이력이 남았다. 쿠버네티스가 좋은 점은 업데이트 말고도 롤백도 손쉽게 할 수 있다는 것이다. 이제 v3를 다시 v2로 롤백해보자.

$ kubectl rollout undo deploy simple-app-dep
deployment.apps/simple-app-dep rolled back

 

그럼 다시 curl 결과를 확인하면 v2로 변경되는 것을 확인할 수 있다.

...
Hello World v3Hello World v2Hello World v3Hello World v3Hello World v2Hello World v3Hello World v3Hello World v2Hello World v2Hello World v3Hello World v3Hello World v2...

 

이제 다시 변경 이력을 확인해보자.

$ kubectl rollout history deploy simple-app-dep
deployment.apps/simple-app-dep
REVISION  CHANGE-CAUSE
1         kubectl create --filename=simple-app-dep.yaml --record=true
3         kubectl edit deploy simple-app-dep --record=true
4         kubectl set image deploy simple-app-dep simple-app=gurumee92/simple-app:v2 --record=true

 

변경 이력 2번이 4번이 된 것을 확인할 수 있다. 이제 롤백할 버전을 지정해서 롤백해보자.

$ kubectl rollout undo deploy simple-app-dep --to-revision=1
deployment.apps/simple-app-dep rolled back

 

이제 다시 curl 결과를 보면 v2에서 v1으로 버전이 내려간 것을 확인할 수 있다.

...
Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v2Hello World v1Hello World v1Hello World v2Hello World v2Hello World v1Hello World v2Hello World v2Hello World v1Hello World v1Hello World v1Hello World v2Hello World v1Hello World v1Hello World v2Hello World v1
...

 

다시 한번 변경 이력을 확인해보자.

$ kubectl rollout history deploy simple-app-dep
deployment.apps/simple-app-dep
REVISION  CHANGE-CAUSE
3         kubectl edit deploy simple-app-dep --record=true
4         kubectl set image deploy simple-app-dep simple-app=gurumee92/simple-app:v2 --record=true
5         kubectl create --filename=simple-app-dep.yaml --record=true

 

변경 이력 1번이 5번으로 된 것을 확인할 수 있다. 아무래도 업무가 업무이다 보니 빌드/배포가 잦은데 이게 이렇게 쉽게 되다니 놀라울 따름...