クイズ: デプロイ・アップグレード・ロールバック

Helm 3 가 릴리스 상태를 저장하는 방식으로 옳은 것은?

• 클라이언트의 홈 디렉터리 아래에 릴리스별 파일로 저장하므로 같은 클러스터를 써도 다른 사람은 이력을 볼 수 없다
• 릴리스가 설치된 네임스페이스에 sh.helm.release.v1.<이름>.v<리비전> 이름의 Secret 으로 리비전마다 하나씩 저장한다
• kube-system 네임스페이스에 있는 helm-releases ConfigMap 하나에 클러스터 안 모든 릴리스의 리비전을 이어 붙여 저장한다
• 클러스터에 상주하는 Tiller 서버가 메모리에 들고 있어 CLI 는 그 서버에 물어봐야 이력을 알 수 있다

리비전 3이 최신인 릴리스를 리비전 2로 롤백하면 이력은 어떻게 되나요?

• 리비전 번호는 3에 머문 채 그 시크릿의 내용만 리비전 2의 것으로 덮인다
• 리비전 2의 차트와 values 로 계산한 리비전 4가 새로 생긴다
• 이력이 초기화되어 리비전 1부터 다시 매겨지고 이전 기록은 사라진다
• 리비전 3의 시크릿이 지워지고 리비전 2가 다시 최신 리비전이 된다

업그레이드가 API 서버에게 거부되어 실패했습니다. 그 결과로 옳은 것은?

• 릴리스 전체가 uninstalled 상태로 바뀌고 이미 떠 있던 리소스까지 Helm 이 함께 정리해 버린다
• 거부된 시도는 리비전을 만들지 않으므로 이력에는 직전 성공 리비전만 그대로 남는다
• 새 리비전은 생기지 않고 직전 성공 리비전의 상태 표시만 failed 로 바뀐다
• 실패한 시도도 새 리비전으로 기록되고 상태가 failed 가 되며 실물은 직전 상태 그대로 남는다

Helm 3 의 three-way strategic merge patch 가 비교하는 세 가지는?

• Chart.yaml 의 메타데이터, values.yaml 의 기본값, templates/ 의 렌더링 결과
• 차트의 기본값, -f 로 넘긴 값 파일, --set 으로 넘긴 명령줄 값
• 이전 리비전의 매니페스트, 현재 클러스터의 실제 상태, 새로 렌더링한 매니페스트
• 개발·스테이지·운영 세 환경에 지금 적용되어 있는 매니페스트

helm get values my-app 과 helm get values my-app -a 의 차이는?

• -a 는 모든 네임스페이스를 뒤져 이름이 같은 릴리스의 값을 모아서 보여 준다
• -a 는 리비전 1부터 지금까지의 값을 순서대로 이어 붙여 한꺼번에 보여 준다
• -a 는 같은 내용을 YAML 대신 JSON 으로 바꿔 출력해 파싱하기 쉽게 해 준다
• -a 는 차트 기본값까지 병합된 최종 값을, 없으면 사용자가 실제로 넘긴 값만 보여 준다

배포 실패의 원인을 관찰해야 하는 상황에서 --atomic 을 붙이지 않는 이유는?

• --atomic 은 실패 시 자동으로 이전 리비전으로 되돌려 실패한 상태를 볼 기회를 없애기 때문
• --atomic 은 --wait 를 끄고 곧바로 반환하므로 파드가 준비되는 과정을 지켜볼 수 없기 때문
• --atomic 은 pre-upgrade 훅을 건너뛰므로 마이그레이션 Job 의 로그가 남지 않기 때문
• --atomic 은 install 에만 있는 옵션이라 upgrade 에 붙이면 조용히 무시되기 때문