Kubernetes Ingress и Gateway API после Ingress-NGINX

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

Gateway API в этой ситуации интересен не как «новый синтаксис Ingress», а как другая модель управления сетью. Он разделяет инфраструктуру, точки приёма трафика и прикладные маршруты между несколькими ресурсами и ролями. Для платформенной команды это означает пересмотр RBAC, границ ответственности, способа публикации сервисов и требований к переносимости конфигурации.

Ниже сравниваются модели API и подходы к эксплуатации в Kubernetes-кластерах на VDS. Производительность, потребление памяти, задержки и пропускная способность конкретных ingress- и gateway-контроллеров не рассматриваются: эти показатели зависят от реализации, конфигурации и топологии кластера, а не только от выбранного Kubernetes API.

Что именно прекратилось в 2026 году

Важно разделять три сущности:

• Ingress — стабильный ресурс Kubernetes из группы networking.k8s.io.
• Ingress controller — компонент, который наблюдает за ресурсами Ingress и настраивает реальный прокси, балансировщик или другой data plane.
• Ingress-NGINX — конкретная реализация контроллера, которую развивало сообщество Kubernetes.

API Ingress остаётся доступным, но сам API заморожен: в него не добавляют новые возможности. Новые сценарии маршрутизации предполагается описывать через Gateway API. Поэтому завершение развития Ingress-NGINX не требует немедленно удалять все объекты Ingress, но создаёт повод проверить, кто отвечает за исправления контроллера, его совместимость с будущими версиями Kubernetes и обнаруживаемые уязвимости.

Возможны разные целевые варианты: другой ingress-контроллер, контроллер с одновременной поддержкой Ingress и Gateway API либо полный переход на Gateway API. Сам факт завершения Ingress-NGINX не делает один продукт автоматическим выбором для всех кластеров.

Главное различие: один прикладной объект и набор связанных ресурсов

Модель Ingress

Ingress объединяет в одном namespaced-объекте основные правила HTTP- и HTTPS-маршрутизации: домены, пути, TLS-секреты и ссылки на Service. Реализация выбирается через IngressClass или имя класса в самом Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  namespace: shop
spec:
  ingressClassName: public
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend
            port:
              number: 8080

Базовая схема компактна, но ограничения модели проявляются за пределами простых маршрутов. Перенаправления, переписывание URL, регулярные выражения, CORS, ограничения тела запроса, тайм-ауты и другие функции часто задаются аннотациями конкретного контроллера. Глобальные параметры могут находиться в ConfigMap контроллера, дополнительные возможности — в его CRD, а произвольные фрагменты конфигурации — в специальных snippet-аннотациях.

В результате компактный Ingress не всегда содержит полное описание своего поведения. Оно может зависеть от ресурсов в другом namespace, значений Helm chart, аргументов запуска контроллера и общекластерной ConfigMap. Например, проверка лимитов запросов требует учитывать не только манифест, но и настройки контроллера; подробнее об этом — в статье о лимитах тела HTTP-запроса в Nginx.

Модель Gateway API

Gateway API разделяет конфигурацию как минимум на три уровня:

• GatewayClass выбирает реализацию и описывает класс шлюзов. Это cluster-scoped-ресурс, которым обычно управляет платформенная команда.
• Gateway описывает экземпляр точки приёма трафика: listeners, порты, протоколы, TLS и правила подключения маршрутов.
• HTTPRoute задаёт прикладную HTTP-маршрутизацию к Service и другим разрешённым backend-объектам.

Эти ресурсы отражают организационные роли: поставщик или владелец инфраструктуры отвечает за реализацию, оператор кластера — за шлюзы и политики доступа, команда приложения — за маршруты своего сервиса. Gateway API определён через CRD и требует совместимого контроллера: установка схем API сама по себе не создаёт работающий сетевой тракт.

Упрощённая конфигурация для того же приложения состоит из Gateway и HTTPRoute:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public
  namespace: gateways
spec:
  gatewayClassName: public
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - name: wildcard-example-com
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            access.example.com/public-gateway: "true"
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop
spec:
  parentRefs:
  - name: public
    namespace: gateways
  hostnames:
  - shop.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: frontend
      port: 8080

В этой схеме команда приложения не редактирует listener, сертификат или инфраструктурные параметры. Она создаёт маршрут, запрашивающий подключение к общему Gateway. Оператор шлюза со своей стороны определяет, маршруты из каких namespace могут к нему присоединяться.

