퀴즈: 설치·운영

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

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

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

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

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

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

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

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

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

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

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

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

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