퀴즈: 오퍼레이터 운영

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

1. 오퍼레이터 설치에서 CRD 가 컨트롤러 Deployment 보다 먼저 들어가야 하는 이유는?

   1. CRD 매니페스트가 컨트롤러 Deployment 의 이미지 태그를 참조하기 때문
   2. 가비지 컬렉터가 소유자 참조를 만들려면 CRD 가 먼저 있어야 하기 때문
   3. CRD 등록에 시간이 걸려 컨트롤러가 먼저 뜨면 타임아웃되기 때문
   4. 컨트롤러가 기동 직후 그 타입을 watch 하므로 타입이 없으면 크래시 루프에 빠지기 때문

2. RBAC 에서 `webservices` 에 update 권한을 줬는데 컨트롤러가 status 를 못 씁니다. 원인은?

   1. CRD 에서 status 서브리소스가 꺼져 있어 쓰기가 무시된다
   2. CRD 는 클러스터 범위라 ClusterRole 대신 Role 을 써야 한다
   3. status 는 새로 만드는 것이라 update 대신 create 권한이 필요하다
   4. `webservices/status` 는 별개의 리소스라 따로 권한을 줘야 한다

3. ClusterRoleBinding 의 subject 이름을 실제 서비스 어카운트와 다르게 적으면?

   1. 바인딩은 정상 생성되고 컨트롤러만 403 을 맞는다
   2. 존재하지 않는 주체라 기본 서비스 어카운트로 대체된다
   3. 주체 존재 검증에 걸려 바인딩 적용이 거부된다
   4. 가장 비슷한 이름의 서비스 어카운트로 자동 교정된다

4. 컨트롤러에 `delete` 권한을 주지 않아도 되는 경우가 많은 이유는?

   1. CRD 를 지우면 그 타입의 자식이 자동으로 함께 정리되기 때문
   2. 삭제 요청이 status 서브리소스 경로로 처리되기 때문
   3. 자식 정리를 소유자 참조와 가비지 컬렉터에 맡길 수 있기 때문
   4. kubectl delete 가 클라이언트에서 대신 정리해 주기 때문

5. 리더 선출이 필요한 이유로 가장 정확한 것은?

   1. 대기 중인 복제본이 캐시를 비워 전체 메모리 사용량을 줄이려고
   2. 복제본 하나만 watch 를 열어 API 서버 rate limit 을 피하려고
   3. 여러 복제본이 같은 오브젝트를 동시에 조정해 충돌하는 것을 막으려고
   4. 여러 복제본이 오브젝트를 나눠 맡아 부하를 분산하게 하려고

6. 오퍼레이터를 업그레이드하면서 CRD 의 옛 버전 스키마를 함께 지우면 위험한 이유는?

   1. kubectl 이 그 버전의 스키마를 디스커버리 캐시에 들고 있어 요청이 깨지기 때문
   2. status.storedVersions 에 그 버전이 남아 있으면 저장된 오브젝트를 읽을 수 없게 되기 때문
   3. CRD 의 versions 목록은 추가만 되고 제거는 API 서버가 거부하기 때문
   4. 옛 컨트롤러 이미지가 그 버전의 Go 타입을 컴파일 시점에 직접 참조하기 때문

7. 권한 검증표에 "되면 안 되는 것" 을 함께 넣는 이유는?

   1. RBAC 는 거부 규칙을 명시해야 하기 때문
   2. 허용만 확인하면 권한이 과하게 열려 있어도 통과하기 때문
   3. 채점을 어렵게 만들기 위해
   4. kubectl auth can-i 가 no 응답에서만 정확하기 때문