HTTPRoute — не просто Ingress с другим kind

Механическая замена kind: Ingress на kind: HTTPRoute невозможна. В Ingress точка входа выбирается преимущественно через класс, а в HTTPRoute связь явно задаётся полем parentRefs. Один маршрут может быть связан с конкретным Gateway и listener, а разрешение такой связи подтверждается обеими сторонами.

HTTPRoute структурирует то, что в Ingress часто выражалось аннотациями. Его правила могут содержать:

• сопоставление по hostname, пути, HTTP-заголовкам и параметрам запроса;
• несколько backendRefs и распределение трафика по весам;
• фильтры перенаправления и изменения URL;
• изменение заголовков запроса или ответа;
• другие стандартные и расширенные возможности, если их поддерживает выбранная реализация.

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

Однако наличие поля в установленной версии Gateway API ещё не гарантирует его поддержку конкретным контроллером. Платформенной команде нужно проверять заявленный уровень соответствия реализации, поддерживаемые функции и условия в status. Состояние маршрута важнее успешного выполнения kubectl apply: объект может сохраниться в API, но не присоединиться к Gateway или не разрешить ссылку на backend.

Как меняются RBAC и распределение ответственности

В модели Ingress команда приложения нередко получает право создавать Ingress в своём namespace. При этом объект может влиять на общий внешний контроллер, занимать hostname и активировать чувствительные возможности через аннотации. Реальные границы доступа тогда зависят не только от RBAC, но и от admission-политик и поведения контроллера.

Gateway API рассчитан на более явное разделение ролей. Типовая схема выглядит так:

• администраторы контроллера управляют GatewayClass и его параметрами;
• платформенная команда создаёт Gateway в выделенном namespace и управляет listeners, TLS и допустимыми источниками маршрутов;
• команды приложений получают CRUD-доступ только к HTTPRoute в собственных namespace;
• владельцы backend-ресурсов отдельно разрешают ссылки из других namespace.

RBAC определяет, кто может создавать и изменять объекты, но не заменяет правила их связывания. Чтобы HTTPRoute из другого namespace подключился к Gateway, маршрут должен указать его в parentRefs, а listener Gateway — разрешить такой источник через allowedRoutes. Это двусторонняя модель согласия, а не автоматическое доверие всем маршрутам кластера.

Для ссылки HTTPRoute на Service в другом namespace применяется ещё один защитный механизм — ReferenceGrant в namespace целевого объекта. Разрешение создаёт владелец backend, поэтому команда маршрута не может самостоятельно направить трафик на произвольный Service соседней команды.

Такое разделение полезно для multi-tenant-кластеров, но увеличивает число объектов и сценариев отказа. Маршрут может не заработать из-за RBAC, allowedRoutes, отсутствующего ReferenceGrant, несовпадения hostname с listener или неподдерживаемого фильтра. Платформе нужны понятные шаблоны, диагностика статусов и документация для разработчиков.

Аннотации, ConfigMap и CRD: куда переезжают расширения

Ingress-NGINX фактически предоставлял API, состоящий не только из стандартного Ingress. В него входили десятки аннотаций, параметры ConfigMap, аргументы контроллера и дополнительные механизмы. Поэтому два одинаковых объекта Ingress в разных кластерах могли вести себя по-разному.

Gateway API переносит распространённые функции в типизированные поля и фильтры. Это уменьшает зависимость от строковых аннотаций, но не устраняет расширения как класс. Для возможностей, не вошедших в стандартную модель, реализации могут применять:

• параметры, связанные с GatewayClass или Gateway;
• ресурсы политик, прикрепляемые к Gateway, Route, Service или другим объектам;
• implementation-specific CRD;
• расширенные или собственные фильтры;
• аннотации для инфраструктурных настроек контроллера.

Следовательно, Gateway API не означает полного отказа от vendor-specific конфигурации. Он позволяет отделить переносимую часть маршрута от особенностей реализации. Чем больше поведения находится в стандартных полях HTTPRoute, тем проще заменить контроллер. Чем сильнее поведение зависит от custom policy, параметров класса и нестандартных фильтров, тем выше новая привязка к реализации.

При миграции каждую настройку полезно отнести к одной из пяти категорий:

