CKAD — 쿠버네티스 애플리케이션 개발자 · 배치는 성공했는데 택배는 두 번 나갔다 · 퀴즈

퀴즈: 배치 재시도와 중복 부작용

LabHub 에서 이어서 보기

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

completions: 1인 Job이 Complete이고 원장에는 같은 주문의 배송이 두 건 있습니다. 가장 정확한 해석은?
1. 실행 완료 조건과 외부 업무의 처리 횟수는 별도로 확인해야 한다
2. Complete 조건이 배송 한 건을 보증하므로 원장 집계부터 제외해야 한다
3. 성공한 Pod가 하나이면 실패 Pod의 요청은 외부에서도 취소된다
4. parallelism을 1로 설정했다면 같은 주문의 중복 저장은 발생할 수 없다
restartPolicy: Never인데 같은 Job 소유의 Pod A는 Failed, Pod B는 Succeeded이고 두 컨테이너의 restartCount는 0입니다. 무엇을 구분한 관측인가요?
1. 컨테이너가 같은 Pod 안에서 재시작해도 restartCount는 변하지 않는다
2. Pod 내부 재시작 없이 Job 컨트롤러가 대체 Pod를 만들 수 있다
3. Never 설정이 있었으므로 두 Pod는 서로 다른 Job에 속해야 한다
4. 새 Pod가 생겼으므로 실패한 Pod의 외부 요청은 존재하지 않는다
backoffLimit: 0인 Job이 저장 직후 실패했고 합성 배송은 한 건 남았습니다. 운영자가 새 Job으로 재실행하기 전에 할 일은?
1. 실패한 Job이므로 부작용은 없다고 보고 새 업무 키로 다시 실행한다
2. 재시도 제한을 더 크게 바꾸면 기존 배송이 자동 취소되는지 기다린다
3. 안정적인 업무 키로 기존 처리 결과를 확인하고 재실행 계약을 적용한다
4. 실패 Pod를 삭제하면 원장도 초기화되므로 먼저 Pod부터 지운다
같은 업무 키의 요청 두 개가 동시에 도착할 때 합성 원장이 배송을 한 번만 만들도록 하는 핵심 계약은?
1. 두 클라이언트가 각자 새 UUID를 만든 뒤 중복 조회를 생략한다
2. 각 Pod의 메모리에 처리 완료를 적고 다른 Pod의 상태는 보지 않는다
3. 조회와 삽입을 나눈 뒤 둘 다 없다고 판단하면 각각 행을 추가한다
4. 유일한 업무 키와 하나의 쓰기 트랜잭션으로 조회·삽입을 처리한다
다른 이름의 Job으로 같은 업무를 재실행해도 중복 배송을 만들지 않으려면 어떤 값을 유지해야 하나요?
1. 논리적인 업무 범위와 주문을 식별하는 안정적인 키
2. 새 Job이 생성될 때 API 서버가 부여한 고유 UID
3. 각 실행 프로세스가 시작할 때 새로 만든 무작위 키
4. 요청을 보내는 Pod의 새 이름과 컨테이너 시작 시각
안전한 모드에서 Job 재시도와 별도 Job 재실행까지 요청은 세 번, 배송은 한 건입니다. 보존해야 할 관측 자료는?
1. 배송이 한 건이므로 첫 요청만 남기고 중복 요청 이력은 삭제한다
2. 세 요청의 실행 식별자와 같은 배송 번호를 가리키는 연결을 남긴다
3. 최종 Job의 Complete 조건만 남기고 원장과 실패 Pod는 제외한다
4. 요청 횟수와 배송 횟수가 같아지도록 두 번째 배송 행을 보충한다
Job이 activeDeadlineSeconds를 넘겨 DeadlineExceeded로 실패했습니다. 프로그램은 종료 전에 배송을 저장했습니다. 어떤 결론이 맞나요?
1. 시간 제한이 끝나면 그 Job의 외부 저장도 같은 시각에 취소된다
2. backoffLimit이 남아 있으면 시간 제한 이후에도 계속 재시도한다
3. 실행 종료와 업무 취소는 다르므로 남은 배송 결과를 따로 확인한다
4. Failed 조건이 있으므로 원장에 남은 배송은 성공으로 집계할 수 없다
CronJob에 concurrencyPolicy: Forbid를 지정했습니다. 멱등 처리에 대한 올바른 설명은?
1. 같은 주문을 처리하는 모든 수동 Job도 서로 겹치지 않게 막는다
2. 다른 CronJob에서 시작한 같은 업무도 하나의 실행으로 자동 합친다
3. 실패 후 외부 원장에 저장된 중복 결과는 CronJob이 자동 제거한다
4. 같은 CronJob의 실행 겹침 제한과 업무 중복 처리 계약은 별개다