퀴즈: 헬름·Kustomize 연동

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

1. `configMapGenerator` 가 만든 ConfigMap 이름 끝에 내용 해시가 붙는 이유는?

   1. 쿠버네티스가 생성기로 만든 ConfigMap 은 해시 접미어가 없으면 거부하기 때문
   2. 같은 입력이면 같은 이름이 나오는 성질을 이용해 빌드 결과를 캐시하기 위해
   3. 설정 내용이 바뀌면 이름이 바뀌고, 그것을 참조하는 파드 템플릿이 바뀌어 롤아웃이 자동으로 일어나게 하려고
   4. 여러 오버레이가 같은 이름의 ConfigMap 을 만들 때 충돌을 막기 위해서만

2. dev 환경만 replicas 를 1로 하고 싶습니다. 올바른 방법은?

   1. dev 오버레이에 패치를 두어 베이스 값을 덮어쓴다
   2. 베이스의 deployment.yaml 을 1로 고친다
   3. dev 전용 deployment.yaml 을 따로 복사해 만든다
   4. 베이스를 두 벌로 나눈다

3. ArgoCD 가 Helm 차트를 소스로 쓰는 Application 을 동기화할 때 실제로 하는 일은?

   1. 차트 파일을 그대로 클러스터로 옮긴 뒤 클러스터 안에서 렌더해 그대로 적용한다
   2. 대상 클러스터에 직접 접속해 `helm upgrade --install` 을 그대로 실행한다
   3. repo-server 가 `helm template` 로 매니페스트를 렌더한 뒤 그 결과를 apply 한다
   4. 클러스터에 설치된 Tiller 컴포넌트를 통해 새 Helm 릴리스를 만들어 둔다

4. `spec.source.targetRevision` 을 `HEAD` 로 두면 생기는 문제는?

   1. `HEAD` 는 브랜치 이름이 아니라 예약어라 저장소를 읽지 못한다
   2. 리비전이 고정되지 않아 안전 장치로 prune 이 강제로 켜진 상태가 된다
   3. 같은 Application 정의가 시점에 따라 다른 것을 배포해 재현 가능성이 사라진다
   4. 비교할 리비전을 특정하지 못해 동기화가 아예 시작되지 않는다

5. `kustomize build` 의 결과에 `kind: Kustomization` 이 들어 있다면 무엇을 의심해야 하나요?

   1. 정상이며 빌드 결과에는 지시서 내용이 원래 함께 출력된다
   2. 지시서 파일 자체를 `resources` 로 가져오는 등 구성이 잘못됐다
   3. 베이스에 patch 가 하나도 없어 원본이 그대로 흘러나온 것이다
   4. kustomize 버전이 낮아 새 API 버전의 지시서를 걸러내지 못한 것이다

6. 베이스에 `namePrefix: labhub-` 가 있을 때 오버레이의 전략적 병합 패치가 대상을 찾는 이름은?

   1. 베이스에 적힌 원래 이름인 `web`
   2. 이름 변형이 끝난 뒤의 `labhub-web`
   3. 패치 파일이 놓인 파일 경로와 이름
   4. 오버레이가 지정한 네임스페이스 이름

7. ArgoCD Application 에서 `helm.valueFiles` 와 `helm.parameters` 를 나눠 쓰는 이유로 가장 적절한 것은?

   1. `valueFiles` 가 Helm 3 에서 폐기되어 파라미터 쪽으로 옮겨 가는 중이기 때문
   2. 환경별로 고정된 값 묶음은 파일로 저장소에 남기고, 배포마다 바뀌는 값(이미지 태그 등)은 파라미터로 넘기기 위해
   3. 둘은 렌더 결과가 완전히 같아 어느 쪽을 쓰든 되는 취향의 문제일 뿐이기 때문
   4. `parameters` 가 `valueFiles` 보다 먼저 읽혀 우선순위가 더 낮기 때문