LabHub

CKA — 쿠버네티스 관리자 · 클러스터 아키텍처·설치·설정 · 실습

CRD 로 API 넓히기

LabHub 에서 이어서 보기

목표

CustomResourceDefinition 을 직접 작성해 쿠버네티스 API 를 넓히고, 스키마 검증이 실제로 요청을 거부하는 것을 확인하고, 새 리소스에 대한 권한을 Aggregated ClusterRole 로 붙입니다.

왜 중요한가

CKA 출제 범위에 CRD 가 들어간 이유는 오퍼레이터를 만들라는 뜻이 아닙니다. 오퍼레이터가 깔린 클러스터를 운영할 수 있느냐를 묻는 것입니다. 현장의 클러스터에는 이미 수십 개의 CRD 가 깔려 있습니다.

여기서 이해해야 할 구조가 있습니다. CRD 를 만들면 apiserver 에 새 엔드포인트가 생기고, 그 엔드포인트는 저장·검증·watch 를 제공합니다. 하지만 그것뿐입니다. 실제로 무언가를 하는 것은 그 CR 을 watch 하는 컨트롤러이고, 그건 별도 소프트웨어입니다. CR 을 만들었는데 아무 일도 안 일어난다면 대개 컨트롤러가 없거나 죽은 것입니다.

스키마도 같은 맥락입니다. apiextensions.k8s.io/v1 에서 schema 는 선택이 아니라 필수입니다. 스키마가 곧 그 API 의 계약이고, 잘못된 값을 컨트롤러가 아니라 apiserver 가 먼저 막아 줍니다.

단계

1. CRD widgets.labhub.io 를 만든다. group labhub.io, scope Namespaced, kind Widget, plural widgets, singular widget, shortNames 에 wg, 버전은 v1alpha1 하나이며 served 와 storage 모두 true.
2. 네임스페이스 cka-crd 를 만들고 그 안에 Widget demo 를 만든다. spec.replicas 는 3, spec.tiersmall.
3. CRD 의 v1alpha1 스키마를 고쳐 검증 규칙을 넣는다. spec.replicas 는 type integer 에 minimum 1, maximum 10. spec.tier 는 type string 에 enum [small, large]. spec 오브젝트의 required 는 [replicas, tier].
4. spec.replicas 가 99 인 Widget too-big 을 만들어 보고, 거부된 에러 출력을 /root/cka-crd/reject.txt 에 저장한다. too-big 은 생성되지 않아야 한다.
5. v1alpha1 에 additionalPrinterColumns 두 개를 추가한다. 이름 REPLICAS (type integer, jsonPath .spec.replicas), 이름 TIER (type string, jsonPath .spec.tier).
6. CRD clusterwidgets.labhub.io 를 만든다. scope Cluster, kind ClusterWidget, plural clusterwidgets, group labhub.io, 버전 v1alpha1. 그리고 ClusterWidget global 을 만든다.
7. ClusterRole cka-widget-viewer 를 만든다. 라벨 rbac.labhub.io/aggregate-to-widget=true, 규칙은 apiGroups labhub.iowidgets 에 대해 get, list, watch. 그리고 ClusterRole cka-widget-aggregate 를 만들어 aggregationRule 이 그 라벨을 셀렉터로 고르게 한다.

참고

단계 7개

  1. CustomResourceDefinition 만들기
  2. 커스텀 리소스 만들기
  3. 스키마에 검증 규칙 넣기
  4. 검증이 거부하는 순간 확인하기
  5. kubectl get 출력에 컬럼 추가하기
  6. 클러스터 스코프 CRD 만들기
  7. Aggregated ClusterRole 로 권한 넓히기