새 배포는 정상적으로 Running 상태지만, 서비스 뒤에 붙은 Endpoint가 비어 있어 실제 트래픽이 전달되지 않습니다. 운영자는 파드가 살아 있다는 이유로 애플리케이션 문제만 보고 있지만, selector와 readiness probe 조건이 어긋나면서 Service 경로가 중간에서 끊긴 상태입니다.
Running 상태인데 트래픽을 받지 못하는 서비스 장애 분석
Kubernetes 원문 시나리오에서 주요 증상 신호를 기준으로 근본 원인과 안전한 복구 방향을 정리하는 문제입니다.
시나리오
먼저 볼 것
- Pod 상태와 서비스 가용성이 다를 수 있다는 점을 이해합니다.
- Service, Endpoint, readiness, selector를 하나의 경로로 연결해 점검합니다.
- 트래픽 장애를 네트워크 문제와 애플리케이션 문제로 나누기 전에 서비스 경로를 먼저 검증합니다.
점검 체크리스트
- Service selector와 Deployment labels가 정확히 일치하는지 확인합니다.
- readiness probe 실패로 Endpoint 등록이 제외되고 있지 않은지 확인합니다.
- kubectl get svc,ep,pod 결과를 같은 namespace 기준으로 나란히 비교합니다.
복구와 재발 방지
서비스 영향을 줄이는 가장 작은 조치를 먼저 선택하고, 이후 rollout 재시도, 설정 되돌리기, probe 조정, 트래픽 우회를 재발 방지 항목으로 분리합니다.
같이 보면 좋은 질문
네. 제목과 시나리오는 실제 장애 단서이므로 그대로 유지합니다. 한국어 풀이는 판단 순서와 답안 구조를 돕기 위한 보조 설명입니다.
아니요. Pod event, rollout, Service/Endpoint 같은 기술 용어와 kubectl 같은 명령어는 영어 원문을 유지하세요.
사용자 영향, 관찰한 근거, 최근 변경, 안전한 복구 방향을 한 번에 연결해 설명하는 것입니다.
현장에서 본 비슷한 케이스