测验：本该只跑一次的结算跑了两次

정기 작업의 감시를 「총 실행 횟수」로만 하면 서머타임 사고를 못 잡는 이유는?

• 서머타임 기간에는 실행 기록이 다른 형식으로 쌓여 집계에서 빠지기 때문이다
• 건너뛴 한 번과 두 번 돈 한 번이 서로를 가려 총계가 기대치와 같아지기 때문이다
• 스케줄러가 놓친 실행을 나중에 몰아서 돌려 총계를 맞춰 주기 때문이다
• 총계는 하루 단위로만 세므로 새벽 시간대가 집계 창 밖으로 나가기 때문이다

쿠버네티스 CronJob 문서가 시간대를 UTC 로 고정한 뒤에도 Job 을 멱등하게 만들라고 요구하는 이유는?

• 컨트롤러가 일정마다 대략 한 번 Job 을 만들며 두 개가 생기거나 하나도 안 생길 수 있기 때문이다
• UTC 로 고정하면 서머타임 대신 윤초 때문에 중복이 생기기 때문이다
• 같은 네임스페이스의 다른 CronJob 이 같은 Job 을 다시 만들 수 있기 때문이다
• Job 이력 보관 한도를 넘으면 삭제된 Job 이 다시 생성되기 때문이다

concurrencyPolicy 의 Forbid 가 하는 일은?

• 앞 실행을 새 실행으로 갈아 끼운다
• 앞 실행이 끝날 때까지 새 실행을 대기열에 넣어 두었다가 이어서 돌린다
• 앞 실행이 아직 안 끝났으면 이번 실행을 건너뛴다
• 같은 네임스페이스의 다른 CronJob 까지 동시 실행을 막는다

되풀이 작업의 멱등성을 위한 실행 열쇠로 적절한 것은?

• 작업 이름과 실행 아이디를 이어 붙인 문자열
• 작업 이름과 실제로 시작한 시각을 이어 붙인 문자열
• 실행할 때마다 새로 만드는 UUID
• 작업 이름과 처리 대상 기간을 이어 붙인 문자열

겹침 방지와 멱등성이 서로 다른 문제라는 것을 가장 잘 보여 주는 경우는?

• 앞 실행이 실패해 재시도가 곧바로 다시 도는 경우
• 서머타임 종료로 같은 기간이 한 시간 간격을 두고 두 번 도는 경우
• 노드 장애로 Job 의 파드가 다른 노드에서 다시 뜨는 경우
• startingDeadlineSeconds 를 넘겨 실행이 건너뛰어지는 경우

CronJob 문서가 startingDeadlineSeconds 에 대해 따로 경고한 것은?

• 값을 0 으로 두면 모든 실행이 즉시 실패로 기록된다
• 이 값은 concurrencyPolicy 가 Forbid 일 때만 효력이 있다
• 10초보다 작게 두면 컨트롤러의 확인 주기 탓에 아예 스케줄되지 않을 수 있다
• 설정하지 않으면 기본값 100초가 적용되어 늦은 실행이 버려진다