LabHub

Helm 차트 제작과 배포 · 차트 구조 · 퀴즈

퀴즈: 차트 구조

LabHub 에서 이어서 보기

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

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

    1. 둘은 같은 대상을 가리키는 값이라 helm lint 가 서로 다르면 경고하므로 항상 같게 맞춘다
    2. version 은 차트 자체의 버전, appVersion 은 배포하는 애플리케이션의 버전으로 독립적으로 움직인다
    3. appVersion 은 앱의 버전이므로 차트를 고칠 때마다 version 보다 항상 크거나 같게 유지해야 한다
    4. appVersion 은 Chart.yaml 에 적지 않아도 Helm 이 이미지 태그를 읽어 자동으로 채워 준다
  2. `templates/_helpers.tpl` 처럼 밑줄로 시작하는 파일의 특징은?

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

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

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

    1. install 때만 적용되고 upgrade 나 uninstall 에서는 건드리지 않으며 템플릿 렌더링도 되지 않는다
    2. 템플릿으로 렌더링되므로 values 를 참조할 수 있고, 업그레이드할 때마다 차트에 담긴 최신 스키마가 다시 적용된다
    3. values 의 조건 값으로 켜고 끌 수 있어 릴리스마다 CRD 설치 여부를 다르게 가져갈 수 있다
    4. uninstall 할 때 다른 리소스보다 먼저 삭제되어 그 CRD 로 만든 커스텀 리소스까지 함께 정리된다
  6. `values.yaml` 에 주석을 다는 것이 중요한 이유로 가장 적절한 것은?

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