Quiz: The Operator Pattern and the Reconcile Loop

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

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

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

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

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

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

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

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

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

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

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

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

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

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