-
07. 쿠버네티스 핵심 개념 (2)개발 스터디/데브옵스(DevOps)를 위한 쿠버네티스 마스터 2021. 7. 14. 21:16반응형
이 문서는 인프런 강의 "데브옵스를 위한 쿠버네티스 마스터"을 듣고 작성되었습니다. 최대한 요약해서 강의 내용을 최소로 하는데 목표를 두고 있어서, 더 친절하고 정확한 내용을 원하신다면 강의를 구매하시는 것을 추천드립니다. => 강의 링크
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 28sPod도 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-appLabel이 삭제된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개가 다시 추가된 것을 확인할 수 있다. 마지막으로Node1개가 갑자기 에러가 나면 어떻게 될까?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 20sReplicaSet은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 11s10개가 다 올라왔다.
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: 8080kind에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 3StrategyType,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번으로 된 것을 확인할 수 있다. 아무래도 업무가 업무이다 보니 빌드/배포가 잦은데 이게 이렇게 쉽게 되다니 놀라울 따름...
'개발 스터디 > 데브옵스(DevOps)를 위한 쿠버네티스 마스터' 카테고리의 다른 글
09. 쿠버네티스 핵심 개념 (4) (0) 2021.08.05 08. 쿠버네티스 핵심 개념 (3) (0) 2021.07.25 06. 쿠버네티스 핵심 개념 (1) (0) 2021.07.09 05. 쿠버네티스 들어가기 (2) (0) 2021.07.06 04. 쿠버네티스 들어가기 (1) (5) 2021.07.03