Spot Overclaims in a Termination Report

삭제되는 Pod의 endpoint가 ready=false로 관측됐습니다. 이 값만으로 내릴 수 없는 결론은 무엇인가요?

• 종료 중 endpoint는 일반 준비 상태와 구분해 읽어야 한다
• 이미 서버가 수락한 HTTP 요청도 즉시 끊겼다
• 기존 요청 결과는 별도의 응답 관측으로 확인해야 한다
• serving과 terminating도 함께 읽을 필요가 있다

Deployment 템플릿에 preStop을 처음 추가하는 롤아웃을 측정했습니다. 옛 Pod의 훅 효과를 평가하려면 무엇을 먼저 확인해야 하나요?

• 새 ReplicaSet의 이름만 이전 이름과 다른지 확인한다
• 변경된 Deployment YAML에 lifecycle이 있는지 확인한다
• 롤아웃 완료 메시지에 오류가 없는지 확인한다
• 실제 종료 대상 Pod의 UID와 기존 lifecycle을 확인한다

preStop에 3초가 걸립니다. terminationGracePeriodSeconds를 계획할 때 올바른 설명은 무엇인가요?

• 훅 시간과 TERM 뒤 필요한 정리를 같은 유예 안에서 고려한다
• 훅이 끝난 시점에 선언된 유예 전체가 새로 시작된다
• 훅이 성공하면 처리 중 요청은 유예와 무관하게 끝까지 기다린다
• 훅의 sleep은 종료 유예 계산에서 제외되는 별도 시간이다

컨테이너 종료 코드 137과 클라이언트 단절을 확인했습니다. 다음 판단 중 가장 타당한 것은 무엇인가요?

• 137은 항상 메모리 부족이므로 유예 설정은 볼 필요가 없다
• 137이면 네트워크 연결 문제이므로 서버 신호 처리는 무관하다
• 종료 사유·실제 유예·신호 관측을 함께 확인해 원인을 좁힌다
• 단절을 관측했으므로 어떤 Pod가 응답했는지는 확인하지 않는다

Pod Ready 직후 보낸 첫 Service 요청이 연결 시간 초과로 끝났습니다. 종료 실험 결과로 쓰기 전에 무엇이 부족한가요?

• 클라이언트 재시도 횟수를 늘렸다는 기록
• 새 Pod의 이름을 이전 이름과 같게 만든 기록
• preStop 문자열이 파일에 한 번 나타난다는 기록
• Service 경로 준비와 삭제 전 서버 수락을 확인한 기록

정상 종료 앱이 이미 수락한 8초 작업을 처리 중이고 preStop도 실행됩니다. 시간 해석으로 적절한 것은 무엇인가요?

• work 전체 시간에 훅 시간을 더하면 언제나 정확한 종료 시각이다
• 작업과 훅이 겹칠 수 있어 각 이벤트와 TERM 뒤 잔여 시간을 본다
• graceful 모드라면 처리 시간이 유예보다 길어도 항상 완료된다
• API 삭제 요청 시각부터 모든 노드가 같은 속도로 종료한다

재채점 때 이미 삭제된 Pod를 새로 만들어 동일 실험을 다시 수행하면 어떤 문제가 생기나요?

• 이전 결과를 검사하지 않고 새 실행으로 바꾸며 상태도 변경한다
• 관측된 과거 Pod UID를 그대로 보존하므로 오히려 더 정확하다
• 두 실행의 결과가 같으면 서로 다른 UID를 구분할 필요가 없다
• Kubernetes는 같은 이름을 재사용할 때 이전 연결도 복구한다

단일 k3s Service의 요청 하나가 종료 중 정상 완료됐습니다. 보고서에 쓸 수 있는 결론은 무엇인가요?

• 외부 로드밸런서가 있는 운영 서비스도 모든 요청이 무중단이다
• 같은 설정이면 임의의 작업 시간과 트래픽량도 항상 안전하다
• 이 실행의 해당 Pod가 수락한 요청은 종료 중 완료됐다
• 종료 처리만 구현하면 업무 재시도의 멱등성은 필요 없어졌다