Quiz: Deploying an Application via a CR

status 서브리소스가 켜진 CR 에 일반 update 로 status 를 쓰면?

• spec 과 status 가 모두 저장된다
• status 부분이 조용히 무시된다
• generation 이 증가한다
• 오류가 나며 요청이 거부된다

소유자 참조가 이름이 아니라 uid 로 연결되는 이유는?

• 이름은 네임스페이스가 다르면 중복될 수 있어 충돌하기 때문
• uid 가 이름보다 짧아 etcd 저장 공간을 아낄 수 있기 때문
• 이름은 라벨 셀렉터 매칭에만 쓰이고 참조에는 쓸 수 없기 때문
• 같은 이름의 부모를 지웠다 다시 만들면 다른 오브젝트이기 때문

conditions 에 reason 과 message 를 둘 다 두는 이유는?

• reason 은 이전 상태를, message 는 현재 상태를 담기 때문
• 알림 규칙은 reason 으로 분기하고 사람은 message 를 읽기 때문
• 쿠버네티스가 두 필드를 모두 요구하기 때문
• message 는 길이 제한이 있어 reason 으로 나눠 담기 때문

status.observedGeneration 이 metadata.generation 보다 작을 때의 의미는?

• status 서브리소스가 꺼진 채로 저장됐다
• 컨트롤러가 아직 최신 명세를 반영하지 못했다
• 저장 버전이 옛 버전이라 변환이 끝나지 않았다
• 오브젝트가 삭제 중이라 갱신이 멈췄다

CR 의 spec.tier 값과 metadata.labels.tier 라벨의 관계로 옳은 것은?

• spec.tier 와 라벨 중 하나만 있어도 라벨 셀렉터로 걸러 낼 수 있다
• 라벨은 metadata 에 있어도 status 를 통해서만 조회에 쓰인다
• spec 은 컨트롤러가 읽는 의도, 라벨은 사람과 도구가 고르는 색인으로 서로 다른 자리다
• spec.tier 에 값을 넣으면 API 서버가 같은 라벨을 자동으로 붙여 준다

spec 에 restartNow: true 같은 필드를 두는 것이 안티패턴인 이유는?

• 일회성 명령이라 실행 뒤 의미가 사라지고 조정 루프가 매번 다시 판단할 수 없어서
• 불리언 필드는 CEL 로도 OpenAPI 스키마로도 검증할 수 없어서
• true 를 기본값으로 두면 재시작이 무한히 반복되기 때문에
• 일회성 신호는 spec 이 아니라 status 에만 둘 수 있어서

status 에 이벤트 로그를 배열로 계속 쌓으면 생기는 문제는?

• 갱신할 때마다 오브젝트 전체가 다시 쓰이고 컨트롤러 캐시 메모리도 함께 부푼다
• 배열 크기가 커지면 status 서브리소스가 자동으로 꺼진다
• etcd 가 큰 배열 필드를 지원하지 않아 저장이 거부된다
• 배열이 자리를 차지해 conditions 를 함께 쓸 수 없게 된다