После прекращения поддержки ingress-nginx: проверка параллельной миграции на Gateway API

Что это

По состоянию на 25 октября 2026 года: в уведомлении сообщества Kubernetes о завершении проекта Ingress NGINX март 2026 года указан как конец сопровождения по мере возможностей; после этого новые выпуски, исправления ошибок и обновления безопасности не предусмотрены. Существующие развёртывания и установочные артефакты остаются работоспособными. Перед планированием изменений заново проверьте уведомление и документацию о поддержке и соответствии спецификации выбранного контроллера на замену. Речь о проекте сообщества ingress-nginx; определите фактический контроллер, а не относите всё с названием NGINX к одной категории. Уведомление о завершении проекта.

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

Доступный образ или работающая конечная точка не свидетельствуют о продолжающемся сопровождении. Gateway API меняет модель конфигурации: Gateway описывает точки входа, а HTTPRoute — маршрутизацию приложения. Аннотации, специфичные для контроллера, требуют явного сопоставления. Общее руководство по миграции объясняет преобразование, но прямо указывает, что не содержит полной процедуры миграции работающей системы. Модель миграции.

Приведённая ниже поэтапная процедура — предлагаемый эксплуатационный план. Её критерии приёмки должны охватывать существующие требования приложения к маршрутизации и безопасности.

Как применять

• Проведите инвентаризацию контроллеров во всех кластерах, к которым у вас есть разрешённый доступ. Уведомление о завершении проекта предлагает kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx. Проверьте также развёртывания и образы контроллеров: один лишь запрос по метке не позволяет исключить переименованные или изменённые установки. Зафиксируйте ресурсы Ingress, классы, аннотации, ссылки TLS и конфигурацию контроллера.

• Выберите сопровождаемую реализацию Gateway API, чьё соответствие спецификации и поддержка расширений обеспечивают необходимые возможности. Назначьте ответственных за точки входа и маршруты. Официальное вводное руководство допускает запуск нового контроллера параллельно с ingress-nginx на другом внешнем IP, поэтому до изменения публичного трафика подготовьте отдельную конечную точку для проверки. Рекомендации по параллельной миграции.

• Используя проверенную установку ingress2gateway, создайте черновик из экспортированных манифестов. В официальном объявлении версии 1.0 документирована такая форма:

  ingress2gateway print --input-file ingress.yaml --providers=ingress-nginx > gateway-draft.yaml
  

  Перед любым применением изучите сгенерированные ресурсы и все предупреждения. Выберите фактический GatewayClass для замены и проверьте имена, пространства имён и ссылки на бэкенды. Рекомендации по преобразованию.

• Явно определите решение для каждой неподдерживаемой возможности. В этом объявлении отмечены непреобразованные фрагменты конфигурации, приблизительное преобразование тайм-аутов, ограничения размера тела без стандартного эквивалента в приведённом примере и различия нормализации URL. Заново проверьте эти сопоставления относительно текущего API и выбранной реализации; не превращайте прежнее ограничение конвертера в постоянное утверждение о спецификации.

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

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

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

Не предполагайте, что сгенерированный YAML сохраняет контроль доступа или что собственные расширения переносимы между контроллерами. Параллельное развёртывание также требует чёткой ответственности за DNS и автоматизацию сертификатов. Не оставляйте снятый с сопровождения контроллер доступным извне на неопределённый срок в качестве недокументированного резерва. Успешное преобразование, готовность контроллера и корректное поведение приложения — отдельные проверки.