Что такое KGateway и почему он приходит на смену Ingress NGINX в Kubernetes

11 ноября 2025 года команда Kubernetes объявила: maintenance Ingress NGINX прекращается в марте 2026 года. Больше не будет релизов, багфиксов и патчей безопасности, а репозитории переходят в режим read-only. Учитывая, что Ingress NGINX — один из самых распространённых ingress-контроллеров в Kubernetes, ему пришлось искать замену. Сам Kubernetes официально порекомендовал миграцию Kubernetes Gateway API. Одна из его зрелых реализаций — KGateway Kubernetes, бывший Gloo Gateway.

Разберём, в чём разница между этими технологиями, почему переход вам точно нужен даже если забыть о прекращении поддержки и как это всё устроено в VK Cloud Managed Kubernetes.

Главная проблема старого Ingress

На NGINX до сих пор держится половина интернета, и вопрос возникает не к самому прокси, а к концепции ресурса Ingress, под которым он работает в Kubernetes. За годы эта модель упёрлась в три ограничения.

«Монолитный» манифест. Один ресурс Ingress смешивает в себе всё сразу: маршрутизацию путей API, TLS-сертификаты и глобальные параметры балансировщика. Логика приложения и инфраструктурные настройки лежат в одном YAML, хотя относятся к разным зонам ответственности.

Конфликт ролей. За инфраструктуру, домены и TLS отвечают DevOps- и системные инженеры. За пути вида /api/v1 к микросервисам — команды разработки. А правят они один и тот же файл. Это источник ошибок и риск для безопасности: чтобы добавить маршрут к новому сервису, разработчику приходится трогать манифест, где рядом лежат сертификаты и сетевые параметры всего кластера.

Перегрузка аннотациями. Базовая спецификация Ingress умеет немного. Всё, что выходит за рамки простой маршрутизации — canary-деплой, rate limiting, перезапись путей, — реализуется через десятки специфичных для контроллера аннотаций вида nginx.ingress.kubernetes.io/....

Разберём на практике, как это выглядит. Чтобы пустить 10% трафика на canary-версию сервиса, в Ingress NGINX заводят отдельный ресурс Ingress с парой аннотаций:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
    nginx.ingress.kubernetes.io/limit-rps: "20"

Здесь canary: "true" помечает ресурс как canary-вариант, canary-weight: "10" задаёт долю трафика, а limit-rps: "20" ограничивает число запросов в секунду. Проблема в том, что все эти параметры — обычные строки в карте аннотаций. Их не проверяет схема API: опечатка в имени аннотации или недопустимое значение не отловятся на этапе kubectl apply — контроллер просто молча проигнорирует строку, и поведение разойдётся с ожиданием. Веса, лимиты и флаги живут не в типизированных полях, а в текстовых ключах, о существовании которых знает только конкретный контроллер.

Из-за этого манифест перестаёт быть переносимым. Перенести его на другой контроллер без переписывания невозможно: аннотации nginx.ingress.kubernetes.io/... понимает только Ingress NGINX, у Traefik или HAProxy свой набор префиксов и свои правила. Это привязка к конкретной реализации: чем больше тонкой логики ушло в аннотации, тем дороже потом сменить контроллер. И вся эта логика остаётся невидимой для инструментов валидации — линтеры и admission-контроллеры видят корректный с точки зрения схемы Ingress, не подозревая, что половина поведения зашита в строках.

Ко всем этим концептуальным ограничениям добавился вопрос безопасности. В марте 2025 года исследователи Wiz раскрыли набор уязвимостей IngressNightmare, включая CVE-2025-1974 — неаутентифицированный RCE через admission webhook контроллера. Фикс вышел в версиях 1.12.1 и 1.11.5. Инцидент показал, насколько критична эта точка входа в кластер и насколько важно её архитектурное состояние.

Что такое KGateway и при чём тут Kubernetes Gateway API

Чтобы понять KGateway, нужно сначала развести два понятия: стандарт и его реализацию.

Kubernetes Gateway API — это официальный стандарт сетевой архитектуры, который развивает рабочая группа SIG-Network. Это не сторонний инструмент и не продукт вендора, а спецификация уровня самого Kubernetes. Релиз v1.0 со статусом GA вышел 31 октября 2023 года, актуальная версия — v1.3.0 от июня 2025 года. Gateway API задаёт набор стандартных ресурсов (GatewayClass, Gateway, HTTPRoute и другие), которые работают одинаково независимо от того, какой контроллер стоит под капотом.

