개인 프로젝트_Kubernetes Application Update
최종 영상 구조
10분 내외로 맞추려면 이렇게 진행하면 좋아.
| 시간 | 슬라이드 | 내용 |
|---|---|---|
| 0:00 ~ 0:25 | 1장 | 주제 소개 |
| 0:25 ~ 0:45 | 2장 | 세 가지 배포 전략 비교 |
| 0:45 ~ 2:20 | 3~4장 | Blue/Green 설명 및 실습 |
| 2:20 ~ 3:50 | 5~6장 | Canary 설명 및 실습 |
| 3:50 ~ 6:50 | 7~9장 | Rolling Update 및 Rollback 실습 |
| 6:50 ~ 7:10 | 10장 | 기본 배포 전략 정리 |
| 7:10 ~ 9:45 | 11~15장 | 추가 조사 내용 설명 |
| 9:45 ~ 10:00 | 마무리 | 전체 요약 |
PPT 1~10장은 배포 전략과 실습 흐름을 시각적으로 이해시키는 역할이고, 11~15장은 --record deprecated, Gateway API, Progressive Delivery 같은 추가 조사 내용으로 구성되어 있어.
녹화 전 준비 상태
영상 시작 전에 터미널은 YAML 파일이 있는 폴더에서 열어둬.
영상에서 굳이 cd 명령어를 보여주지 않아도 돼.
필요한 파일은 아래와 같아.
deployment-blue.yaml
deployment-green.yaml
nginx-service.yaml
deployment-stable.yaml
deployment-canary.yaml
nginx-service-canary.yaml
deployment-rolling-update.yaml여기서 nginx-service-canary.yaml은 Canary 실습용 서비스 파일이야.
Blue/Green 실습의 nginx-service.yaml은 처음에 version=blue를 바라보고, Canary 실습에서는 app=nginx만 바라보는 Service가 필요하므로 파일을 분리해두는 게 안전해.
최종 발표 대본 + 실습 명령어
슬라이드 1. 제목
대본
안녕하세요. 클라우드융합 개인 프로젝트 발표를 맡은 박시운입니다.
제가 맡은 주제는 Kubernetes Application Update이고, 세부적으로는 Blue/Green Update, Canary Update, Rolling Update 세 가지 배포 전략입니다.
이번 영상에서는 왼쪽에는 PPT를 띄워 각 배포 전략의 구조를 설명하고, 오른쪽 터미널에서는 실제 kubectl 명령어로 실습을 진행하겠습니다.
실습이 끝난 뒤에는 추가 조사 내용으로 최신 Kubernetes 운영 방식인 GitOps, Gateway API, Progressive Delivery까지 설명하겠습니다.
슬라이드 2. 배포 전략 비교
대본
2장에서는 세 가지 배포 전략을 비교합니다.
Blue/Green은 구버전과 신버전을 동시에 띄운 뒤 트래픽을 한 번에 전환하는 방식입니다. 자원은 많이 필요하지만 롤백이 빠릅니다.
Canary는 신버전을 일부 트래픽에만 먼저 배포해서 정상 동작을 검증하는 방식입니다. 위험을 빠르게 감지할 수 있습니다.
Rolling Update는 Pod를 하나씩 교체하면서 전체 시스템을 무중단으로 업데이트하는 방식입니다.
이제 이 세 가지 전략을 순서대로 실습하겠습니다.
1. Blue/Green Update 실습
슬라이드 3. Blue/Green Update 개념
대본
먼저 Blue/Green Update입니다.
Blue/Green Update는 구버전인 Blue와 신버전인 Green을 나란히 배포한 뒤, 트래픽을 한 번에 Green으로 전환하는 방식입니다.
장점은 롤백이 빠르다는 것입니다. Green 버전에 문제가 생기면 다시 Blue로 트래픽을 돌리면 됩니다.
단점은 Blue와 Green을 동시에 운영해야 하므로 전환 시점에 시스템 자원이 두 배 가까이 필요하다는 점입니다.
슬라이드 4. Service Selector 변경을 통한 트래픽 전환
대본
4장은 Kubernetes에서 Blue/Green 전환을 Service selector로 구현하는 구조입니다.
처음에는 nginx-svc 서비스가 version=blue인 Pod를 바라보게 하고, 이후 서비스의 selector를 version=green으로 바꾸면 트래픽이 Green Pod로 전환됩니다.
먼저 Blue와 Green Deployment, 그리고 nginx Service를 배포하겠습니다.
명령어
kubectl apply -f deployment-blue.yaml
kubectl apply -f deployment-green.yaml
kubectl apply -f nginx-service.yaml
kubectl get pod -o wide대본
현재 Blue 버전과 Green 버전의 Pod가 모두 배포되었습니다.
다만 서비스는 아직 Blue 버전을 바라보도록 설정되어 있습니다.
이제 nginx-svc 서비스의 Endpoint를 확인하겠습니다.
명령어
kubectl describe svc nginx-svc대본
출력 결과에서 Selector 부분을 보면 version=blue로 되어 있습니다.
Endpoints: 은 지금 실습 환경의 EndpointSlice 권한/버전 차이 때문에 표시되지않고 있습니다. 실제 Endpoint IP 변화는 kubectl get endpoints nginx-svc 명령으로 확인하겠습니다.
kubectl get endpoints nginx-svc
kubectl get pod -l app=nginx,version=blue -o wideEndpoint에는 version=blue인 Pod의 IP가 연결되어 있습니다.
이제 실습 PDF와 동일하게 kubectl edit 명령어로 서비스 selector의 version 값을 blue에서 green으로 바꾸겠습니다.
명령어
kubectl edit svc nginx-svc편집 방법
편집기가 열리면 아래 부분을 찾는다.
selector:
app: nginx
version: blue이 부분을 아래처럼 바꾼다.
selector:
app: nginx
version: greenvi 편집기라면 i를 눌러 수정하고, 수정 후 Esc → :wq → Enter로 저장한다.
nano 편집기라면 수정 후 Ctrl + O → Enter → Ctrl + X로 저장한다.
대본
서비스 selector를 version=green으로 수정했습니다.
이제 다시 nginx-svc를 확인해서 Endpoint가 Green Pod로 바뀌었는지 확인하겠습니다.
명령어
kubectl describe svc nginx-svckubectl get endpoints nginx-svc
kubectl get pod -l app=nginx,version=green -o wide대본
이제 selector가 version=green으로 변경되었고, Endpoint도 Green Pod의 IP로 바뀐 것을 확인할 수 있습니다.
즉, 사용자는 동일한 nginx-svc 서비스로 접근하지만, 내부적으로는 Blue에서 Green으로 트래픽이 전환된 것입니다.
이것이 Blue/Green Update의 핵심입니다.
다음 실습을 위한 최소 정리 명령어
kubectl delete -f deployment-blue.yaml
kubectl delete -f deployment-green.yaml
kubectl delete -f nginx-service.yaml짧은 설명
이 정리 명령어는 PDF에는 없지만, 한 영상에서 Canary 실습까지 이어서 진행하기 위해 필요합니다.
Blue/Green Pod가 남아 있으면 Canary 실습의 Service가 기존 Pod까지 같이 바라볼 수 있기 때문입니다.
2. Canary Update 실습
슬라이드 5. Canary Update 개념
대본
다음은 Canary Update입니다.
Canary Update는 신버전을 전체 사용자에게 바로 배포하지 않고, 일부 서버나 일부 사용자에게만 먼저 배포해서 정상 동작을 확인한 뒤 전체로 확산하는 방식입니다.
이 방식은 장애가 발생하더라도 일부 트래픽에서만 문제가 나타나므로 위험을 빠르게 감지하고 피해 범위를 줄일 수 있습니다.
슬라이드 6. Canary 트래픽 분산과 Pod Scaling
대본
6장은 Canary에서 트래픽 분산과 Pod Scaling을 보여줍니다.
이번 실습에서는 Stable 버전 Pod 2개와 Canary 버전 Pod 1개를 먼저 배포합니다.
이후 Canary 버전이 정상 동작한다고 가정하고, Canary Pod를 2개로 늘리고 Stable Pod를 0개로 줄여 전체를 Canary 버전으로 전환하겠습니다.
먼저 Stable과 Canary Deployment를 배포하겠습니다.
명령어
kubectl apply -f deployment-stable.yaml
kubectl apply -f deployment-canary.yaml
kubectl apply -f nginx-service-canary.yaml
kubectl get pod && kubectl get svc
kubectl get deployment -o wide대본
출력 결과를 보면 nginx-stable은 2개, nginx-canary는 1개가 실행 중입니다.
즉, Stable 버전 Pod 2개와 Canary 버전 Pod 1개가 배포된 상태입니다.
이제 서비스의 Endpoint를 확인하겠습니다.
명령어
kubectl describe service nginx-svc대본
Service의 selector는 app=nginx이고, Endpoint에는 Stable Pod와 Canary Pod가 함께 포함되어 있습니다.
즉, 총 3개의 Pod 중 1개가 Canary이므로 대략 Stable 66%, Canary 33% 정도의 트래픽 분산을 기대할 수 있습니다.
이제 Canary 버전이 정상 동작한다고 가정하고 전체 업데이트를 진행하겠습니다.
명령어
kubectl scale deployment nginx-canary --replicas=2
kubectl scale deployment nginx-stable --replicas=0
kubectl get deployment -o wide
kubectl get pod -o wide대본
이제 nginx-canary는 2개로 늘어났고, nginx-stable은 0개로 줄었습니다.
즉, 전체 트래픽이 Canary 버전으로 전환된 상태입니다.
이 방식은 Canary 배포의 기본 원리를 보여주기 좋지만, Pod 개수로 비율을 맞추는 방식이기 때문에 정확한 5%나 10% 같은 정밀한 트래픽 제어에는 한계가 있습니다.
이 한계는 뒤에서 Gateway API 설명과 연결됩니다.
다음 실습을 위한 최소 정리 명령어
kubectl delete -f deployment-stable.yaml
kubectl delete -f deployment-canary.yaml
kubectl delete -f nginx-service-canary.yaml3. Rolling Update 실습
슬라이드 7. Rolling Update 개념
대본
다음은 Rolling Update입니다.
Rolling Update는 전체 시스템을 중단하지 않고 점진적으로 업데이트하는 방식입니다.
새 이미지의 컨테이너가 들어간 Pod를 하나 추가하고, 기존 이미지의 Pod를 하나 삭제하는 과정을 순차적으로 반복합니다.
이 방식은 자원 오버헤드를 최소화하면서 무중단 업데이트를 수행할 수 있기 때문에 Kubernetes Deployment에서 기본적으로 많이 사용됩니다.
슬라이드 8. 생성과 종료의 Cross Replacement
대본
8장은 Rolling Update 중 새 Pod 생성과 기존 Pod 종료가 교차로 일어나는 과정을 보여줍니다.
새 Pod가 ContainerCreating 상태가 되는 동시에 기존 Pod가 Terminating 상태가 됩니다.
이 교차 과정 덕분에 서비스가 중단되지 않고 업데이트될 수 있습니다.
먼저 Rolling Update용 Deployment를 배포하겠습니다.
명령어
kubectl apply -f deployment-rolling-update.yaml --record
kubectl get deployment nginx-rolling-update -o wide대본
현재 nginx-rolling-update Deployment가 배포되었고, 이미지는 nginx:1.14입니다.
이제 이미지를 nginx:1.15로 변경하면서 Rolling Update를 수행하겠습니다.
실시간으로 Pod 생성과 종료를 보기 위해 터미널을 두 개 사용하겠습니다.
터미널 1 명령어
watch kubectl get pod대본
터미널 1에서는 watch kubectl get pod 명령으로 Pod 상태를 실시간으로 확인합니다.
이제 터미널 2에서 이미지 업데이트 명령을 실행하겠습니다.
터미널 2 명령어
kubectl set image deployment nginx-rolling-update webpage=nginx:1.15 --record대본
터미널 1을 보면 새 Pod가 ContainerCreating 상태로 생성되고, 기존 Pod가 Terminating 상태로 종료되는 것을 확인할 수 있습니다.
확인이 끝났으면 Ctrl + C로 watch 명령을 종료합니다.
이제 Rolling Update가 완료되었는지 확인하겠습니다.
명령어
kubectl rollout status deployment nginx-rolling-update
kubectl get deployment nginx-rolling-update -o wide대본
출력 결과에서 이미지가 nginx:1.15로 변경되었고, Deployment가 정상적으로 rollout된 것을 확인할 수 있습니다.
슬라이드 9. Revision History와 Rollback
대본
9장은 Rolling Update의 revision history와 rollback을 보여줍니다.
kubectl rollout history 명령어로 업데이트 기록을 확인할 수 있고, kubectl rollout undo 명령어로 이전 버전 또는 특정 revision으로 되돌릴 수 있습니다.
먼저 rollback 실습을 위해 이미지를 1.16, 1.17, 1.18까지 순서대로 업데이트하겠습니다.
명령어
kubectl set image deployment nginx-rolling-update webpage=nginx:1.16 --record
kubectl rollout status deployment nginx-rolling-update
kubectl set image deployment nginx-rolling-update webpage=nginx:1.17 --record
kubectl rollout status deployment nginx-rolling-update
kubectl set image deployment nginx-rolling-update webpage=nginx:1.18 --record
kubectl rollout status deployment nginx-rolling-update대본
이제 여러 번 이미지가 변경되었기 때문에 revision history가 생성되었습니다.
업데이트 기록을 확인하겠습니다.
명령어
kubectl rollout history deployment nginx-rolling-update
kubectl get deployment nginx-rolling-update -o wide대본
현재 이미지는 nginx:1.18입니다.
이제 바로 전 업데이트 버전인 nginx:1.17로 rollback하겠습니다.
명령어
kubectl rollout undo deployment nginx-rolling-update대본
kubectl rollout undo 명령은 기본적으로 바로 이전 revision으로 되돌립니다.
현재 이미지 버전을 다시 확인하겠습니다.
명령어
kubectl get deployment nginx-rolling-update -o wide
kubectl rollout history deployment nginx-rolling-update대본
현재 이미지가 nginx:1.17로 rollback된 것을 확인할 수 있습니다.
이번에는 특정 revision을 지정해서 nginx:1.15 버전으로 rollback하겠습니다.
실습 PDF에서는 revision 2가 nginx:1.15 버전에 해당합니다.
명령어
kubectl rollout undo deployment nginx-rolling-update --to-revision=2대본
이제 특정 revision으로 rollback했습니다.
현재 이미지와 업데이트 기록을 다시 확인하겠습니다.
명령어
kubectl get deployment nginx-rolling-update -o wide
kubectl rollout history deployment nginx-rolling-update대본
현재 이미지가 nginx:1.15로 변경된 것을 확인할 수 있습니다.
이처럼 Rolling Update는 점진적으로 배포할 수 있을 뿐 아니라, revision history를 이용해서 원하는 과거 버전으로 안전하게 rollback할 수 있습니다.
슬라이드 10. 최적의 배포 전략
대본
10장은 지금까지 실습한 세 가지 배포 전략을 어떤 상황에서 선택할지 정리하는 슬라이드입니다.
클러스터 자원이 충분하고 빠른 롤백이 중요하다면 Blue/Green이 적합합니다.
실제 사용자 트래픽을 통해 신버전 안정성 검증이 필요하다면 Canary가 적합합니다.
자원 제약 속에서 표준적인 무중단 배포를 원한다면 Rolling Update가 적합합니다.
즉, 완벽한 단일 배포 전략은 없습니다.
인프라 자원, 트래픽 민감도, 롤백의 긴급성을 종합적으로 고려해서 시스템에 맞는 최적의 라우팅 전략을 설계하는 것이 중요합니다.
이제 실습은 마무리하고, 11장부터는 추가 조사 내용인 최신 Kubernetes 운영 방향을 설명하겠습니다.
4. 추가 조사 내용 설명
슬라이드 11. 최신화 방향
대본
11장부터는 추가 조사 내용입니다.
지금까지는 Blue/Green, Canary, Rolling Update라는 기본 배포 전략을 실습했습니다.
하지만 최신 Kubernetes 운영에서는 이 전략들이 단순한 수동 kubectl 명령어 수준을 넘어 GitOps, Gateway API, Progressive Delivery와 결합하는 방향으로 발전하고 있습니다.
즉, 앞의 실습은 배포 전략의 기본 원리를 보여주는 것이고, 11장 이후는 이 원리가 실무 환경에서 어떻게 더 자동화되고 정밀해지는지를 설명하는 부분입니다.
슬라이드 12. --record deprecated와 GitOps
대본
12장은 Rolling Update 실습에서 사용한 --record 옵션과 관련된 최신 이슈입니다.
실습에서는 PDF 흐름과 동일하게 kubectl set image ... --record 명령어를 사용했습니다.
이 옵션은 rollout history에서 변경 원인을 남기기 위해 사용됩니다.
하지만 Kubernetes v1.22 changelog에서는 kubectl --record 플래그가 deprecated 되었다고 명시되어 있습니다. 즉, 최신 운영에서는 이 방식이 더 이상 권장되는 중심 방식은 아닙니다. (GitHub)
그래서 최신 방식에서는 kubernetes.io/change-cause annotation을 직접 남기거나, 더 나아가 Argo CD나 Flux 같은 GitOps 도구를 사용해 Git commit history를 배포 이력의 기준으로 삼습니다.
예를 들면 이런 방식입니다.
kubectl annotate deployment/nginx-rolling-update \
kubernetes.io/change-cause="nginx 이미지를 1.15로 업데이트" \
--overwrite즉, 과거에는 kubectl 명령어 자체가 이력 관리의 중심이었다면, 최신 운영에서는 Git commit, Pull Request, merge history가 배포 이력의 중심이 됩니다.
슬라이드 13. Ingress NGINX 은퇴와 Gateway API 전환
대본
13장은 Canary 배포에서 트래픽 비율을 제어하는 방식의 변화입니다.
앞에서 실습한 Canary는 Stable Pod 2개, Canary Pod 1개처럼 Pod 개수를 조절해서 트래픽 비율을 간접적으로 맞추는 방식이었습니다.
하지만 Pod 개수 기반 방식은 정확한 10%나 5% 같은 비율 제어가 어렵습니다.
기존에는 Ingress-NGINX에서도 annotation을 통해 Canary weight를 지정할 수 있었지만, 이것은 ingress-nginx 컨트롤러 전용 설정에 가까웠습니다.
Gateway API에서는 HTTPRoute의 backendRefs.weight를 사용해서 여러 backend 사이의 트래픽 비율을 지정할 수 있습니다. 공식 Gateway API 문서에서도 HTTPRoute weight는 rollout이나 canary 변경 중 backend 간 트래픽을 나누는 데 사용할 수 있다고 설명합니다. (Gateway API)
예시는 다음과 같습니다.
rules:
backendRefs:
- name: nginx-stable
port: 80
weight: 90
- name: nginx-canary
port: 80
weight: 10이렇게 하면 Stable 서비스에는 대부분의 트래픽을 보내고, Canary 서비스에는 일부 트래픽만 보낼 수 있습니다.
다만 weight는 정확히 “퍼센트 값” 자체는 아니고, 전체 weight 합계 대비 비율입니다. Gateway API 스펙에서도 weight는 weight / 전체 weight 합계로 계산된다고 설명합니다. (Gateway API)
즉, 기존 실습은 Pod 개수 기반 Canary이고, 최신 방식은 Gateway API의 weight 기반 라우팅으로 더 정밀하게 트래픽을 제어하는 방식입니다.
슬라이드 14. 메트릭 기반의 자동화된 롤아웃
대본
14장은 Progressive Delivery, 즉 메트릭 기반의 자동화된 롤아웃입니다.
앞의 실습에서는 사람이 직접 kubectl scale, kubectl set image, kubectl rollout undo 명령어를 실행했습니다.
하지만 실무에서는 이 과정을 자동화할 수 있습니다.
예를 들어 처음에는 Canary 버전에 트래픽을 5%만 보냅니다.
그 다음 Prometheus나 Datadog 같은 모니터링 도구로 에러율, 응답 지연 시간, 성공률 같은 메트릭을 확인합니다.
정상이라면 트래픽을 10%, 20%, 50%처럼 점진적으로 늘립니다.
반대로 문제가 발생하면 자동으로 rollback합니다.
이때 Prometheus는 트래픽을 직접 제어하는 도구가 아니라, 메트릭을 수집하고 제공하는 역할입니다.
실제 판단과 제어는 Argo Rollouts나 Flagger 같은 컨트롤러가 담당합니다.
Argo 공식 페이지에서도 Argo Rollouts는 Canary와 Blue-Green 같은 고급 Kubernetes 배포 전략을 쉽게 수행하기 위한 도구라고 설명합니다. (Argo Project)
즉, Progressive Delivery는 단순 배포가 아니라, 메트릭으로 안전성을 확인하면서 점진적으로 배포하는 방식입니다.
슬라이드 15. Progressive Delivery Architecture
대본
마지막 15장은 Progressive Delivery의 전체 아키텍처입니다.
흐름은 왼쪽에서 오른쪽으로 진행됩니다.
먼저 개발자가 코드를 수정하고 Git에 commit합니다.
Argo CD는 Git 저장소의 manifest를 Kubernetes 클러스터와 동기화합니다.
그 다음 Argo Rollouts가 배포 전략을 관리합니다.
Gateway API의 HTTPRoute는 Stable Pod와 Canary Pod 사이의 트래픽 비율을 담당합니다.
예를 들어 Stable Pod에는 90%의 트래픽을 보내고, Canary Pod에는 10%의 트래픽만 보냅니다.
그리고 Gateway 계층과 Pod에서 발생하는 요청 수, 에러율, 지연 시간 같은 메트릭은 Prometheus로 수집됩니다.
중요한 점은 Prometheus가 Gateway API를 직접 제어하지 않는다는 것입니다.
Prometheus는 메트릭을 제공하고, Argo Rollouts나 Flagger가 이 메트릭을 기반으로 배포 성공 여부를 판단합니다.
정상이라면 Argo Rollouts가 Gateway API의 weight를 조정해 Canary 트래픽을 더 늘립니다.
문제가 발생하면 weight를 Stable 쪽으로 되돌려 자동 rollback합니다.
정리하면 흐름은 다음과 같습니다.
Git Commit
→ Argo CD
→ Argo Rollouts
→ Gateway API
→ Stable / Canary Pod
→ Prometheus 메트릭 수집
→ Argo Rollouts 판단
→ Gateway API weight 조정 또는 rollback결론적으로 Blue/Green, Canary, Rolling은 배포 전략의 기본이고, 최신 Kubernetes 운영에서는 GitOps의 선언적 관리, Gateway API의 정밀한 라우팅, Prometheus 기반 관측성, Argo Rollouts 기반 자동화를 결합한 Progressive Delivery로 발전하고 있습니다.
최종 마무리 멘트
대본
지금까지 Kubernetes Application Update 주제로 Blue/Green, Canary, Rolling Update를 설명하고 실제 kubectl 명령어로 실습을 진행했습니다.
Blue/Green은 Service selector를 바꿔 트래픽을 빠르게 전환하는 방식입니다.
Canary는 일부 트래픽만 신버전에 보내 위험을 줄이는 방식입니다.
Rolling Update는 Pod를 순차적으로 교체하면서 무중단 업데이트를 수행하는 방식입니다.
그리고 추가 조사 내용으로, 최신 Kubernetes 운영에서는 GitOps 기반 이력 관리, Gateway API 기반 트래픽 weight 제어, Prometheus 메트릭 분석, Argo Rollouts 기반 자동 rollback을 결합한 Progressive Delivery로 발전하고 있다는 점을 확인했습니다.
이상으로 발표와 실습을 마치겠습니다.
최종 실습 명령어만 모은 버전
영상 중 복사해서 쓰기 편하게 명령어만 다시 모아두면 아래와 같아.
Blue/Green
kubectl apply -f deployment-blue.yaml
kubectl apply -f deployment-green.yaml
kubectl apply -f nginx-service.yaml
kubectl get pod -o widekubectl describe svc nginx-svckubectl edit svc nginx-svc수정 내용:
selector:
app: nginx
version: greenkubectl describe svc nginx-svckubectl delete -f deployment-blue.yaml
kubectl delete -f deployment-green.yaml
kubectl delete -f nginx-service.yamlCanary
kubectl apply -f deployment-stable.yaml
kubectl apply -f deployment-canary.yaml
kubectl apply -f nginx-service-canary.yaml
kubectl get pod && kubectl get svc
kubectl get deployment -o widekubectl describe service nginx-svckubectl scale deployment nginx-canary --replicas=2
kubectl scale deployment nginx-stable --replicas=0
kubectl get deployment -o wide
kubectl get pod -o widekubectl delete -f deployment-stable.yaml
kubectl delete -f deployment-canary.yaml
kubectl delete -f nginx-service-canary.yamlRolling Update
kubectl apply -f deployment-rolling-update.yaml --record
kubectl get deployment nginx-rolling-update -o wide터미널 1:
watch kubectl get pod터미널 2:
kubectl set image deployment nginx-rolling-update webpage=nginx:1.15 --record확인:
kubectl rollout status deployment nginx-rolling-update
kubectl get deployment nginx-rolling-update -o wideRevision 생성
kubectl set image deployment nginx-rolling-update webpage=nginx:1.16 --record
kubectl rollout status deployment nginx-rolling-update
kubectl set image deployment nginx-rolling-update webpage=nginx:1.17 --record
kubectl rollout status deployment nginx-rolling-update
kubectl set image deployment nginx-rolling-update webpage=nginx:1.18 --record
kubectl rollout status deployment nginx-rolling-updateRollback
kubectl rollout history deployment nginx-rolling-update
kubectl get deployment nginx-rolling-update -o widekubectl rollout undo deployment nginx-rolling-updatekubectl get deployment nginx-rolling-update -o wide
kubectl rollout history deployment nginx-rolling-updatekubectl rollout undo deployment nginx-rolling-update --to-revision=2kubectl get deployment nginx-rolling-update -o wide
kubectl rollout history deployment nginx-rolling-update이 버전이 발표용 최종본으로 쓰기 가장 깔끔해. PDF에 있는 핵심 명령어를 유지했고, get nodes, current-context, 시작 전 전체 삭제 같은 부가 명령어는 본편에서 제거했어.
