커스텀 리소스 정의

커스텀 리소스 정의 (Custom Resource Definitions)

이 문서는 커스텀 리소스 정의(Custom Resource Definition, CRD) 객체를 만들고 사용하는 방법을 다뤄요. CRD 선언과 이를 사용하는 리소스를 구분하고, 설치 방법을 설명해요.

출처: 문서

본문

이 모범 사례 가이드의 이 섹션은 커스텀 리소스 정의(Custom Resource Definition) 객체를 만들고 사용하는 방법을 다뤄요.

CRD로 작업할 때 두 가지 다른 부분을 구분하는 것이 중요해요:

CRD의 선언이 있어요. 이것은 kind가 CustomResourceDefinition인 YAML 파일이에요.
그리고 CRD를 사용하는 리소스가 있어요. CRD가 foo.example.com/v1을 정의한다고 합시다. apiVersion: example.com/v1이고 kind가 Foo인 리소스는 모두 CRD를 사용하는 리소스예요.

리소스를 사용하기 전에 CRD 선언 설치하기 (Install a CRD Declaration Before Using the Resource)

Helm은 가능한 한 많은 리소스를 Kubernetes에 빠르게 로드하도록 최적화되어 있어요. 설계상 Kubernetes는 전체 매니페스트 집합을 가져와 모두 온라인 상태로 만들 수 있어요 (이것을 조정 루프(reconciliation loop)라고 해요).

하지만 CRD에는 차이가 있어요.

CRD의 경우 그 kind(들)의 리소스를 사용하기 전에 선언이 등록되어야 해요. 그리고 등록 과정은 때때로 몇 초가 걸려요.

방법 1: `helm`이 대신 처리하게 하기 (Method 1: Let `helm` Do It For You)

Helm 3가 등장하면서 우리는 더 단순한 방법을 위해 이전의 crd-install 훅을 제거했어요. 이제 차트에 CRD를 보관할 수 있는 crds라는 특수 디렉터리가 있어요. 이 CRD는 템플릿화되지 않지만 기본적으로 차트에 대해 helm install을 실행할 때 설치돼요. CRD가 이미 존재하면 경고와 함께 건너뛰어져요. CRD 설치 단계를 건너뛰고 싶으면 --skip-crds 플래그를 전달할 수 있어요.

몇 가지 주의 사항 (및 설명)

현재는 Helm을 사용한 CRD 업그레이드나 삭제를 지원하지 않아요. 의도하지 않은 데이터 손실에 대한 위험 때문에 많은 커뮤니티 논의 끝에 명시적으로 결정된 사항이에요. 게다가 현재 CRD와 그 수명주기를 처리하는 방법에 대한 커뮤니티 합의가 없어요. 이것이 발전함에 따라 Helm은 그러한 사용 사례에 대한 지원을 추가할 거예요.

helm install과 helm upgrade의 --dry-run 플래그는 현재 CRD에 대해 지원되지 않아요. "Dry Run"의 목적은 차트의 출력이 서버로 전송될 때 실제로 작동할지 검증하는 것이에요. 하지만 CRD는 서버 동작의 수정이에요. Helm은 dry run에서 CRD를 설치할 수 없으므로 discovery 클라이언트가 그 커스텀 리소스(CR)를 알지 못하고 검증이 실패할 거예요. CRD를 자체 차트로 옮기거나 helm template을 사용할 수도 있어요.

CRD 지원에 대한 논의에서 고려할 또 다른 중요한 점은 템플릿 렌더링이 처리되는 방식이에요. Helm 2에서 사용된 crd-install 방법의 뚜렷한 단점 중 하나는 변경되는 API 가용성 때문에 차트를 제대로 검증할 수 없다는 것이었어요 (CRD는 사실상 Kubernetes 클러스터에 사용 가능한 API를 하나 더 추가하는 것이에요). 차트가 CRD를 설치하면 helm은 더 이상 작동할 유효한 API 버전 집합을 갖지 못했어요. 이것이 CRD에서 템플릿 지원을 제거한 이유이기도 해요. 새로운 crds CRD 설치 방법을 통해 이제 helm이 클러스터의 현재 상태에 대해 완전히 유효한 정보를 갖도록 보장해요.

방법 2: 별도의 차트 (Method 2: Separate Charts)

이렇게 하는 또 다른 방법은 CRD 정의를 한 차트에 넣고, 그 CRD를 사용하는 리소스를 다른 차트에 넣는 것이에요.

이 방법에서는 각 차트를 별도로 설치해야 해요. 하지만 이 워크플로우는 클러스터에 대한 관리자 접근 권한이 있는 클러스터 운영자에게 더 유용할 수 있어요.