По данным совместного исследования CNCF и SlashData (ноябрь 2025 года), фундаментальные API-gateway-технологии используют около 50% backend-разработчиков. Эта цифра относится к gateway-технологиям в целом, а не строго к Kubernetes Gateway API — но она показывает, что управляемый вход в кластер превратился в часть базовой инфраструктуры. На фоне такого спроса вокруг стандарта выросло сразу несколько реализаций: помимо KGateway, спецификацию Gateway API поддерживают Envoy Gateway, Istio и Cilium. KGateway — одна из них, и выбор реализации не привязывает вас к одному вендору, ведь ресурсы остаются стандартными.

KGateway — это конкретная реализация Gateway API. Легковесный декларативный API-шлюз на базе прокси Envoy, спроектированный под спецификацию Gateway API. Раньше проект назывался Gloo Gateway и развивался компанией Solo.io с 2018 года под именем Gloo. 4 марта 2025 года KGateway приняли в CNCF Sandbox. KGateway нативно встроен в экосистему Kubernetes: он не требует отдельной плоскости управления вне кластера и работает со стандартными ресурсами Gateway API.

Связь простая: Gateway API описывает что должно работать, KGateway отвечает за то, как это исполняется на движке Envoy.

Разделение ролей на уровне архитектуры

Главное преимущество Gateway API — role-oriented design, разделение ответственности на уровне самой модели ресурсов. Вместо одного перегруженного Ingress вводятся три уровня абстракции, каждый со своим владельцем.

GatewayClass создаётся инфраструктурным провайдером, например облачной платформой VK Cloud. Определяет тип балансировщика и конкретную реализацию контроллера. Это шаблон, который команды кластера получают готовым.

Gateway настраивается инфраструктурной командой, DevOps или NetOps. Здесь живут порты, TLS-сертификаты и глобальные правила доступа. Сетевой периметр и его защита остаются в руках тех, кто за них отвечает.

HTTPRoute (а также TCPRoute и GRPCRoute) отдаётся командам разработки. Здесь описываются пути маршрутизации к микросервисам. Разработчику не нужен доступ к TLS-сертификатам и базовой сети, он работает только со своим маршрутом.

Так конфликт ролей из модели Ingress исчезает: каждый редактирует свой ресурс, не задевая чужой. Минимальный HTTPRoute выглядит так:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: team-payments
spec:
  parentRefs:
    - name: shared-gateway
      namespace: infra
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v1
      backendRefs:
        - name: payments-service
          port: 8080

Разработчик команды team-payments управляет только маршрутом и ссылается на общий Gateway в неймспейсе infra через parentRefs. Сертификаты и порты он не видит, ими владеет инфраструктурная команда.

Ещё одно отличие, которое сильно упрощает эксплуатацию, — явное состояние ресурсов. Gateway API делает состояние объектов наблюдаемым через типизированные поля status. У Gateway это условия вроде Accepted и Programmed: первое говорит, что контроллер принял конфигурацию, второе — что она реально применена на дата-плоскости. У маршрутов в status отражается факт привязки к родительскому Gateway. У Ingress такого типизированного описания состояния нет: понять, почему правило не работает, чаще приходится через логи контроллера и косвенные признаки. В Gateway API статус — это часть контракта API, поэтому диагностика сводится к чтению полей объекта, а не к расследованию по логам.

Сравнительный анализ: KGateway vs Ingress NGINX

Продвинутые возможности KGateway, недоступные в стандартном NGINX

Часть сценариев в модели Ingress либо требует обвязки из аннотаций, либо невозможна вовсе. Gateway API и KGateway закрывают их нативно.

