Quiz: Helm and Kustomize Integration

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

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

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

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

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

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

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

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

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

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

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

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

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

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