배포하고, 깨뜨리고, 되돌린다

목표

배포를 되돌릴 수 있는 것으로 만듭니다. 배포하고, 일부러 깨뜨리고, 두 가지
방법으로 되돌리고, 갇힌 릴리스를 꺼내는 것까지 한 바퀴 돕니다.

왜 중요한가

배포 자동화의 성패는 성공했을 때가 아니라 실패했을 때 어떤 상태로 남는가로
갈립니다. helm upgrade 는 기본적으로 파드가 뜨는지 보지 않고 성공을 반환합니다.
그래서 CI 는 초록불인데 사용자만 장애를 겪는 상황이 만들어집니다.

이 실습에서는 그 상황을 직접 만들어 봅니다. 4단계에서 없는 이미지로 배포하면
helm 이 STATUS: deployed 라고 말하는 걸 눈으로 보게 됩니다. 그다음 --atomic 을
붙이면 무엇이 달라지는지 비교합니다.

환경

이 파드는 kwok 으로 진짜 kube-apiserver 를 띄웁니다. 파드가 실제로 실행되지는
않지만 릴리스 시크릿·리비전·리소스 변경은 전부 진짜입니다. 그래서 채점도
파일이 아니라 클러스터 상태를 다시 읽어서 합니다.

kubectl get nodes            노드 2대가 Readyhelm version                 v3.16

단계

1. helm create demo → helm install
2. 릴리스 시크릿에서 매니페스트를 꺼내 /root/helm/02-manifest.yaml
3. --set replicaCount=4 로 리비전 2
4. 없는 이미지로 업그레이드 — 성공했다고 나오는 것을 확인
5. 같은 실수를 --atomic 으로 다시 → /root/helm/05-atomic.txt
6. helm rollback demo 2
7. helm template 두 번을 diff → /root/helm/07-diff.txt
8. pending-upgrade 에 갇힌 릴리스를 꺼내기

참고

• 이 실습에서는 명령이 실패하는 것도 정답인 단계가 있습니다(5번).

실패 출력을 저장하는 것이 목적입니다.

• helm history demo 를 자주 보세요. 무슨 일이 있었는지가 전부 거기 있습니다.
• 갇힌 릴리스는 실무에서 helm 프로세스가 중간에 죽거나 CI 가 취소될 때 생깁니다.

단계 8개

1. 차트를 만들고 배포한다
2. 릴리스가 저장된 시크릿을 직접 본다
3. replicas 를 올려 리비전 2를 만든다
4. 일부러 깨뜨린다
5. --atomic 으로 실패를 잡는다
6. 손으로 되돌린다
7. 무엇이 달라지는지 미리 본다
8. pending 에 갇힌 릴리스를 꺼낸다