Cross-Namespace Routing через ReferenceGrant. Разработчики безопасно ссылаются на сервисы и маршруты из других неймспейсов без объединения прав доступа. Типичный кейс в крупном кластере выглядит так: общий Gateway живёт в инфраструктурном неймспейсе (например, infra), а маршруты HTTPRoute — в неймспейсах продуктовых команд (team-payments, team-billing и так далее). Команда заводит свой маршрут и ссылается на чужой Gateway или на сервис в соседнем неймспейсе. Но просто сослаться нельзя — нужно встречное разрешение: владелец целевого ресурса заводит ReferenceGrant, который явно перечисляет, из каких неймспейсов и на какие типы объектов разрешены ссылки. Связь возникает только при обоюдном согласии — тот, кто владеет целевым сервисом, контролирует, кто на него ссылается. Это подходящая модель для больших кластеров, где команды изолированы по неймспейсам и никто не должен дотянуться до чужого сервиса в обход его владельца.

Нативный Traffic Splitting. Разделение трафика между версиями сервиса — 90% на стабильную v1 и 10% на canary v2 — описывается декларативно через поле weight прямо в HTTPRoute. Без плагинов и без аннотаций:

rules:
    - backendRefs:
    - backendRefs:
        - name: service-v1
          port: 8080
          weight: 90
        - name: service-v2
          port: 8080
          weight: 10

Глубокая поддержка современного стека. KGateway даёт первоклассную поддержку gRPC и HTTP/3 — на движке Envoy это работает на уровне ядра, а не надстройки. Для микросервисной архитектуры, где gRPC давно стал основным транспортом между сервисами, это критично.

Как это устроено в VK Cloud Managed Kubernetes

В VK Cloud Managed Kubernetes на текущий момент существует связка ingress-контроллер плюс HTTP-балансировщик VK Cloud: балансировщик терминирует SSL/TLS и перенаправляет трафик на контроллер внутри кластера. Это рабочая и проверенная модель для входящего HTTP-трафика.

Принцип интеграции с облачными балансировщиками общий для современных кластеров: когда вы создаёте сетевой ресурс, требующий внешнего доступа, VK Cloud Load Balancer автоматически выделяет под него внешний IP. Это снимает с команды ручную рутину по выделению и привязке адресов. Та же логика применима и к ресурсам Gateway API: Gateway запрашивает точку входа, а облако обеспечивает её внешним адресом.

С чего начать миграцию с Ingress NGINX

В феврале 2026 года Google опубликовал в своём Open Source Blog материал о завершении эпохи Ingress NGINX и migration roadmap — план перехода с Ingress NGINX на Gateway API; в нём рекомендуют инструмент ingress2gateway для автоматического переноса правил и пилот на любой конформной реализации. Появление такого roadmap у крупного игрока означает, что миграция перестала быть экспериментом и обрела понятную траекторию.

Общая логика перехода складывается из нескольких шагов:

1. Инвентаризация аннотаций: пройтись по всем ресурсам Ingress и выписать, какие аннотации nginx.ingress.kubernetes.io/... реально используются и за что отвечают. Этот список показывает, какая логика трафика зашита в строках и что предстоит перенести в типизированные поля Gateway API.
2. Развернуть контроллер Gateway API параллельно с действующим Ingress NGINX, не выключая старый: две модели какое-то время сосуществуют, и это снижает риск простоя.
3. Перенести правила маршрутизации в новую модель: глобальные параметры, порты и TLS уходят в Gateway, а пути и backend'ы — в HTTPRoute. Здесь же аннотации превращаются в нативные поля: canary-веса — в weight, кросс-неймспейс-ссылки — в ReferenceGrant.
4. Постепенное переключение трафика: сначала на новый контроллер уходит часть запросов, поведение сверяется по полям status и метрикам, и только затем доля растёт до полного перевода.

Поэтапный подход даёт точку отката на каждом этапе и не требует одномоментной смены всей сетевой схемы кластера.

Заключение

Эра классического Ingress подходит к концу: maintenance Ingress NGINX прекращается в марте 2026 года. На смену приходит Kubernetes Gateway API — официальный стандарт сетевой архитектуры, а KGateway Kubernetes становится одним из зрелых инструментов для его реализации на движке Envoy. Теперь вместо перегруженного манифеста с конфликтом ролей появляется чистое разделение ответственности между инфраструктурой и разработкой.

Если вы планируете архитектуру кластера на годы вперёд, стоит закладывать современные стандарты сетевой инфраструктуры уже сейчас. Присмотритесь к Gateway API как к целевой модели маршрутизации и попробуйте её в экосистеме Managed Kubernetes от VK Cloud.