07. 쿠버네티스 핵심 개념 (2)
이 문서는 인프런 강의 "데브옵스를 위한 쿠버네티스 마스터"을 듣고 작성되었습니다. 최대한 요약해서 강의 내용을 최소로 하는데 목표를 두고 있어서, 더 친절하고 정확한 내용을 원하신다면 강의를 구매하시는 것을 추천드립니다. => 강의 링크
ReplicationController
ReplicationController
는 Pod
을 감시하고 있다가 문제가 발생할 때 대체 Pod
을 생성하는 리소스이다.
가용성과 자가 치유를 할 수 있으며, 수동/자동으로 수평 스케일링도 가능하다. ReplicationController
의 필수 요소는 다음과 같다.
- Label Selector
- Replicas
- 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가지이다.
- Recreate
- 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
이제 다음 스크립트를 생성한다.
#!/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번으로 된 것을 확인할 수 있다. 아무래도 업무가 업무이다 보니 빌드/배포가 잦은데 이게 이렇게 쉽게 되다니 놀라울 따름...