测验：Capabilities 与 crds

옵션 없는 helm template 에서 .Capabilities.APIVersions.Has "networking.k8s.io/v1/Ingress" 의 값은?

• 현재 kubeconfig 가 가리키는 클러스터에 물어 답한다
• false — helm 에 박힌 작은 기본 목록만 쓰고 클러스터에 묻지 않는다
• true — 표준 API 는 언제나 있는 것으로 간주한다
• kubeconfig 가 없으면 오류가 나고, 있으면 클러스터 값을 쓴다

helm template --api-versions "demo.labhub.io/v1/Widget" 을 주면 기본 API 목록은 어떻게 되나요?

• 기본 목록이 통째로 대체되어 표준 API 는 모두 없는 것이 된다
• 클러스터에 접속해 목록을 가져온 뒤 그 위에 더한다
• 이 옵션은 --kube-version 과 함께 써야만 효과가 있다
• 기본 목록은 그대로 두고 지정한 것을 더한다

차트의 crds/widget.yaml 을 고치고 helm upgrade 를 돌렸습니다. 클러스터의 CRD 는?

• 그대로다 — crds 는 설치 때만 들어가고 업그레이드에서는 손대지 않는다
• 새 내용으로 갱신된다 — 릴리스 매니페스트의 일부이기 때문이다
• 삭제되었다가 새로 만들어진다 — 스키마 변경이라 교체가 필요하다
• 업그레이드가 CRD 변경을 감지해 오류로 중단된다

helm get manifest <릴리스> 를 실행했을 때 crds/ 의 CRD 가 보이지 않는 이유는?

• 매니페스트는 요약이라 클러스터 범위 오브젝트를 생략한다
• CRD 가 이미 있던 것이라 이번 릴리스가 만들지 않았기 때문이다
• CRD 는 릴리스가 소유하지 않으므로 릴리스 매니페스트에 기록되지 않는다
• --include-crds 없이 설치했기 때문이다 — 그 옵션을 주면 기록된다

CRD 를 crds/ 대신 templates/ 에 두면 생기는 대표적인 위험은?

• 템플릿 엔진을 거치므로 CRD 안의 중괄호가 모두 오류가 된다
• CRD 가 다른 오브젝트보다 늦게 들어가 첫 설치가 반드시 실패한다
• helm template 에서 CRD 가 출력되지 않아 검토가 어려워진다
• 릴리스가 CRD 를 소유하게 되어, 릴리스를 지우면 CRD 와 그 자원이 함께 사라진다

CI 에 클러스터 접속이 없는데 policy/v1 분기와 policy/v1beta1 분기를 모두 검증하려면?

• --kube-version 과 --api-versions 로 두 대상 클러스터를 흉내 내어 각각 렌더한다
• helm template --validate 를 두 번 돌려 결과를 비교한다
• helm install --dry-run=server 로 두 분기를 모두 렌더한다
• values 에 분기용 스위치를 따로 만들어 Capabilities 를 쓰지 않는다