Helm 차트 제작과 배포 · 차트 구조 · 퀴즈
퀴즈: 차트 구조
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
`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 로 잡아 차트 패키징과 저장소 업로드가 막히기 때문
- 주석이 렌더링된 매니페스트에 그대로 남아 누가 어떤 값을 바꿨는지 감사 추적이 되기 때문