퀴즈: 템플릿과 values

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

1. Helm 템플릿 엔진이 YAML 을 다루는 방식으로 옳은 것은?

   1. 값마다 개별 JSON 패치를 만들어 API 서버에 차례로 적용한다
   2. 쿠버네티스 API 스키마를 참조해 블록의 들여쓰기를 자동으로 맞춰 준다
   3. YAML 을 먼저 파싱해 트리로 만든 뒤 노드의 값을 직접 바꿔 넣는다
   4. 먼저 문자열을 만들어 내고, 완성된 문자열을 그다음에 YAML 로 파싱한다

2. `toYaml` 결과에 `indent` 대신 `nindent` 를 쓰는 이유는?

   1. nindent 는 앞 키의 들여쓰기 깊이를 읽어 인자 없이도 칸 수를 알아서 맞춰 주기 때문
   2. indent 는 맵만 들여쓸 수 있어 toYaml 로 편 리스트에는 쓸 수 없기 때문
   3. indent 는 렌더링이 다 끝난 뒤에 적용되어 파이프 중간에 끼워 넣을 수 없기 때문
   4. nindent 는 앞에 줄바꿈을 넣어 주므로 블록의 첫 줄이 앞 키에 붙지 않기 때문

3. `template` 과 `include` 의 실질적인 차이는?

   1. include 는 렌더링을 뒤로 미뤄 두었다가 다른 템플릿이 모두 끝난 뒤에 실행하므로 최종 매니페스트의 출력 순서가 달라진다
   2. include 만 서브차트를 포함한 다른 차트에 정의된 네임드 템플릿을 이름으로 불러 쓸 수 있다
   3. template 은 컨텍스트를 인자로 받지 못해 점 하나를 넘길 수 없고 전역 값만 볼 수 있다
   4. include 는 결과를 문자열로 반환해 파이프로 후처리할 수 있고, template 은 결과를 그 자리에 바로 출력한다

4. `default` 와 `required` 를 나누어 쓰는 기준으로 가장 적절한 것은?

   1. 없어도 합리적으로 동작할 값에는 default 를, 없으면 배포되면 안 되는 값에는 required 를 쓴다
   2. required 는 서브차트 템플릿에서만 동작하므로 부모 차트에서는 default 로 대신 검사해야 한다
   3. default 는 값이 비면 렌더링을 실패시키고 required 는 경고만 남긴 채 빈 값으로 계속 진행한다
   4. 빈 값이 가능한 문자열에는 default 를, 0 과 구분이 어려운 숫자와 불리언에는 required 를 쓴다

5. `-f a.yaml -f b.yaml --set key=v` 로 렌더링할 때 값의 우선순위는?

   1. a.yaml 과 b.yaml 은 차트 values.yaml 보다 약해서 차트에 이미 있는 키는 덮어쓰지 못한다
   2. 값 파일은 준 순서와 무관하게 키 이름의 알파벳 순으로 병합되고 --set 도 같은 규칙을 따른다
   3. 차트 values.yaml 이 가장 약하고, a.yaml, b.yaml 순으로 세지며, --set 이 가장 세다
   4. --set 이 가장 약하고 차트 values.yaml 이 가장 세며 두 값 파일은 그 사이에 놓인다

6. 파드 템플릿 어노테이션에 `checksum/config` 를 넣는 관례의 목적은?

   1. kubelet 이 마운트 전에 해시를 대조해 ConfigMap 내용이 손상되지 않았는지 검증하게 하려고
   2. ConfigMap 내용이 바뀌어도 파드 스펙은 그대로여서 롤아웃이 일어나지 않는 문제를 해결하려고
   3. 이름이 같은 ConfigMap 을 다른 릴리스가 가로채 마운트하는 일을 Helm 이 막게 하려고
   4. three-way merge 에서 Helm 이 바뀐 리소스만 골라 적용하도록 힌트를 주려고