测验：安装与运维

Kyverno 의 네 컨트롤러 중 어떤 설치에서도 반드시 포함되어야 하는 것은?

• reports controller — 보고서 없이는 정책 상태를 알 수 없다
• background controller — generate 규칙이 여기서 돈다
• admission controller — API 서버의 웹훅 콜백을 받는다
• cleanup controller — 정리 정책과 TTL 라벨을 처리한다

reports controller 의 복제본을 3개로 늘리면 얻는 것은?

• 가용성만 얻고 처리량은 리더 한 개가 하므로 그대로다
• 복제본이 보고서를 나눠 처리해 처리량이 3배가 된다
• 백그라운드 스캔이 세 파드에 분산되어 지연이 준다
• 웹훅 요청이 분산되어 어드미션 지연이 줄어든다

Kyverno 를 새 버전으로 올릴 때 이미지 태그만 바꾸면 안 되는 이유로 문서가 드는 것은?

• 태그를 바꾸면 Helm 릴리스 이름이 바뀌어 values 가 초기화된다
• 새 이미지는 이전 버전의 인증서 Secret 을 읽지 못한다
• 웹훅 설정이 이미지 안에 있어 재설치해야만 갱신된다
• CRD 를 포함해 함께 바뀌는 지원 리소스가 많기 때문이다

정책과 리소스와 기대 결과(pass·fail·skip)를 미리 적어 두고 실제 결과와 비교하는 CLI 명령은?

• kyverno apply — 정책을 리소스에 적용해 결과를 보여 준다
• kyverno test — kyverno-test.yaml 의 기대 결과와 비교한다
• kyverno jp query — JMESPath 식을 파일에 대해 평가한다
• kyverno migrate — 저장된 오브젝트를 새 저장 버전으로 옮긴다

apiCall 컨텍스트에 넣을 JMESPath 식이 맞는지 클러스터 응답으로 미리 확인하는 방법으로 문서가 권하는 것은?

• kubectl get --raw 의 출력을 kyverno jp query 로 파이프한다
• kyverno apply 에 --registry 를 붙여 API 응답을 가져온다
• 정책을 audit 모드로 넣고 PolicyReport 의 메시지를 읽는다
• kyverno create values 로 응답을 values 파일에 넣는다

kyverno_policy_results 지표에서 규칙이 어드미션 요청 때문에 실행됐는지 백그라운드 스캔 때문에 실행됐는지를 구분하는 라벨은?

• policy_background_mode — 정책의 background 설정값
• rule_type — validate·mutate·generate 중 무엇인가
• resource_request_operation — create·update·delete
• rule_execution_cause — admission_request 또는 background_scan