1. Прямой стандартный эквивалент. Например, простое сопоставление пути или перенаправление, поддерживаемое стандартным фильтром.
2. Эквивалент с другой семантикой. Поле существует, но единицы измерения, область действия или поведение по умолчанию отличаются.
3. Расширение выбранного контроллера. Перенос возможен, но снижает переносимость.
4. Архитектурная замена. Возможность реализуется отдельным сервисом, политикой безопасности или на другом сетевом уровне.
5. Непереносимое либо нежелательное поведение. Его следует удалить или переработать.

Переносимость: что Gateway API гарантирует, а что нет

Gateway API повышает переносимость прежде всего за счёт общей схемы ресурсов и формализованных возможностей. Стандартный HTTPRoute с hostname, PathPrefix и backendRef обычно понятнее разным реализациям, чем Ingress с набором аннотаций конкретного контроллера.

Но переносимость не бинарна. Она состоит из нескольких уровней:

• Переносимость API. Контроллер принимает одинаковые kinds и поля.
• Переносимость функций. Реализация действительно поддерживает использованные matches, filters и политики.
• Переносимость поведения. Совпадают приоритеты правил, обработка конфликтов, регулярных выражений, перенаправлений и тайм-аутов.
• Переносимость инфраструктуры. Не требуется менять способ выдачи IP-адреса, публикации портов, TLS и взаимодействия с внешним балансировщиком.
• Переносимость эксплуатации. Сохраняются наблюдаемость, журналы, метрики, процедура обновления и модель аварийного восстановления.

На практике полностью переносимыми стоит считать только проверенные функции общей спецификации. Имя GatewayClass, ссылки на параметры, инфраструктурные аннотации, Policy CRD и собственные фильтры почти всегда требуют адаптации при смене реализации.

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

Что меняется в Kubernetes-кластерах на VDS

Gateway API описывает желаемую маршрутизацию, но не решает автоматически задачу доставки интернет-трафика к кластеру. В среде VDS часто отсутствует встроенный облачный LoadBalancer, поэтому платформенная команда самостоятельно формирует полный путь:

публичный IP или внешний балансировщик
            ↓
порты VDS и сетевой фильтр
            ↓
Service, NodePort, host network или локальный балансировщик
            ↓
контроллер и Gateway listener
            ↓
HTTPRoute
            ↓
Service приложения

Конкретная цепочка зависит от числа узлов, доступных публичных адресов, реализации Service типа LoadBalancer и требований к отказоустойчивости. Переход с Ingress на Gateway API не создаёт новый внешний IP сам по себе и не открывает TCP-порты 80 и 443 в сетевом экране VDS. Для размещения компонентов кластера и сетевого контура может потребоваться VPS-сервер с подходящими сетевыми ресурсами.

Для VDS особенно важны следующие вопросы:

• где завершается TLS и в каком namespace хранятся сертификаты;
• какие узлы принимают входящие соединения и что происходит при отказе узла;
• как работают IPv4 и IPv6, если кластер и DNS используют оба стека;
• как сохраняется исходный IP клиента;
• кто управляет DNS при параллельной работе старой и новой точки входа;
• не конфликтуют ли два контроллера за host ports, NodePort или один внешний адрес;
• как выполняется откат без одновременного изменения DNS, маршрутов и приложений.

Если один Gateway обслуживает много namespace, он становится общей платформенной зависимостью. На небольшом наборе VDS это требует не только корректного YAML, но и резервирования data plane, контроля ресурсов, PodDisruptionBudget, распределения реплик по узлам и заранее проверенной процедуры восстановления. Эти меры относятся к эксплуатации реализации, а не к преимуществам самого API.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Почему автоматическая конвертация не завершает миграцию

20 марта 2026 года SIG Network объявила выпуск Ingress2Gateway 1.0. Инструмент преобразует Ingress и часть implementation-specific настроек в ресурсы Gateway API, сообщает о неподдерживаемых параметрах и предлагает варианты обработки. В версии 1.0 была расширена поддержка распространённых аннотаций Ingress-NGINX, но проект позиционируется как помощник миграции, а не как однокнопочная замена.

Синтаксически корректный результат ещё не гарантирует эквивалентное поведение. В материалах Kubernetes отдельно отмечены различия в обработке регулярных выражений, перенаправлений, rewrite, тайм-аутов и других настроек Ingress-NGINX. Некоторые аннотации переводятся в стандартные фильтры, некоторые получают приближённый эквивалент, а такие механизмы, как произвольные configuration snippets, могут не иметь безопасного прямого соответствия.

