Диагностика Ingress

Цель при инциденте — восстановить публичный сервис, не уничтожив состояние, которое помогает объяснить сбой. Ingress пересекает несколько зон ответственности: DNS, сеть, сертификат, конфигурацию nginx, политику Route, приватный транспорт и среду выполнения приложения. Одновременное изменение нескольких уровней обычно продлевает недоступность.

Назначьте одного владельца инцидента, зафиксируйте последнее заведомо исправное изменение и проверяйте путь снаружи внутрь. Восстановление завершено, когда внешний сервис снова работает, желаемое и сообщённое состояния Opfield совпадают, а неисправный уровень и безопасное действие по восстановлению зафиксированы достаточно точно, чтобы предотвратить повторение.

Проверяйте уровни в следующем порядке, чтобы не изменить исправную часть системы:

DNS: разрешите имя хоста с внешнего клиента и убедитесь, что оно указывает на назначенную ноду Ingress.
Сеть: проверьте доступность публичных портов 80/443 и правила межсетевого экрана хоста.
TLS: проверьте имя хоста в сертификате, цепочку, срок действия и состояние распространения.
Конфигурация nginx: убедитесь, что последняя ревизия применена и успешно прошла валидацию.
Состояние Route: проверьте ожидаемые код и тело ответа, а также режим обслуживания.
Целевая служба: проверьте приложение с ноды nginx или откройте состояние Secure Link.
Журналы: сопоставьте записи доступа и ошибок nginx с журналами рабочей нагрузки и идентификаторами запросов.

Частые причины: Domain и Route размещены на разных нодах, после миграции во внешнем DNS остались старые записи, HTTP-01 выбран на ноде без публичного порта 80, для приложения WebSocket не включена передача WebSocket или выбран порт рабочей нагрузки, который фактически не опубликован и не подключён.

Таблица симптомов

Симптом	Наиболее вероятный уровень	Первая проверка
Имя хоста не разрешается	DNS	Внешний запрос `A`/`AAAA` и размещение Domain
Тайм-аут соединения	сеть	Публичный адрес, межсетевой экран, порты 80/443, доступность ноды
Предупреждение о сертификате	TLS	Имя хоста в сертификате, цепочка, срок действия и назначенный Route
Рукопожатие TLS сразу завершается ошибкой	сопоставление Route	Ни один включённый Route на этой ноде не обслуживает имя; нода отклоняет такие рукопожатия, а не отвечает сайтом другого Route
Немедленный `404`	сопоставление Route	Имя хоста, префикс пути, состояние включения, необработанная конфигурация
Управляемый `503`	обслуживание или неисправная целевая служба	Режим обслуживания и история состояния
`502`/`504`	транспорт к целевой службе	Secure Link, целевой порт, состояние рабочей нагрузки, настройки тайм-аутов
WebSocket отключается	передача протокола	Настройка WebSocket, путь приложения, тайм-ауты прокси и чтения
Изменения не появляются	применение или согласование	Состояние Task, ревизия nginx, соединение ноды, ошибка валидации; отклонённое изменение завершается ошибкой `422 NGINX_CONFIG_FAILED` и сообщает вывод `nginx -t`
`502` от Route к Docker в Raw Config Mode	исходная конфигурация	Исходная конфигурация должна по-прежнему проксировать на `upstream` Secure Link этого Route; см. Ресурсы Route
`502` от Deployment	маршрутизатор Deployment	Заголовок `X-Gateway-Deployment-Router: upstream-unavailable` означает, что маршрутизатор не смог достучаться до активного слота

Соберите свидетельства до изменения состояния

Зафиксируйте неисправное имя хоста, путь, время, класс IP-адреса клиента, ожидаемый и фактический ответы, назначенную ноду, идентификатор Route, идентификатор последней Task и связанный идентификатор запроса. До повторной попытки сохраните ошибку валидации созданной конфигурации и ограниченный фрагмент журналов: последующие изменения могут стереть самые полезные свидетельства.

Сравните три представления:

желаемое состояние Opfield на страницах Route и Domain;
последнее подтверждённое состояние от ноды nginx;
наблюдаемое снаружи поведение DNS, TLS и HTTP.

Расхождение между ними показывает ответственный уровень: состояние контура управления, применение на ноде или внешняя инфраструктура.

Сбои Secure Links записываются в журнал один раз на ссылку, а не на каждый запрос. nginx-демон на ноде Ingress пишет предупреждение proxy secure-link connections failing с link_id, последним Relay, этапом и ошибкой, когда ссылка начинает отказывать, still failing с числом отказов каждые 5 минут, информационную запись, когда запросы проходят только после повторов, и recovered с числом отказавших и повторённых запросов при первом чистом соединении. Docker-демон цели так же записывает сбои входящих туннелей по владельцу адреса подключения (relay endpoint tunnels), а отказы на отозванных маршрутах — отдельно (relay endpoint tunnels on revoked routes). Подробности каждой попытки доступны на уровне отладки.

Безопасное восстановление

Исправляйте DNS только после подтверждения нужного размещения ноды.
Исправляйте назначение сертификата, не отключая TLS глобально.
Сначала устраните ошибку валидации конфигурации и только затем запускайте новое применение.
Используйте режим обслуживания, если приложение должно оставаться недоступным во время ремонта.
Повторяйте согласование только после восстановления зависимости, вызвавшей сбой.
Откатывайте приложение или конфигурацию Route, если доступна заведомо исправная ревизия.

Не удаляйте и не создавайте заново Domain, сертификат или Route первым действием. Это уничтожает историю связей и может вызвать второй сбой.

Проверка восстановления

Выполните запрос с внешнего клиента, затем проверьте каноническое имя хоста, цепочку сертификата, код и тело ответа, перенаправления, WebSockets, историю состояния и журналы nginx. Закрывайте инцидент только после того, как публичное поведение и состояние Opfield совпали.

Откат по неисправному уровню

Откат должен отменять минимальное изменение, которое вызвало недоступность. Для DNS восстановите записанные адреса с учётом кэшей DNS-серверов. Для TLS верните прежнее корректное назначение сертификата, не отключая HTTPS. Для конфигурации nginx верните последние заведомо исправные управляемые настройки и дождитесь подтверждения. При регрессии приложения откатывайте владеющий Deployment или ревизию Compose, а не перестраивайте Route вокруг неработающего релиза.

Сбой Secure Link требует восстановить Relay, соединение нод или целевую среду выполнения; изменения DNS и сертификата его не исправят. При ошибке политики доступа верните прежний Access List или настройку доверенного прокси, а не открывайте порт рабочей нагрузки. На время ремонта используйте режим обслуживания: он сохраняет явное имя хоста и путь TLS, но не допускает случайный трафик к частично восстановленному приложению.

Данные для эскалации

Если первая попытка восстановления не объяснила причину, до эскалации соберите ограниченный пакет данных:

идентификаторы Domain и Route, назначенную ноду Ingress и последнюю подтверждённую ревизию конфигурации;
внешние ответы DNS и сведения о TLS-сертификате, наблюдавшиеся во время инцидента;
историю состояния Route и точные путь (path), метод (method), статус (status) и время (timestamp) сбоя;
связанные записи доступа и ошибок nginx, а также операцию владеющей рабочей нагрузки или Secure Link;
версии нод и Relay, состояние соединения и последнее сообщение неуспешной Task;
последние заведомо исправные ревизии приложения, Route и DNS.

Удалите учётные данные, файлы cookie, заголовки авторизации, закрытые ключи и чувствительные параметры запроса. Задача пакета — сохранить причинно-следственную связь, не превращая запись инцидента в хранилище секретов.