Kubernetes API Gateway: от Ingress к Gateway API

Пока приложение ютится в одном поде и одном namespace, роль точки входа спокойно выполняет обычный Service. Но стоит появиться десяткам микросервисов, нескольким командам и требованиям к канареечным релизам — и на входе в кластер требуется отдельный слой. Kubernetes API Gateway принимает внешний трафик, маршрутизирует его, ограничивает по скорости, проверяет токены и шифрует соединения. Долгие годы эту задачу решал Ingress, но его аннотации превратились в зоопарк несовместимых расширений. На смену пришёл Gateway API — набор стандартизированных CRD, который поддерживают Envoy, Kong, Traefik, Istio и Cilium.

Под API Gateway в контексте Kubernetes понимают управляемый контроллер, публикующий сервисы кластера наружу и выполняющий над запросами набор политик: маршрутизацию по путям и заголовкам, TLS-терминацию, ограничение частоты запросов, аутентификацию, трансформацию тела запроса, ретраи и circuit breaking. Такой трафик называют north-south — он идёт снаружи внутрь кластера, в отличие от east-west, который циркулирует между подами и обычно управляется service mesh.

Классический Ingress Controller закрывал лишь первую часть задачи: «хост + путь → сервис». Всё остальное описывалось аннотациями вида nginx.ingress.kubernetes.io/..., и они не переносились между реализациями. Переезд с NGINX на Traefik означал переписывание манифестов с нуля. Gateway API (ранее Service APIs) — ответ сообщества: набор типизированных CRD, где каждая возможность описана отдельным полем, а не строкой в аннотации. Главная выгода — разделение ответственности. Инфраструктурная команда управляет GatewayClass и Gateway, а продуктовые разработчики — своими HTTPRoute. Больше не нужно выдавать доступ к кластерным настройкам балансировщика каждому, кто просто хочет опубликовать новый эндпоинт.

Модель держится на нескольких объектах. GatewayClass — аналог StorageClass: указывает, какой контроллер обслуживает ресурсы, обычно создаётся один раз администратором кластера. Gateway описывает саму точку входа: порты, протоколы, TLS-сертификаты, адрес балансировщика. HTTPRoute, GRPCRoute, TLSRoute и TCPRoute задают правила маршрутизации и привязываются к Gateway через parentRefs. ReferenceGrant разрешает маршруту из одного namespace ссылаться на сервис или секрет из другого.

Выбор контроллера определяет, какие политики вы получите из коробки, а какие придётся дописывать через EnvoyFilter или плагины. Расклад по ключевым решениям выглядит так:

• NGINX Ingress — движок NGINX, поддержка Gateway API частичная, rate limiting через аннотации, mTLS ограничен, внедрение простое.
• Traefik — собственный движок на Go, Gateway API с версии v3, лимиты через Middleware, mTLS есть, порог входа низкий.
• Kong Gateway — OpenResty, полная поддержка Gateway API, кластерный лимит через плагин, mTLS есть, сложность средняя.
• Envoy Gateway — референсная реализация на Envoy Proxy, лимиты через BackendTrafficPolicy, mTLS есть, сложность средняя.
• Istio Ingress — Envoy, настройка через EnvoyFilter или Wasm, встроенный mTLS, внедрение сложное.
• Cilium Gateway — eBPF плюс Envoy, политики через CiliumNetworkPolicy, mTLS на уровне ядра, сложность средняя.

Если вы только начинаете и нужен минимальный входной барьер — берите Traefik или NGINX. Планируете L7-политики, gRPC и тонкую observability — смотрите на Envoy Gateway или Istio. Если сеть уже построена на Cilium, логично не ставить второй прокси.

Практика начинается с установки оператора Envoy Gateway через Helm и создания первого маршрута. Предполагается, что кластер уже имеет LoadBalancer или MetalLB. Сначала применяются CRD Gateway API стандартных каналов v1, затем ставится сам оператор, после чего проверяется, что класс шлюза появился и признан валидным. Дальше описываются точка входа и правило маршрутизации — причём Gateway и HTTPRoute можно держать в разных namespace, и это как раз и есть разделение ролей. После применения манифестов статус условий Accepted и Programmed подтверждает, что конфигурация принята контроллером.

Ограничение частоты запросов в Envoy Gateway задаётся отдельным ресурсом, который ссылается на маршрут. Это удобнее аннотаций: политика версионируется вместе с кодом и проверяется валидатором. Когда базовая маршрутизация работает, начинается самое интересное — три задачи, которые закрывает почти любой продакшен-контур. Канареечный деплой через веса в backendRefs: 5% трафика на новую версию, затем постепенное увеличение, а откат — простое изменение манифеста. JWT-авторизация на входе: Gateway валидирует подпись и aud до того, как запрос дойдёт до пода, снимая нагрузку с приложений и унифицируя проверку между сервисами. mTLS между шлюзом и бэкендами: в Istio и Cilium включается одной настройкой, в Envoy Gateway — через ClientTrafficPolicy и BackendTLSPolicy, что защищает от прослушивания трафика внутри кластера.

Не включайте mTLS и rate limiting «на всякий случай» на старте. Сначала измерьте базовую задержку без политик — потом добавляйте по одному правилу и смотрите на p99. Иначе при первом инциденте будет непонятно, что именно тормозит цепочку.

Опыт миграции трёх кластеров с Ingress на Gateway API показывает закономерность: главная экономия времени приходит не от новых возможностей, а от валидации. Ingress с опечаткой в аннотации молча игнорирует её — трафик уходит не туда, и вы ищете проблему в логах приложения. Gateway API возвращает понятный статус с сообщением ResolvedRefs: False, Reason: BackendNotFound, если сервис не существует. Одна эта деталь экономит часы дебага ночью. Второй момент: команды быстро перестают плодить «снежинки» — шаблон HTTPRoute у всех одинаковый, и ревью конфигов занимает минуты.

По количеству шлюзов в кластере обычно разделяют публичный (интернет) и внутренний (VPN, партнёры). Так проще применять разные политики безопасности и разные сертификаты, не создавая отдельный кластер. С legacy-Ingress разумно держать оба контроллера параллельно: новые сервисы публиковать через HTTPRoute, старые переносить по мере релизов. Общий LoadBalancer разделить нельзя, поэтому либо два разных адреса, либо миграция через DNS с TTL в 60 секунд. Тестировать конфигурацию до продакшена лучше на kind или k3d локально с тем же контроллером, что и в продакшене, прогоняя kubectl apply --dry-run=server в CI — серверная проверка ловит неверные ссылки между объектами, которые клиентский dry-run пропускает.

Service mesh вместе с Gateway нужен не всегда. Gateway закрывает north-south, а mesh — east-west: ретраи, таймауты, взаимный TLS между подами. Если у вас меньше 10 сервисов, часто достаточно Gateway с политиками и обычных Kubernetes NetworkPolicy.

Kubernetes API Gateway в 2026 году — уже не эксперимент, а рабочая замена Ingress. Gateway API даёт типизированные объекты, разделение ролей между командами и единый набор политик для HTTP, gRPC и TCP. Движок выбирается под задачу: Traefik для скорости внедрения, Envoy или Istio для сложных L7-сценариев, Cilium — если сеть уже на eBPF. Начните с одного HTTPRoute, проверьте статусы, а лимиты и mTLS добавляйте по мере роста нагрузки. И держите политики в Git рядом с приложением — тогда откат конфигурации будет таким же обыденным делом, как откат деплоймента.