Quiz: Why CRDs

CRD 를 적용했을 때 API 서버가 '공짜로' 제공하는 것이 아닌 것은?

• CR 이 선언한 대로 파드를 띄우는 동작
• 스키마 기반 검증과 기본값 주입
• etcd 저장과 watch 스트림
• 리소스 단위 RBAC 와 감사 로그

Helm values 대신 CR 을 쓸 때 얻는 가장 구조적인 이득은?

• 잘못된 값이 배포 시점이 아니라 apply 시점에 거부된다
• 템플릿 문법이 사라져 작성해야 할 YAML 이 크게 줄어든다
• 차트에 들어가던 설정이 빠져 컨테이너 이미지 크기가 줄어든다
• 차트 재렌더링이 없어져 클러스터 업그레이드가 쉬워진다

다음 중 CRD 를 만들지 않는 편이 나은 상황은?

• 새벽 장애에 사람이 개입하던 복구 절차를 코드로 옮기려 한다
• Deployment 와 HPA 만으로 충분한 스테이트리스 웹앱을 배포한다
• 데이터베이스의 페일오버와 백업 검증까지 자동화해야 한다
• 여러 팀에 표준화된 배포 인터페이스를 API 로 제공해야 한다

필드 간 제약(예: prod 계층이면 복제본 2 이상)을 표현하는 2026년 기준 권장 방법은?

• 컨트롤러의 reconcile 안에서 검사하고 status 에 오류로 기록
• CI 파이프라인에서 매니페스트를 정적 검사해 머지 단계에서 차단
• 스키마의 x-kubernetes-validations 에 CEL 규칙으로 선언
• 검증 웹훅 서버를 띄워 admission 단계에서 필드 조합을 검사

"CRD 는 코드가 아니라 API 계약" 이라는 말의 실무적 함의는?

• CRD 는 클러스터마다 다르게 정의해 환경 차이를 흡수해야 한다
• CRD 는 컨트롤러가 준비된 뒤에 배포해야 오류가 나지 않는다
• 한 번 공개한 필드는 저장된 오브젝트와 사용자 매니페스트 때문에 되돌리기 어렵다
• CRD 는 선언형 YAML 이라 Go 타입 정의에서 생성할 수 없다

오퍼레이터 도입을 검토할 때 가장 먼저 확인해야 할 것은?

• 팀이 Go 와 컨트롤러 런타임을 다룰 수 있는지
• 이미 잘 관리되는 공식·커뮤니티 오퍼레이터가 있는지
• 컨트롤러를 상시 돌릴 클러스터 노드 여유가 충분한지
• CRD 의 그룹과 복수형 이름을 무엇으로 할지

CR 을 라벨 셀렉터로 골라낼 수 있는 이유는?

• CRD 를 만들 때 스키마에 라벨 셀렉터 필드를 정의해 두었기 때문
• 컨트롤러가 CR 을 캐시하며 라벨 인덱스를 따로 만들기 때문
• kubectl 이 전체 목록을 받아 클라이언트에서 필터링하기 때문
• CR 도 다른 오브젝트와 같은 metadata 를 가진 정식 API 오브젝트이기 때문