Миграция с Ingress NGINX становится обязательной: EOL и уязвимости делают переход на Kubernetes Gateway API вопросом устойчивости и безопасности.
Проблема проявляется не сразу — до момента, когда контроль над входящим трафиком становится точкой системного риска. Ingress NGINX долгое время был стандартом де-факто для Kubernetes, но его жизненный цикл завершён. Это означает отсутствие будущих патчей безопасности. На этом фоне уязвимости уровня IngressNightmare и новые CVE показывают важную деталь: ingress-контроллер — это не изолированный компонент, а точка с кластерным радиусом поражения. При этом сам Kubernetes Ingress API остаётся, но фактически заморожен по функциональности. Система продолжает работать, но перестаёт эволюционировать.
Решение в этой ситуации — переход на Kubernetes Gateway API. Это не конкретный контроллер, а спецификация с набором ресурсов. Такой подход убирает зависимость от аннотаций, которые раньше были привязаны к Ingress NGINX. Вместо этого маршрутизация описывается декларативно через стандартные ресурсы. Это снижает vendor lock-in и делает конфигурации переносимыми между реализациями. Компромисс здесь очевиден: поведение и уровень соответствия (conformance) могут отличаться между контроллерами. Также важно учитывать поддержку протоколов. HTTP покрывается везде, но TCP и UDP — не гарантированы.
Ключевой архитектурный шаг — выбор контроллера. Он определяет поведение data plane и доступные возможности. Например, для LLM-нагрузок важна поддержка расширений, таких как inference routing, которые зависят от конкретных реализаций (например, через ext_proc). Далее начинается сама миграция. Она строится как параллельный процесс, а не “переключение рубильника”. Сначала фиксируется baseline: request rate, latency, error rate. Эти метрики нужны не для отчёта, а как контрольная точка, чтобы понять, ломается ли поведение системы.
Имплементация начинается с установки Gateway API CRDs и выбранного контроллера. Базовые сущности — GatewayClass, Gateway, Route и ReferenceGrant. В отличие от Ingress, где многие вещи “работали по умолчанию”, здесь связи становятся явными. Например, кросс-namespace доступ теперь требует ReferenceGrant. Это повышает безопасность, но добавляет операционную сложность. Ошибка в этих связях проявляется сразу — Route не будет принят (Accepted: False или ResolvedRefs: False).
Для ускорения миграции используется инструмент Ingress2Gateway. Он переводит существующие манифесты и даже часть аннотаций в новый формат. Но это только стартовая точка. Ручная проверка обязательна, потому что не все конструкции имеют прямое соответствие. После генерации конфигурации создаются Gateway и Route ресурсы, которые повторяют текущую логику: хосты, пути, TLS, backend-сервисы.
Критический момент — валидация без продакшен-трафика. Используются shadow или synthetic запросы. Сравниваются ответы через старый и новый entrypoint. Проверяются статус-коды, заголовки, TLS-поведение и фактическая доставка запроса в backend. Это позволяет поймать расхождения до DNS cutover. Если у Gateway есть внешний адрес, тестирование можно проводить напрямую, подставляя production hostname.
Переключение трафика происходит через DNS. Это не мгновенный процесс. Даже при низком TTL часть клиентов продолжает использовать старые записи. В этот период система фактически работает в режиме split traffic. Это создаёт дополнительную нагрузку на observability. Нужно отслеживать отклонения от baseline: рост latency, всплески 4xx/5xx, проблемы с TLS. Важно, что rollback остаётся простым — достаточно вернуть DNS.
Наблюдаемость (observability) становится центральным элементом миграции. Метрики Ingress NGINX сравниваются с метриками Gateway API в едином дашборде. Многие контроллеры отдают данные в формате Prometheus, что упрощает интеграцию. Дополнительно используется трассировка (APM), чтобы понять, где возникает деградация — на edge или внутри сервисов. Такой подход превращает миграцию из рискованного события в контролируемый процесс.
Результат — более строгая и предсказуемая модель маршрутизации. Gateway API делает поведение системы явным и переносимым. Но цена — рост сложности и необходимость лучше понимать связи между ресурсами. Метрики улучшений в исходных данных не приводятся, поэтому эффект оценивается через стабильность, безопасность и управляемость архитектуры.