クイズ: mutateとgenerate

추가 앵커 +(cpu): 200m 의 동작으로 옳은 것은?

• cpu 값이 200m 과 같은지 검사해서 다르면 그 요청을 거부한다
• cpu 키를 지워서 네임스페이스의 기본값이 적용되게 한다
• 값이 이미 있든 없든 cpu 를 항상 200m 으로 덮어쓴다
• cpu 가 없을 때만 200m 을 넣고, 이미 있으면 건드리지 않는다

컨테이너 개수가 정해지지 않은 파드의 모든 컨테이너에 같은 값을 넣어야 합니다. 적절한 방식은?

• patchesJson6902 로 /spec/containers/0 부터 인덱스를 늘려 가며 넣는다
• foreach 로 request.object.spec.containers 를 돌며 element 를 쓴다
• patchStrategicMerge 로 containers 배열을 통째로 새로 써서 교체한다
• generate 규칙으로 값이 채워진 컨테이너를 필요한 만큼 새로 만든다

레지스트리 시크릿을 여러 네임스페이스에 배포할 때 data 대신 clone 을 쓰는 이유는?

• 정책 파일은 보통 git 에 들어가므로 시크릿 내용을 정책에 적으면 그대로 유출되기 때문
• clone 은 원본이 바뀌어도 사본이 알아서 따라가 동기화 설정이 필요 없기 때문
• clone 이 값을 직접 적는 방식보다 리소스 생성 속도가 훨씬 빠르기 때문
• data 방식은 ConfigMap 만 만들 수 있고 Secret 은 지원하지 않기 때문

generate.synchronize: true 를 켰을 때의 동작은?

• 생성 시점에 한 번만 만들고 이후에는 관여하지 않는다
• 트리거 네임스페이스가 지워져도 생성물은 남는다
• 생성된 리소스를 누가 고치면 정책이 원래 상태로 되돌린다
• 생성 대신 검증만 수행한다

생성 정책을 걸었는데 요청은 성공하는데 리소스가 만들어지지 않습니다. 가장 먼저 의심할 것은?

• 백그라운드 컨트롤러에 그 리소스 종류를 만들 RBAC 권한이 없는 것
• 트리거 리소스의 이름이 너무 길어 생성될 이름이 한도를 넘긴 것
• synchronize: true 가 켜져 있어 생성이 뒤로 보류된 것
• 정책 YAML 의 들여쓰기가 어긋나 generate 규칙이 무시된 것

mutate.targets 를 쓰는 규칙의 성격으로 옳은 것은?

• 요청으로 들어온 트리거 리소스 자신을 어드미션 단계에서 곧바로 고친다
• validate 규칙에만 붙일 수 있고 mutate 규칙에서는 쓰지 못한다
• 정책이 바뀌면 이미 존재하는 대상 전체를 자동으로 다시 고쳐 준다
• 트리거가 아닌 다른 리소스를 고치며, 백그라운드에서 돌기 때문에 추가 권한이 필요하다

차트 기본값으로 두어야 할 값을 변형 정책으로 넣었을 때 생기는 문제는?

• 변형 규칙에는 통과·실패 판정이 없어 PolicyReport 에 아무런 기록도 남지 않게 된다
• 매니페스트와 실제 오브젝트가 달라져 배포 도구의 드리프트 감지와 계속 충돌하고, 나중에 누가 넣었는지 추적하기 어렵다
• 채워 넣을 기본값 수만큼 규칙이 늘어 모든 요청의 정책 평가 시간이 함께 길어진다
• 차트 기본값을 대신하는 변형은 검증 규칙보다 나중에 실행되어 아예 걸러지지 않는다