01
Добавить связанные ресурсы
Разделите Ingress и Service строкой ---; при необходимости добавьте Deployment или Pod. Service с тем же именем в другом namespace не подходит.
Kubernetes / Helm
проверка маршрутов Ingress
Вставьте готовый YAML и задайте Host и путь одного запроса для статической проверки.
проверка маршрутов Ingress
Отчёт о маршруте
Вставьте манифесты или загрузите пример.
Локальный анализ в браузере, без кластера и HTTP-запросов.
Параметры запроса
Exact и Prefix по правилам Kubernetes; особенности контроллера не моделируются.
Пределы: 300 000 символов, 100 ресурсов, 500 путей.
Вставьте манифесты или загрузите пример.
Правило Ingress может подходить запросу, но указывать на порт, которого нет в Service. Проверка маршрутов Ingress показывает, на каком звене эта цепочка прерывается.
Отчёт строится только по вставленным объектам. Он не обращается к кластеру и не посылает HTTP-запрос, поэтому неизвестное состояние не выдаётся за доказанный сбой.
Зачем нужна проверка маршрутов Ingress?
Проследить один запрос до целевого порта
Проверка маршрутов Ingress выбирает самый длинный подходящий путь, а при равной длине отдаёт приоритет Exact. Затем она показывает переход от порта Service к targetPort.
Отделить обрыв ссылки от недостатка данных
Если указанный порт Service отсутствует, отчёт укажет место обрыва. Если Pod не был вставлен, состояние останется неизвестным, без ложного вывода о недоступности.
Три проверки перед изменением YAML
02
Задать конкретный запрос
Исходный путь — /. Для проверки /api/orders укажите и HTTP Host, если правило его требует. Пустой Host проверяет лишь правила без имени хоста.
03
Прочитать уровень достоверности
Совпадение означает только статический выбор правила. Обрыв — отсутствующая ссылка, неопределённость — зависимость от контроллера. После правки запустите анализ заново.
От правила до порта Service
Сравнение Host и пути
Проверка маршрутов Ingress поддерживает Exact, Prefix по сегментам, точный Host и маску одного поддомена. Путь /api не совпадёт с /apix. Маршрутизация Kubernetes Ingress здесь оценивается лишь по стандартным правилам; ошибка 404 Ingress требует проверки кластера.
Разные роли port и targetPort
Backend Ingress ссылается на номер или имя порта Service. Service затем отображает его в targetPort; если поле не задано, используется тот же port.
Необязательная связь с Pod
Если вставлены Pod или шаблон Deployment, selector Service сопоставляется с labels. Без этих ресурсов наличие рабочего EndpointSlice не предполагается.
Границы статического вывода
- Поведение контроллера остаётся открытым
- ImplementationSpecific, regex и rewrite-аннотации зависят от контроллера. Проверка маршрутов Ingress отмечает их как неопределённые, а не подменяет правилом Prefix.
- Сеть не проверяется
- Для ошибки 404 Ingress могут понадобиться логи контроллера, DNS, EndpointSlices и реальный запрос. Совпавший YAML не доказывает доступность приложения.
- Отсутствие Pod в тексте не равно обрыву
- В кластере могут быть не вставленные Pod или ручные endpoints. Доказанным обрывом здесь считается только отсутствие указанного Service или порта среди предоставленных объектов.
- Ограниченный объём
- Не более 300 000 символов, 100 ресурсов и 500 путей. Поддерживаются готовые Ingress v1 и Service v1; шаблоны Helm и Gateway API не интерпретируются.
Проверка маршрутов Ingress: частые вопросы
Почему Ingress возвращает 404 для заданного пути?
Причиной 404 бывает несовпадение Host или пути, defaultBackend, rewrite либо само приложение. Отчёт показывает статический маршрут; для фактического ответа нужны логи и запрос к кластеру.
В backend Ingress указывать порт Service или targetPort?
Backend Ingress указывает номер или имя порта Service. Лишь затем Service направляет трафик на targetPort. Порт Pod не обязан совпадать с портом backend.
Совпадает ли Prefix /foo с /foobar?
Нет. Prefix /foo совпадает с /foo и /foo/bar, но не с /foobar. Регистр символов также имеет значение.
Какое правило выбирается при совпадении Exact и Prefix?
Выбирается самый длинный совпадающий путь. При равной длине Exact важнее Prefix; равнозначные правила разных Ingress помечаются как конфликт.
Можно ли по YAML подтвердить доступность Pod?
Нет. По YAML нельзя подтвердить готовность Pod, состояние EndpointSlice, DNS, балансировщика и сети.
Остались вопросы о маршруте?
Запустить проверку маршрутов Ingress
Измените Host и путь примера, чтобы увидеть выбор порта Service.
Данные обрабатываются в браузере.