Ingress NGINX умер, да здравствует Gateway API

Разбираем причины отказа от NGINX Ingress Controller, преимущества Gateway API и практический план перехода.

Мир Kubernetes стоит на пороге заметной архитектурной трансформации. Ingress долго воспринимался как стандартная точка входа для HTTP-трафика, но сегодня экосистема всё активнее смещается в сторону Gateway API. Катализатором этого перехода стало прекращение поддержки классического NGINX Ingress Controller: стало очевидно, что старая модель упёрлась в собственные ограничения.

Это не повод для паники, а хороший момент пересмотреть сетевую архитектуру. Ниже разберём, почему Ingress перестал устраивать индустрию, чем Gateway API лучше и как подходить к миграции без лишнего риска.

Введение: почему Kubernetes заговорил о переменах #

Ingress долго казался удобной и достаточно универсальной абстракцией: host, path, backend, TLS и минимум сущностей. В 2020 году ресурс получил статус Generally Available (v1), но дальше его развитие практически остановилось. Простота, которая раньше была преимуществом, со временем превратилась в архитектурное ограничение.

Когда появились новости о прекращении обновлений безопасности для классического NGINX Ingress Controller, стало понятно, что разговор о замене больше не теоретический. Для многих команд это стало сигналом: старую схему пора не латать, а переосмысливать.

Как мы жили с Ingress и что пошло не так #

У Ingress было несколько системных проблем, которые годами компенсировались обходными путями.

• «Мешок аннотаций». Базовых полей Ingress не хватало, поэтому вендоры вынесли значительную часть конфигурации в аннотации вроде nginx.ingress.kubernetes.io/.... В результате манифесты становились длинными, плохо читаемыми и зависимыми от конкретной реализации.
• Монолитность. В одной сущности смешивались инфраструктурные настройки и прикладная логика маршрутизации. Это мешало нормальному разделению ответственности между платформенной командой и разработчиками.
• Проблемы безопасности. Для гибкости приходилось использовать сниппеты и расширения, в том числе Lua. Именно такие механизмы нередко становились источником критических уязвимостей и усложняли сопровождение контроллера.

Итог простой: Ingress оказался слишком тесной моделью для современных требований к сетям, безопасности и командной работе.

Анатомия Gateway API: разделяй и властвуй #

Gateway API построен на декомпозиции и явном разделении ролей. Вместо одной перегруженной сущности появляются отдельные объекты с понятной зоной ответственности.

• GatewayClass определяет тип реализации балансировщика и соответствует инфраструктурному уровню.
• Gateway описывает конкретную точку входа: IP-адреса, порты, листенеры, политики доступа.
• HTTPRoute отвечает за прикладную маршрутизацию и может управляться отдельно от инфраструктурной части.

Такой подход помогает развести обязанности между командами. Например, сертификат wildcard можно держать в защищённом инфраструктурном namespace и использовать его на уровне Gateway, не копируя секрет в каждый прикладной namespace.

Дополнительный плюс Gateway API в том, что это открытая спецификация с conformance-тестами. Архитектура строится не вокруг конкретного контроллера, а вокруг стандарта, который поддерживают разные реализации, включая Cilium, Istio и Envoy-based решения.

Куда мигрировать сегодня #

Выбор конкретной реализации Gateway API зависит от инфраструктуры, требований по производительности и уже используемого сетевого стека.

• Cilium хорошо подходит тем, кто делает ставку на eBPF и хочет получить максимально нативную интеграцию с Linux-сетью.
• Envoy-based решения вроде Istio, Traefik или Gloo интересны там, где важны гибкая маршрутизация и развитая экосистема сервисной сетки.
• F5 NGINX Plus может быть промежуточным вариантом для тех, кто хочет остаться в знакомой экосистеме NGINX, но перейти на поддерживаемый коммерческий продукт.

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

Практика миграции: инструменты и подводные камни #

Миграция не должна быть прыжком в бездну. Сообщество предлагает утилиту ingress2gateway, которая помогает автоматически преобразовать существующие манифесты, но полностью полагаться на неё не стоит.

Основные риски при переходе:

• Проблемы с namespace. Автоматическая конвертация может пытаться создавать Gateway прямо в прикладном namespace, хотя архитектурно такой ресурс чаще уместнее на инфраструктурном уровне.
• Непереносимые аннотации. Значительная часть специфичных настроек NGINX Ingress не имеет прямого эквивалента и требует ручного пересмотра через Filters и другие механизмы HTTPRoute.
• Ошибки совместимости. Перед применением манифестов полезно проверять их через kubectl apply --server-side --dry-run=server, чтобы заранее получить ответ от вебхуков контроллера и не ломать рабочую среду.

Хорошая стратегия миграции — запускать Gateway API параллельно с действующим Ingress на другом IP-адресе или порту. Это позволяет переводить сервисы по одному, тестировать поведение и снижать риск массового сбоя.

Взгляд вперёд со «Штурвалом» #

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

В платформе «Штурвал» начиная с релиза 2.14, в интерфейсе доступно управление объектами Gateway API — см. Gateway API.

Путь миграции всё ещё требует ручной проверки манифестов и архитектурной дисциплины, но итог обычно оправдывает усилия: сеть становится чище, понятнее и безопаснее.