クイズ: アドミッション制御とKyvernoの構造

kubectl apply 요청이 API 서버 안에서 지나는 순서로 올바른 것은?

• 인가 → 인증 → validating admission → mutating admission → etcd
• 인증 → 인가 → mutating admission → 스키마 검증 → validating admission → etcd
• 인증 → mutating admission → 인가 → validating admission → etcd
• 인증 → 인가 → validating admission → mutating admission → etcd

사이드카를 주입하는 mutate 정책과 모든 컨테이너에 리소스 리밋을 요구하는 validate 정책을 함께 걸었더니 배포가 막혔다. 로그에는 사용자가 쓰지 않은 컨테이너 이름이 찍혔다. 원인은?

• validate 가 mutate 보다 먼저 돌아 원본 스펙만 검사했다
• 두 정책의 match 블록이 겹쳐 중복 평가됐다
• mutate 가 먼저 돌아 주입된 사이드카까지 validate 검사 대상이 됐는데, 주입 스펙에 리밋이 없었다
• background 컨트롤러가 리밋을 지웠다

Kyverno 의 세 컨트롤러를 나눈 이유로 가장 적절한 것은?

• 고가용성을 위해 세 컨트롤러가 서로 똑같은 일을 중복으로 수행하도록 일부러 만들어 둔 것이기 때문에
• 라이선스 문제로 기능을 분리해야 했기 때문
• admission 은 밀리초 안에 답해야 하고 background 는 오래 걸려도 되며 reports 는 쓰기가 많아, 한 프로세스에 두면 리포트 집계가 밀릴 때 배포가 함께 밀리기 때문
• 쿠버네티스가 컨트롤러당 하나의 CRD 만 허용하기 때문

Kyverno 의 기본 failurePolicy 인 Fail 이 가용성 문제로 이어지는 경로를 가장 정확히 설명한 것은?

• Fail 로 두면 정책이 위반을 PolicyReport 에만 남기고 요청은 그대로 통과시킨다
• Fail 은 background 컨트롤러의 스캔 주기를 늘린다
• Fail 은 PolicyReport 생성을 막는다
• 와일드카드 매치로 모든 요청이 웹훅을 타는데, 웹훅이 타임아웃 안에 응답하지 못하면 요청이 거부되므로 Kyverno 가 느려지는 순간 클러스터가 멈춘다

Kyverno 의 웹훅 타임아웃에 대한 설명으로 옳은 것은?

• 기본값은 30초이고 상한이 없다
• 기본값은 10초이고 1에서 30초 사이만 설정할 수 있다
• 기본값은 60초이고 5초 단위로만 설정할 수 있다
• 타임아웃은 설정할 수 없고 항상 API 서버 기본값을 따른다

정책 오브젝트가 목록에 정상으로 보이는데 아무것도 막히지 않는다. 가장 먼저 의심할 것 두 가지는?

• 웹훅 설정이 등록됐는지, 그리고 match 블록이 실제로 무언가를 고르는지
• PolicyReport 용량과 etcd 디스크
• 노드 수와 CNI 종류
• Kyverno 라이선스와 네임스페이스 이름