종료 보고서에서 과장된 결론 찾기

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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