Приложение не получает трафик через Service, хотя поды в статусе Running — как системно найти причину?

Короткий ответ

Нужно последовательно проверить: совпадают ли selector Service и labels подов, есть ли endpoints у сервиса (kubectl get endpoints), проходят ли поды readiness probe, совпадает ли targetPort с реальным портом, на котором слушает приложение внутри контейнера, и не блокирует ли трафик NetworkPolicy.

Как это работает подробнее

Service — это абстракция поверх реального списка endpoint, который формируется автоматически только при точном совпадении меток и успешном readiness; даже один неверный символ в значении метки или в имени порта полностью разрывает эту цепочку без явной ошибки в логах приложения — проблема проявляется только на уровне сетевого взаимодействия.

Пример кода

Команды и выводКопировать

kubectl get endpoints backend
NAME      ENDPOINTS   AGE
backend   <none>      10m

Что использовать на практике

• Практика. первый диагностический шаг — kubectl get endpoints <service>: пустой список сразу сужает проблему до selector/labels/readiness, тогда как непустой список переключает фокус на targetPort, сетевые политики или на само приложение (слушает ли оно действительно указанный порт и интерфейс, например 0.0.0.0, а не только 127.0.0.1). Проверку порта внутри контейнера можно сделать через kubectl exec и curl localhost:<port> непосредственно в самом поде.

Подводные камни

• Риски. сразу подозревать Ingress или внешний балансировщик, не проверив базовый слой Service/Endpoints; путать port (порт самого Service) и targetPort (порт контейнера) — несовпадение targetPort с реальным портом приложения даёт непустые endpoints, но соединения всё равно будут обрываться; забывать, что приложение, слушающее только 127.0.0.1 внутри контейнера, недоступно даже при идеально настроенном Service.