Ingress отдаёт 503, хотя Pod у Service вроде живы — проследите, где теряется трафик.
Ingress отдаёт 503 для приложения, но поды работают. Проследите путь запроса Ingress → Service → endpoints → Pod, найдите, где он рвётся, и дайте фикс.
$ curl -sI https://app.example.com/ | head -1
HTTP/2 503
$ kubectl get pods -l app=api
NAME READY STATUS RESTARTS AGE
api-abc 0/1 Running 0 2m
api-def 0/1 Running 0 2m
$ kubectl get endpoints api
NAME ENDPOINTS AGE
api <none> 30mДиагностируйте и исправьте.
503 при пустом kubectl get endpoints api значит, что у Service нет готовых бэкендов, kube-proxy некуда маршрутизировать. Две причины: readiness не проходит, поды 0/1 Running и вне Service, либо selector не совпадает с метками подов.
- ✗Винить Ingress-контроллер до проверки endpoints у Service
- ✗Забывать, что не-Ready под убирается из endpoints Service
- ✗Упускать селектор Service, не совпадающий с метками подов
- →Чем readiness-проба отличается от liveness в этом сбое?
- →Какой командой сверить селектор Service с метками работающего пода?
Решение
1. Идём по пути запроса
Ingress → Service → Endpoints → Pod
$ kubectl get endpoints api # api <none> ← обрыв здесьendpoints пуст → у Service нет готовых бэкендов, поэтому Ingress отдаёт 503 (нет upstream). Значит, дело между Service и подами.
2. Две причины пустых endpoints
endpoints. Смотрите describe pod → Readiness probe failed, чините пробу/приложение.
тогда endpoints пуст, даже если поды 1/1 Ready.
- Readiness не проходит: поды
0/1 Running(как здесь) — не-Ready под исключён из - Селектор не совпадает:
Service.spec.selectorне матчитmetadata.labelsподов —
3. Как различить и фикс
$ kubectl get pod api-abc -o jsonpath='{.metadata.labels}' # метки пода
$ kubectl get svc api -o jsonpath='{.spec.selector}' # селекторСовпадают, но endpoints пуст → readiness. Не совпадают → поправьте селектор/метки.
