Quiz: Why did the delivery stop?

Pod가 Running인데 Service 요청은 실패합니다. 먼저 구분할 사실은?

• Pod 직접 요청과 Service 요청의 차이
• 클러스터의 모든 노드를 재시작할 순서
• 새 이미지를 강제로 다시 받을 주기
• 모든 정상 Pod를 삭제할 우선순위

Service selector만 app=missing으로 바꿨습니다. 가장 잘 맞는 관측은?

• Pod도 같은 라벨로 자동 변경된다
• Pod는 응답하지만 선택된 주소가 없어진다
• Deployment 리비전이 반드시 증가한다
• 같은 컨테이너의 재시작 횟수가 증가한다

EndpointSlice의 endpoints가 null이면 관측기는 어떻게 해야 하나요?

• 컨트롤 플레인이 죽었다고 즉시 확정한다
• 직전의 정상 주소를 계속 사용한다
• 대상 주소가 없는 상태로 해석한다
• 첫 Pod의 주소를 대신 채워 넣는다

kubectl patch가 성공했지만 바로 보낸 요청은 실패했습니다. 적절한 해석은?

• API 성공이므로 요청 실패는 무시한다
• 다른 네임스페이스까지 함께 수정한다
• 모든 컨테이너 이미지를 다시 빌드한다
• 반영 지연과 실제 데이터 경로를 확인한다

Pod 직접 요청 성공만으로 주장할 수 있는 것은?

• 그 Pod의 해당 HTTP 경로가 응답했다
• 외부 DNS와 TLS도 모두 정상이다
• Service의 대상 포트가 반드시 맞다
• 모든 고객의 업무가 복구됐다

Pod IP의 8080번은 성공하지만 Ready 주소가 있는 Service IP의 8080번은 실패합니다. 다음 비교로 가장 직접적인 것은?

• ClusterIP 직접 요청의 외부 DNS 전파 시간
• Service targetPort와 실제 수신 포트
• Pod 재시작 횟수와 요청 본문의 글자 수
• Ingress TLS 인증서와 Pod 이미지 태그