Quiz: Chart Structure

Chart.yaml 의 version 과 appVersion 의 관계로 옳은 것은?

• 둘은 같은 대상을 가리키는 값이라 helm lint 가 서로 다르면 경고하므로 항상 같게 맞춘다
• version 은 차트 자체의 버전, appVersion 은 배포하는 애플리케이션의 버전으로 독립적으로 움직인다
• appVersion 은 앱의 버전이므로 차트를 고칠 때마다 version 보다 항상 크거나 같게 유지해야 한다
• appVersion 은 Chart.yaml 에 적지 않아도 Helm 이 이미지 태그를 읽어 자동으로 채워 준다

templates/_helpers.tpl 처럼 밑줄로 시작하는 파일의 특징은?

• install 때만 적용되고 upgrade·uninstall 에서는 손대지 않는 특별 구역이다
• helm package 가 자동으로 빼므로 패키징된 차트 안에는 들어가지 않는다
• Helm 이 파싱하지 않는 파일이라 메모나 초안을 자유롭게 적어 두는 자리다
• 매니페스트로 렌더링되지 않고 이름 붙은 템플릿 정의를 담는 자리다

공통 라벨과 셀렉터 라벨을 굳이 따로 정의하는 이유는?

• Service 의 spec.selector 는 app.kubernetes.io/version 같은 버전 라벨을 해석하지 못해 트래픽이 파드에 닿지 않기 때문
• 셀렉터에 적는 라벨 수가 적을수록 API 서버의 라벨 인덱스 조회가 빨라져 대규모 클러스터에서 응답 시간이 벌어지기 때문
• Deployment 의 spec.selector 는 변경할 수 없는 필드인데 공통 라벨에는 버전이 섞여 있어 차트 버전을 올리면 업그레이드가 거부되기 때문
• Helm 이 공통 라벨은 템플릿 렌더링 때, 셀렉터 라벨은 적용 직전에 계산하므로 두 자리의 값이 어긋날 수 있기 때문

이름 헬퍼에 trunc 63 과 trimSuffix 가 붙어 있는 이유는?

• 쿠버네티스 이름 길이 제한을 넘지 않게 자르고, 잘린 끝이 하이픈으로 끝나 유효하지 않게 되는 것을 막기 위해
• 라벨 값이 63자를 넘으면 etcd 가 저장을 거부하므로 리소스 이름도 라벨과 같은 길이 안에 들어오게 맞추기 위해
• 릴리스 이름이 63자보다 짧으면 Helm 이 뒤를 하이픈으로 채우므로 그 여백을 다시 걷어 내기 위해
• Helm 템플릿 엔진의 내부 문자열 버퍼가 63바이트라 그것을 넘기면 렌더링이 잘려 나가기 때문에

crds/ 디렉터리에 있는 파일의 특별한 취급으로 옳은 것은?

• install 때만 적용되고 upgrade 나 uninstall 에서는 건드리지 않으며 템플릿 렌더링도 되지 않는다
• 템플릿으로 렌더링되므로 values 를 참조할 수 있고, 업그레이드할 때마다 차트에 담긴 최신 스키마가 다시 적용된다
• values 의 조건 값으로 켜고 끌 수 있어 릴리스마다 CRD 설치 여부를 다르게 가져갈 수 있다
• uninstall 할 때 다른 리소스보다 먼저 삭제되어 그 CRD 로 만든 커스텀 리소스까지 함께 정리된다

values.yaml 에 주석을 다는 것이 중요한 이유로 가장 적절한 것은?

• 차트를 쓰는 사람이 실제로 읽는 것은 템플릿이 아니라 values.yaml 이므로 그 파일이 사실상 API 문서이기 때문
• 주석에 적힌 키 설명을 Helm 이 스키마처럼 함께 읽어야 값의 우선순위와 병합 순서가 올바르게 계산되기 때문
• 주석이 하나도 없는 values.yaml 은 helm lint 가 ERROR 로 잡아 차트 패키징과 저장소 업로드가 막히기 때문
• 주석이 렌더링된 매니페스트에 그대로 남아 누가 어떤 값을 바꿨는지 감사 추적이 되기 때문