퀴즈: 배포·업그레이드·롤백

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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