퀴즈: 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 를 쓰지 않는다