퀴즈: CRD 작성과 배포

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. CRD 의 `metadata.name` 규칙으로 옳은 것은?

   1. 네임스페이스를 접두어로 붙인다
   2. `<복수형>.<그룹>` 형태여야 한다
   3. 임의로 지어도 되지만 63자를 넘길 수 없다
   4. kind 를 소문자로 바꾼 것

2. status 서브리소스를 켰을 때 컨트롤러 설계에 결정적인 효과는?

   1. status 가 etcd 가 아니라 apiserver 메모리 캐시에만 저장된다
   2. status 에 conditions 배열이 자동으로 만들어지고 서버가 관리해 준다
   3. status 를 써도 metadata.generation 이 올라가지 않아 spec 변경과 구분된다
   4. status 가 읽기 전용이 되어 사용자가 kubectl 로 볼 수 없게 된다

3. 스키마에 정의하지 않은 필드를 CR 에 넣고 적용하면 기본적으로 어떻게 되나요?

   1. annotation 으로 옮겨져 그대로 보존된다
   2. 스키마 위반으로 apply 가 거부된다
   3. 그대로 저장되고 컨트롤러가 알아서 무시한다
   4. 저장 전에 잘려 나가고 경고 없이 사라진다

4. `scale` 서브리소스에서 `labelSelectorPath` 가 필요한 이유는?

   1. 가비지 컬렉터가 소유자 참조 없이도 자식을 찾을 수 있게 하려고
   2. API 서버가 여러 버전 중 저장 버전을 고르기 위해
   3. HPA 가 그 셀렉터로 파드를 세어 메트릭을 계산하기 위해
   4. kubectl scale 이 대상 파드 집합을 찾기 위해

5. 한 CRD 가 v1alpha1 과 v1 을 함께 제공할 때 반드시 지켜야 하는 것은?

   1. storage 가 true 인 버전이 정확히 하나여야 한다
   2. 옛 버전은 served 를 false 로 둬야 한다
   3. 두 버전의 스키마가 완전히 같아야 한다
   4. 두 버전 모두 storage 를 true 로 둔다

6. 저장 버전을 v1alpha1 에서 v1 으로 바꾼 뒤 기존 오브젝트를 재저장하지 않으면 어떤 일이 생기나요?

   1. 옛 버전으로 저장된 오브젝트가 그대로 남아 있어 같은 이름의 새 오브젝트를 만들 수 없게 된다
   2. API 서버가 실제 저장 형식을 감지해 storage 플래그를 자동으로 옛 버전으로 되돌린다
   3. status.storedVersions 에 옛 버전이 남고, 그 스키마를 지우면 저장된 오브젝트를 읽을 수 없게 된다
   4. 읽을 때마다 스키마 변환이 자동으로 일어나므로 재저장을 건너뛰어도 아무 문제가 없다

7. 필드에 `default` 를 줄 수 있는데도 `required` 로 만들면 생기는 문제는?

   1. 그 필드가 spec 에서 status 로 자동으로 옮겨진다
   2. API 서버가 required 필드의 default 를 무시해 값이 비어 저장된다
   3. 그 필드에 대해서는 pruning 이 동작하지 않아 오타가 그대로 남는다
   4. 사용자가 매번 같은 값을 적어야 하고, 나중에 선택 필드로 낮추기 어려워진다