NGINX Ingress retired: как мигрировать на Gateway API без падения прода

31 марта 2026 года NGINX Ingress официально перешёл в статус retired: best-effort поддержка комьюнити-контроллера kubernetes/ingress-nginx на этом закончилась. Патчей больше нет и не будет, уязвимости не закрываются. На NGINX Ingress при этом держится примерно половина публичных облачных Kubernetes-сред в мире - то есть речь не о редком легаси, а о самом распространённом способе публикации трафика. Разберём, как мигрировать на Gateway API в managed Kubernetes без простоя, уже после официального окончания поддержки.

NGINX Ingress retired - это официальный статус, утверждённый комитетом по безопасности Kubernetes и группой SIG Network. Поддержка завершилась 31 марта 2026, после чего не выходит ни новых патчей, ни закрытий CVE. Уже работающие кластеры не отключат принудительно, но уязвимости в них никто не исправит.

Ключевых причин упадка две. Первая - annotation hell. Вся логика маршрутизации, редиректы, таймауты, настройки TLS уходят в вендор-специфичные аннотации. Конфиг превращается в нечитаемую простыню, а переезд между разными ingress-контроллерами становится болезненным: аннотации не переносятся между реализациями.

Вторая причина - blast radius. Ошибка в одном Ingress-объекте может сломать конфигурацию всего контроллера. При невалидном reload NGINX не применяет новую конфигурацию и остаётся на последней успешной версии. Это защищает трафик, но создаёт ложное ощущение, что изменения применились. Пока команда не увидит рассинхрон, продакшн живёт со старым конфигом.

Gateway API - это расширяемый набор CRD в Kubernetes, который разделяет ответственность за сетевой слой между платформенной командой и командами приложений. В отличие от Ingress, где все настройки сосредоточены в одном объекте, Gateway API вводит три ролевые сущности: GatewayClass, Gateway и Routes.

GatewayClass описывает, какой контроллер обслуживает трафик. Это зона ответственности платформенной команды. GatewayClass определяет, что именно обрабатывает запросы: NGINX, Envoy, Traefik или другой контроллер, поддерживающий Gateway API.

Gateway - точка входа в кластер: листенеры, порты, протоколы, TLS-политики. Gateway управляет инфраструктурным контуром, но не определяет конкретные маршруты.

Routes - это HTTPRoute, GRPCRoute, TCPRoute и другие ресурсы. Они описывают, куда направлять трафик: матчинг по хостам, путям, заголовкам, веса для канареечных релизов. Это зона ответственности команды приложения.

Актуальная версия Gateway API на момент разбора - 1.5.1. Расширяемость реализована через CRD, а не аннотации. Новые возможности добавляются контроллером через собственные ресурсы, а не через строковые магические ключи в одном YAML.

Маршруты подхватываются через ParentRefs. В ресурсе Route указывается ссылка на родительский Gateway: имя, namespace, порт. Контроллер Gateway API сам находит все Route, которые ссылаются на его Gateway, и строит итоговую конфигурацию.

На уровне Gateway можно ограничивать, какие маршруты подхватываются. Это решает проблему мультитенантности. Два типичных фильтра:

Такой подход снижает blast radius: ошибка в одном HTTPRoute не валит весь контроллер, а отсекается на уровне конкретного маршрута. Плюс команды приложений могут менять свои Routes, не запрашивая прав на изменение общих Ingress-объектов.

Managed Kubernetes добавляет свои требования к Ingress-контроллерам. Провайдеру нужно изолировать клиентские конфигурации, управлять TLS-сертификатами, автоматизировать балансировку. Gateway API для этого подходит лучше, чем Ingress: CRD-модель позволяет платформенной команде контролировать уровень Gateway, не влезая в маршруты приложений.

Так в managed Kubernetes MWS используются два параллельных контура: Gateway представляет инфраструктурную зону с листенерами и TLS, а Routes описывают прикладную логику. Это упрощает обновление TLS-сертификатов: они привязываются к Gateway, а не размазываются по десяткам Ingress-объектов. Для выдачи сертификатов в связке с Gateway API логично использовать MWS Certificate Manager - это управляемый сервис для выпуска и продления сертификатов.

Основной инструмент миграции - утилита ingress2gateway. Она принимает на вход существующие Ingress-ресурсы и генерирует связку Gateway + HTTPRoute. Утилита не творит магию: часть аннотаций переносится, часть теряется.

Практический сценарий миграции в managed Kubernetes выглядит так:

Держать старый и новый контроллеры в одном кластере параллельно - нормальная практика. Это позволяет мигрировать посервисно: сначала некритичные сервисы, потом боевые. Риск простоя при этом минимален.

ingress2gateway не переносит всё. Это не двусторонний конвертер, а генератор структуры Gateway API из Ingress-ресурсов. Часть аннотаций переносится автоматически, часть - нет.

Ключевой пример из практики: аннотация SSL Redirect переезжает в Gateway API без ручной работы. А лимиты RPS (rate limiting), заданные через аннотации, прямого аналога в стандартном HTTPRoute не имеют - их приходится переносить отдельно, через специфичные для контроллера ресурсы.

Поэтому после автоматической конвертации обязателен этап ручной ревизии. Утилита ускоряет старт, но не отменяет понимание итоговой конфигурации.

Ключевой приём - параллельная работа двух контроллеров. NGINX Ingress продолжает обслуживать трафик, пока Gateway API разворачивается и тестируется. Переключение происходит на уровне DNS.

Надёжная последовательность:

Откат при параллельной работе примитивен: DNS возвращается на старый IP Ingress-контроллера. Поэтому важно не удалять старый контроллер сразу после миграции.

Кластеры на NGINX Ingress не отключат принудительно - контроллер продолжит обслуживать трафик, пока вы его не уберёте. Проблема не в остановке, а в накоплении долга: чем дольше кластер живёт на retired-контроллере, тем больше уязвимостей копится без исправлений и тем сложнее проходить аудит безопасности. Каждая новая CVE в NGINX и его модулях остаётся незакрытой.

Перенос конфигурации на Gateway API - это не только уход от устаревшего проекта, но и смена модели управления трафиком: меньше аннотаций, больше структуры, предсказуемый blast radius. И чем раньше начать, тем спокойнее проходит сам переход - параллельный запуск двух контроллеров и посервисное переключение безопасны ровно настолько, насколько есть время проверить каждый сервис.

Финальный список для перехода с NGINX Ingress на Gateway API:

Миграция с NGINX Ingress на Gateway API - не разовая операция, а процесс. Но при параллельной работе двух контроллеров его можно провести без единого прод-инцидента.