В Kubernetes приложение может работать внутри pod, но быть недоступным снаружи через ingress. Обычно проблема в связке ingress - service - endpoints.

Почему это важно

Маршрут ломается из-за неверных labels, пустых endpoints, перепутанных port/targetPort, неправильного ingressClass, TLS-секрета или path rewrite.

Что проверяю в первую очередь

  • Есть ли endpoints у service.
  • Совпадают ли labels selector и pod labels.
  • Правильные ли port и targetPort.
  • Какой ingressClass использует объект.
  • Что пишут логи ingress controller.

Как исправляю

Я проверяю маршрут по слоям: pod отвечает, service видит pod, ingress ведет в service, внешний DNS попадает в ingress controller.

  • Проверяю pod readiness и service endpoints.
  • Тестирую service внутри кластера.
  • Смотрю ingress rules и annotations.
  • Исправляю path, class, TLS или ports.
  • Проверяю доступ снаружи и логи controller.

Что будет после исправления

  • Сервис открывается через ingress.
  • Маршрут становится понятным и документированным.
  • Ошибки видны в kubectl и логах.
  • Конфигурацию проще переносить между окружениями.

Что подготовить

  • YAML deployment/service/ingress.
  • Namespace приложения.
  • Домен или path.
  • Логи ingress controller.

Вопросы и ответы

Можно ли решить точечно?

Да. Часто достаточно поправить selector, port или ingressClass без изменения приложения.

Почему не стоит откладывать?

Пока ingress не работает, внешний пользователь не видит сервис, а команда может ошибочно чинить само приложение вместо маршрутизации.

Нужна похожая задача?

Опишите проблему и пришлите ссылку, скрин или лог. Я разберу причину, предложу понятный план исправления и не буду обещать результат без первичного просмотра.