Опаснее всего скрытые зависимости от общих настроек. Конвертер конкретного Ingress не обязательно может определить полный эффект ConfigMap контроллера, его аргументов запуска, шаблонов, admission-компонентов или внешней автоматизации. Поэтому единицей анализа должен быть не отдельный YAML-файл, а полный контур Ingress-NGINX в кластере.

Что включить в оценку миграции

Для обзорной оценки не требуется сразу выбирать новый контроллер. Сначала полезно установить реальный объём используемого API и зависимостей.

Инвентаризация конфигурации

• Ingress и IngressClass во всех namespace;
• все аннотации, включая редко используемые и сгенерированные Helm chart;
• ConfigMap и аргументы запуска Ingress-NGINX;
• TLS Secrets, default backend и правила HTTP-to-HTTPS redirect;
• регулярные выражения, rewrite, canary и распределение трафика;
• тайм-ауты, лимиты тела, буферизация и backend TLS;
• аутентификация, allowlist, rate limiting и snippets;
• TCP- и UDP-публикации, которые не описаны обычным Ingress;
• CRD, admission-политики и автоматизация вокруг контроллера.

Проектирование новой модели владения

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

Также следует заранее решить:

• кто создаёт GatewayClass и Gateway;
• могут ли приложения подключаться только из namespace с определённой меткой;
• разрешены ли произвольные hostnames или нужен отдельный контроль доменов;
• кто создаёт ReferenceGrant для общих backend;
• какие расширения допустимы и кто может менять Policy-ресурсы;
• как платформенные шаблоны будут проверяться admission-политиками.

Проверка поведения, а не только объектов

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

• точные пути и PathPrefix;
• регистр символов и граничные случаи регулярных выражений;
• rewrite и redirect с query string;
• HTTP и HTTPS, SNI и выбор сертификата;
• крупные запросы и длительные соединения;
• ошибочные backend и отсутствие endpoints;
• заголовки клиента и исходный IP;
• поведение при недоступности одной реплики контроллера.

Одновременно проверяют status Gateway и HTTPRoute, события контроллера, DNS и сетевую доступность снаружи VDS. Такой подход выявляет ситуации, когда манифест принят API-сервером, но не реализован data plane. Если новый маршрут возвращает ошибку из-за Service или отсутствующих endpoints, пригодится материал о диагностике 502 и 504 между Ingress, Service и Pod.

Когда Ingress пока может оставаться разумным выбором

Сохранение Ingress может быть оправдано, если выбранный и поддерживаемый контроллер продолжает реализовывать этот API, маршруты просты, а команда не нуждается в разделении инфраструктурных и прикладных ролей. Это особенно актуально для небольшого одноарендного кластера, где одни и те же администраторы управляют контроллером, TLS и приложениями.

Но решение следует принимать по жизненному циклу конкретного контроллера, а не исходя из того, что Ingress остаётся частью Kubernetes. Замороженный API стабилен, однако не получает новых выразительных возможностей. Если конфигурация продолжает расти за счёт proprietary-аннотаций, стоимость будущей миграции также растёт.

Когда Gateway API даёт заметное преимущество

Переход особенно полезен, если платформа:

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

Gateway API не обязательно уменьшает число строк YAML. Его преимущество заключается в более точном выражении отношений: кто предоставляет инфраструктуру, кто публикует listener, кто создаёт маршрут и кто разрешает доступ к backend.

Итог

После завершения Ingress-NGINX вопрос стоит не как «Ingress или новый синтаксис», а как выбор модели управления внешним трафиком. Ingress остаётся стабильным и компактным API, однако сложное поведение часто находится в аннотациях и глобальной конфигурации конкретного контроллера.

Gateway API разделяет GatewayClass, Gateway и HTTPRoute, лучше соответствует Kubernetes RBAC и даёт платформе явные механизмы делегирования. Стандартные поля повышают переносимость, но implementation-specific policies, фильтры и инфраструктурные параметры всё равно требуют учёта.

Для кластера на VDS переход необходимо рассматривать вместе с реальным сетевым трактом: публичными адресами, портами, Service, TLS, DNS и отказоустойчивостью узлов. Ingress2Gateway способен подготовить черновую конвертацию и выявить часть несовместимостей, но финальным критерием остаётся проверка фактического поведения. Наиболее безопасная стратегия — сначала описать используемые функции и новую модель владения, затем поднять параллельный контур и только после функциональных тестов переключать внешний трафик.