K8s 망가뜨리기 — 범인은 내 YAML · 정상인데 왜 배송되지 않을까 · 퀴즈
퀴즈: 정상인데 왜 배송되지 않을까
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
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 이미지 태그