퀴즈: 오퍼레이터 패턴과 리컨사일 루프

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

1. 리컨사일 함수에 전달되는 것은 무엇인가요?

   1. 오브젝트의 키(네임스페이스/이름)뿐
   2. 변경 전후의 diff
   3. watch 이벤트의 원본 JSON
   4. 변경된 오브젝트 전체와 이벤트 종류

2. 멱등한 리컨사일의 가장 실용적인 판정 기준은?

   1. 두 번째 실행에서 오류 없이 같은 결과 코드가 돌아오는 것
   2. 리컨사일 실행 시간이 회차마다 거의 같은 값으로 유지되는 것
   3. 이미 맞는 상태에서 하위 오브젝트의 resourceVersion 이 바뀌지 않는 것
   4. 두 번째 실행 로그에 changed 나 updated 가 찍히지 않는 것

3. 외부 의존 대상이 아직 준비되지 않았을 때 올바른 처리는?

   1. status 에 실패로 기록하고 다음 이벤트까지 기다린다
   2. 에러를 반환해 워크큐의 지수 백오프 재시도에 맡긴다
   3. 준비될 때까지 리컨사일 함수 안에서 폴링하며 기다린다
   4. 에러가 아닌 지연 재큐로 '조금 뒤에 다시 보자'를 표현한다

4. 컨트롤러가 자기 status 쓰기 때문에 무한 리컨사일에 빠지는 것을 막는 표준 방법은?

   1. generation 이 바뀐 이벤트만 처리하는 필터를 건다
   2. 리컨사일 사이에 sleep 을 넣어 재호출 간격을 벌린다
   3. 워커 동시성을 1로 낮춰 중복 처리와 재호출을 없앤다
   4. status 를 annotation 으로 옮겨 감시 대상에서 뺀다

5. 파이널라이저가 붙은 오브젝트에 삭제를 요청하면 무슨 일이 일어나나요?

   1. 파이널라이저가 남아 있는 동안 삭제 요청이 거부되고 오류가 반환된다
   2. API 서버가 파이널라이저를 자동으로 제거한 뒤 오브젝트를 지운다
   3. 오브젝트는 즉시 삭제되고 컨트롤러에게 정리하라는 알림이 간다
   4. deletionTimestamp 가 찍히고 오브젝트는 남으며 리컨사일이 다시 불린다

6. 파이널라이저 안의 정리 함수가 멱등하지 않으면 생기는 대표적 사고는?

   1. 정리가 두 번 돌아 오브젝트가 두 번 삭제되고 이벤트도 두 번 남는다
   2. 이미 없는 자원을 지우려다 실패해 파이널라이저가 떨어지지 않고 삭제가 영원히 끝나지 않는다
   3. 가비지 컬렉터가 자식뿐 아니라 부모 오브젝트까지 함께 지워 버린다
   4. 정리가 재시도될 때마다 status 의 conditions 가 빈 값으로 초기화된다

7. 소유자 참조로 이어진 자식이 있는데도 파이널라이저가 필요한 경우는?

   1. 정리해야 할 대상이 클러스터 밖에 있어 가비지 컬렉터가 모를 때
   2. status 서브리소스를 켜서 조건을 기록해야 할 때
   3. 부모 하나에 자식 오브젝트가 여러 개 매달려 있을 때
   4. 자식이 부모와 다른 네임스페이스에 만들어져 있을 때