Привет, Хабр! Меня зовут Роман Тимошевский, и я являюсь лидом команды DevOps в компании Data Sapience. Мы отвечаем за поддержку инфраструктуры, в которой происходит разработка и тестирование нашх продуктов, таких как Data Ocean, Data Ocean Governance, Kolmogorov AI, CM Ocean и TALYS Ocean. Поэтому приходится активно взаимодействовать с Kubernetes и его сетевой составляющей с компонентами, отвечающими за внешний доступ к приложениям внутри кластеров. На текущий момент среди них — давно известный всем Ingress Controller и Gateway API, который призван прийти ему на замену.
Если вы последние пару лет следили за развитием сетевой подсистемы Kubernetes, то наверняка заметили, что вокруг Gateway API сложился странный консенсус: все согласны, что это будущее, но почти никто толком не понимает, какую именно реализацию брать и зачем уходить от привычного Ingress. В этой статье я попробую рассказать про ключевые отличия Gateway API от Ingress (на примере самого популярного — NGINX Ingress Controller), сравнить между собой основные реализации Gateway API и поговорить о нюансах кастомизации, интеграции и производительности.
Краткая предыстория: почему Ingress перестал всех устраивать
Ingress появился как простая абстракция, которая получает на входе адрес хоста и путь и, в соответствии с описанными правилами, перенаправляет трафик на нужный сервис. Но за годы эксплуатации накопились фундаментальные проблемы.
Главная боль — аннотации. Спецификация Ingress настолько бедна, что любая кастомизация поведения (rewrite, таймауты, canary, mTLS, rate limiting, кастомные заголовки) реализуется через аннотации, специфичные для конкретного контроллера. В итоге ваш Ingress-манифест с десятком nginx.ingress.kubernetes.io/* аннотаций — это не переносимая конфигурация, а проприетарный конфиг NGINX, замаскированный под стандартный объект Kubernetes. Переезд на другой контроллер означает переписывание всего.
Вторая проблема — отсутствие разделения ролей. В Ingress всё свалено в один объект: и инфраструктурная часть (порты, TLS, IP), и прикладная (маршруты, пути). Это значит, что разработчик приложения и платформенная команда работают с одним и тем же ресурсом, что порождает конфликты прав и ответственности.
Gateway API проектировался именно как ответ на эти две боли.
Что такое Gateway API концептуально
Gateway API — это не контроллер, а набор CRD и спецификация поведения, развиваемые в рамках SIG-Network. Ключевая идея — разделение ответственности через несколько ресурсов:
Архитектурная схема компонентов Gateway API:
GatewayClass — аналог StorageClass. Определяет, какая реализация (контроллер) будет обрабатывать Gateway. Управляется инфраструктурным провайдером;
Gateway — конкретный экземпляр шлюза: какие порты слушать, какие протоколы, TLS-сертификаты использовать. Зона ответственности платформенной команды;
HTTPRoute / GRPCRoute / TCPRoute / TLSRoute / UDPRoute — правила маршрутизации. Зона ответственности команд разработки.
Принципиальное отличие от Ingress: то, что раньше было аннотацией, теперь — типизированное поле в спецификации. Rewrite, редиректы, манипуляция заголовками, mirroring, weighted routing — всё это часть стандарта, а не вендорное расширение.
При этом надо честно сказать: Gateway API не покрывает 100% потребностей. Для специфичных вещей (rate limiting, авторизация, кастомные политики) используется механизм Policy Attachment — отдельные CRD, которые «прикрепляются» к Gateway или Route. И вот тут универсальность снова начинает страдать, потому что эти политики различаются для разных вендоров. Об этом ниже.
Уровни соответствия: важнейший нюанс при выборе
Gateway API делит фичи на три категории:
Core — обязательны для всех реализаций;
Extended — опциональны, но стандартизированы (если реализованы, то одинаково);
Implementation-specific — вендорные расширения.
Это значит, что заявление «контроллер X поддерживает Gateway API» почти ничего не говорит. Нужно смотреть отчёт о соответствии (conformance report) конкретной версии. Например, поддержка GRPCRoute, mesh-режима или session persistence сильно различается между реализациями. SIG-Network публикует таблицу с галочками — это первое, на что стоит смотреть.
Обзор основных реализаций
Реализаций уже десятки, но в проде имеет смысл рассматривать далеко не все. Разберём самые значимые.
NGINX Gateway Fabric
Официальная реализация Gateway API от команды NGINX (F5).
Плюсы: знакомый dataplane (NGINX), относительно низкое потребление ресурсов, понятная модель для тех, кто уже живёт на NGINX.
Минусы: молодой проект, по фичам пока отстаёт от связки «старый Ingress + аннотации». Многое из того, что в Ingress делалось аннотациями, в NGF либо ещё не реализовано, либо требует кастомных snippet-политик. Динамическая перезагрузка конфигурации в NGINX исторически означает reload процесса — при высокой частоте изменений маршрутов (частый CI/CD, autoscaling) это может вызывать кратковременный рост потребления CPU и обрыв части долгоживущих соединений.
Envoy Gateway
Реализация под эгидой CNCF/Envoy, по сути «упрощённый и стандартизированный» способ запустить Envoy как Gateway. Внутри — control plane, который транслирует Gateway API в xDS-конфигурацию Envoy.
Плюсы: Envoy — это де-факто индустриальный стандарт edge/mesh-прокси с богатейшим функционалом (продвинутый L7, retries, circuit breaking, observability через готовые метрики/трейсы). Динамическая перенастройка через xDS без реконфигурации процесса — большое преимущество при частых изменениях. Под высокой и динамичной нагрузкой Envoy ведёт себя предсказуемее NGINX.
Минусы: Envoy заметно прожорливее по памяти, чем NGINX, особенно при большом количестве маршрутов и кластеров (модель xDS держит конфигурацию кластеров и эндпоинтов в памяти, и при тысячах маршрутов потребление растёт заметно). По CPU при включённых фильтрах и трейсинге Envoy тоже дороже. На «голом» проксировании латентность чуть выше, чем у NGINX.
Cilium Gateway API
Если вы уже используете Cilium как CNI, его реализация Gateway API встроена в dataplane на базе eBPF + Envoy. L3/L4-маршрутизация, балансировка (замена kube-proxy) и enforcement network policy на уровне L3/L4 исполняются в ядре через eBPF-программы, без выхода в user-space. L7-обработка (HTTP-маршрутизация Gateway API, L7-фильтры) делегируется встроенному Envoy.
Плюсы: единая платформа для сети и Gateway API без дополнительных компонентов. На чистом L3/L4 eBPF в ядре даёт минимальный overhead, низкую латентность и отличную масштабируемость числа правил — eBPF-карты эффективнее, чем длинные цепочки iptables. Отличная интеграция с network policies в единой модели: трафик, входящий через Gateway, и внутрикластерный трафик управляются одними и теми же правилами.
Минусы: жёсткая привязка к Cilium как CNI — это решение архитектурного уровня, а не «просто поставить контроллер». Для L7-обработки всё равно поднимается Envoy, поэтому преимущество eBPF на L7 частично нивелируется: HTTP-трафик проходит через user-space прокси, и в этой части наследуется envoy’евский профиль потребления. Реальный выигрыш Cilium на L7 — скорее в эффективной доставке трафика до прокси и обратно, чем в самой L7-обработке.
Calico Ingress Gateway
Относительно свежее предложение от Tigera (создателей Calico). Ключевой факт, который надо понимать сразу: это не самостоятельный dataplane, а дистрибутив Envoy Gateway, интегрированный в экосистему Calico. То есть под капотом — тот же Envoy + Envoy Gateway control plane, но упакованный, протестированный и поддерживаемый в связке с сетевой и security-подсистемой Calico.
Логика тут такая же, как у Cilium: если у вас Calico уже выступает в роли CNI и движком сетевых политик, то Ingress Gateway даёт единую платформу — ingress-трафик, внутрикластерное сетевое взаимодействие, network policy и наблюдаемость управляются в одном стеке и одной модели безопасности.
Плюсы:
Нативная интеграция с Calico Network Policy. Главное ценностное предложение. Трафик, входящий через Gateway, попадает в единую модель политик Calico — можно бесшовно описывать правила и для ingress, и для внутрикластерного трафика. Это закрывает классический разрыв между «L7 ingress-правилами» и «L3/L4 network policies», которые в обычном стеке живут раздельно. Сама модель network policy Calico — зрелая и обкатанная годами.
Полноценный Gateway API через Envoy. Поскольку основа — Envoy Gateway, вы получаете богатый L7-функционал, динамическую реконфигурацию через xDS (без перезапуска) и хорошую observability.
Производительность L3/L4. Calico в современном eBPF-режиме dataplane по latency и масштабированию правил близок к Cilium; в классическом iptables-режиме на большом числе сервисов/правил проигрывает из-за линейного роста цепочек.
Поддерживаемость. Tigera поставляет это как протестированную, версионированную сборку, что для энтерпрайза часто важнее, чем самостоятельная эксплуатация upstream Envoy Gateway.
Минусы:
Привязка к экосистеме Calico. Как и в случае Cilium, реальный смысл решение приобретает, когда Calico уже ваш CNI/policy-движок. Тащить весь Calico ради ingress нерационально;
Наследует «налог» Envoy. Поскольку L7-dataplane — Envoy, наследуется и его профиль потребления: повышенный расход памяти на масштабе (xDS-модель кластеров/эндпоинтов), более высокий CPU при активных L7-фильтрах и трейсинге по сравнению с NGINX;
Молодость продукта в этой роли. Сам Calico зрелый, но именно Ingress Gateway как продуктовое направление новое — стоит внимательно смотреть conformance-отчёт нужной версии и проверять, какие Extended-фичи Gateway API реализованы, а какие — пока нет;
Зависимость от расширений Envoy Gateway для политик. Продвинутые сценарии (rate limiting, внешняя авторизация) конфигурируются через Policy Attachment в стиле Envoy Gateway (BackendTrafficPolicy, SecurityPolicy и т. п.) — то есть переносимость продвинутых политик ограничена, как и у «ванильного» Envoy Gateway.
По сути, Calico Ingress Gateway и Cilium Gateway API — это два конкурирующих ответа на один и тот же вопрос: «Как объединить L7-ingress с сетевыми политиками в рамках одной платформы?» Разница в акцентах: Cilium делает ставку на eBPF в dataplane (с делегированием L7 в Envoy) и даёт дешёвую L3/L4-наблюдаемость, а Calico — на курируемый hardened Envoy Gateway, плотно сшитый со своей зрелой моделью network policy и вендорной поддержкой. При этом на самом L7 оба используют Envoy и будут показывать сопоставимые RPS и латентность при одинаковой конфигурации — реальная разница между ними лежит в L3/L4, в подходе к политикам и наблюдаемости, а не в «ingress-бенчмарках». Поэтому выбор между ними почти всегда диктуется тем, какой CNI у вас уже стоит, — менять сетевой фундамент ради ingress дорого и рискованно.
Istio
Istio полноценно поддерживает Gateway API как нативный способ конфигурации (вместо собственных VirtualService/Gateway CRD). Причём Gateway API в Istio работает в двух режимах: ingress gateway и mesh (для внутрикластерного трафика между сервисами через parentRef на Service).
Плюсы: если вам нужен service mesh, Gateway API в Istio даёт единую модель и для входящего, и для внутреннего трафика. Богатейший L7-функционал, mTLS из коробки, продвинутая телеметрия.
Минусы: Istio — тяжёлая платформа с самыми высокими накладными расходами по ресурсам из-за control plane (istiod) и сайдкаров/ambient-компонентов. Брать его только ради ingress — стрельба из пушки по воробьям. Но если mesh вам нужен по другим причинам, ingress «бесплатно» использует уже оплаченную инфраструктуру.
Kong, Traefik, HAProxy, APISIX
Большинство популярных API-gateway и прокси добавили поддержку Gateway API:
Traefik — лёгкий, удобный для небольших инсталляций, хорошая поддержка Gateway API, но исторически часть фич живёт в собственных CRD (IngressRoute);
Kong — силён там, где нужен полноценный API-management (плагины, аутентификация, монетизация). Gateway API — лишь один из способов конфигурации;
HAProxy — высочайшая производительность L4/L7, минимальный overhead, но экосистема расширений беднее;
APISIX — на базе NGINX/OpenResty, богат плагинами.
Эти решения выбирают чаще не «ради Gateway API», а ради их основной специализации (API-management, производительность), а Gateway API идёт как приятный бонус.
Кастомизация: где заканчивается стандарт
Это, пожалуй, самый недооценённый аспект миграции. Сценарии, которые в NGINX Ingress делались одной аннотацией, в Gateway API распределяются между тремя механизмами:
Нативные поля спецификации — rewrite, redirect, request/response header modification, traffic splitting (weighted backends), mirroring. Это всё стандартизировано и переносимо. Хорошая новость: для большинства приложений этого достаточно;
Filters / ExtensionRef — точки расширения внутри HTTPRoute, ссылающиеся на вендорные CRD;
Policy Attachment — отдельные CRD для rate limiting, retries, таймаутов, авторизации, mTLS. Вот тут начинается вендор-специфика: в Envoy Gateway (и наследующем его функциональность Calico Ingress Gateway) это BackendTrafficPolicy/SecurityPolicy, в Cilium — свои аннотации, в NGF — ClientSettingsPolicy/UpstreamSettingsPolicy и snippet-механизмы.
Практический вывод: базовая маршрутизация переносима между реализациями, продвинутые политики — нет. Если ваша главная цель — «переносимость конфигурации между провайдерами», то она работает лишь частично, ровно до того момента, как вам понадобится rate limiting или внешняя авторизация.
Отдельно отмечу болезненный для многих момент: знаменитые NGINX snippets (вставка произвольного куска конфига) в Gateway API мире намеренно затруднены или отключены по умолчанию из соображений безопасности (вспомните CVE вокруг snippet-инъекций в Ingress-NGINX). Если ваша инсталляция держится на кастомных snippet’ах — это будет самая сложная часть миграции.
Интеграция с cert-manager
Здесь не всё так гладко. Cert-manager поддерживает Gateway API нативно, но, как всегда, есть нюансы. Вместо аннотации cert-manager.io/cluster-issuer на Ingress вы можете:
добавить аннотацию на объект Gateway (
cert-manager.io/cluster-issuer), и cert-manager сам создаст Certificate на основе TLS-listener’ов;явно создать Certificate и сослаться на секрет в манифесте Gateway;
явно создать Certificate и сослаться на секрет в манифесте ListenerSet/XListenerSet, предварительно разрешив подключать ListenerSet'ы из неймспейсов разработчиков к Gateway.
В итоге, если вам недостаточно одного wildcard-сертификата на весь кластер и вы хотите, чтобы разработчики могли выпускать уникальные сертификаты для своих HTTPRoute, каждый из которых привязан к своему поддомену, вам придётся либо прописывать их все вручную на уровне Gateway (который, как мы помним, находится в зоне ответственности команды поддержки платформы), либо плодить дополнительные сущности в виде ListenerSet'ов. Сделать это так же просто и удобно путём добавления одной аннотации на IngressHTTPRoute, как это было раньше, к сожалению, не получится.
Важный нюанс с ACME HTTP-01 challenge: cert-manager умеет решать challenge через Gateway API, создавая временный HTTPRoute. Нужно, чтобы это поддерживалось вашей реализацией (флаг --enable-gateway-api в cert-manager).
Производительность: общие закономерности
Сразу оговорюсь: бенчмарки сильно зависят от профиля нагрузки, числа маршрутов, размера тел запросов, доли keep-alive соединений и включённых фич (TLS termination, L7-фильтры). Любые «X RPS быстрее Y» без указания условий — маркетинг. Конкретные нюансы каждого решения я разобрал в обзоре реализаций выше. Здесь — обобщающая картина.
Ключевые различия проходят по двум осям: dataplane (NGINX vs Envoy vs eBPF) и способ реконфигурации (reload vs xDS).
NGINX-решения выигрывают по памяти и latency на статичной конфигурации, но проигрывают за счёт reload’ов при частых изменениях;
Envoy-решения (Envoy Gateway, Istio, Cilium и Calico) дороже по памяти и CPU, но обеспечивают динамическую реконфигурацию без reload и предсказуемое поведение под динамичной нагрузкой;
eBPF-решения (Cilium, Calico в eBPF-режиме) дают минимальный overhead на L3/L4, но, как только трафик попадает в L7-обработку Gateway API, оба сводятся к Envoy, и преимущество eBPF в этой части нивелируется.
Главный практический вывод: на самом L7 все Envoy-based решения показывают сопоставимые цифры при одинаковой конфигурации, поэтому выбор между ними редко стоит делать по «ingress-бенчмаркам». Гораздо важнее dataplane на L3/L4, модель сетевых политик, наблюдаемость и, что часто решает всё — какой CNI у вас уже стоит.
Производительность: тесты
Всё описанное выше — это теория и накопленный опыт тех, кто работал с этими решениями (пусть и не в роли Gateway API). Дополнительно я решил провести небольшой практический тест некоторых популярных универсальных реализаций Gateway API.
Стенд представляет из себя:
Managed k8s кластер в Яндекс облаке, на котором установлены:
NGINX Ingress
NGINX Gateway Fabric
Envoy Gateway
Istio Gateway
Тестовый под с веб-страницей на 100 МБ, хранящейся в памяти
Виртуальная машина, с которой запускается утилита
wrkдля генерации нагрузки
Все компоненты установлены со стандартными параметрами, без дополнительных модификаций и оптимизаций.
Провёл 4 теста с разным количеством активных подключений — 4, 8, 16 и 32. Результаты получились следующими:
Результаты при разном профиле нагрузки получились неоднозначными, но в целом можно сделать вывод, что NGINX как в случае Gateway API, так и в случае Ingress Controller показывает худшие результаты как по пропускной способности, так и по утилизации CPU. К моему удивлению, Istio оказался шустрее всех, а Envoy в большинстве сценариев занял почётное второе место. Утилизация памяти во всех сценариях для всех реализаций оказалась незначительной (не более 100 МБ), поэтому не стал отражать её в таблице.
Данный тест был проведен в максимально простых условиях и далеко не с самой высокой нагрузкой. Поэтому важно понимать, что в реальных окружениях картина может сильно отличаться в зависимости от количества и настроек манифестов HTTPRoute, TCPRoute, размера веб-страниц, частоты создания и изменений манифестов и многих других факторов.
Как выбрать: практические рекомендации
Если убрать хайп, решение сводится к нескольким вариантам:
NGINX Ingress Controller: эксплуатировать целесообразно, если: у вас стабильная конфигурация, всё работает, команда знает NGINX, сложные потребности уже закрыты аннотациями и ваше кластер находится в защищённом контуре без доступа снаружи. Держите в голове, что развитие классического Ingress фактически заморожено с марта 2026 года и нет никаких гарантий, что вендор будет выпускать хотфиксы в случае обнаружения новых уязвимостей;
Envoy Gateway: если хотите «чистую» реализацию Gateway API без привязки к платформе, нужны богатые L7-возможности и динамичная среда с частыми изменениями;
NGINX Gateway Fabric: если хотите Gateway API, но психологически и операционно остаётесь в мире NGINX и ваши требования укладываются в текущий (пока ограниченный) набор фич;
Cilium Gateway: если вы уже используете Cilium в качестве CNI или строите платформу с единым подходом к сети, политикам и наблюдаемости, и вам важна eBPF-эффективность на L3/L4;
Calico Ingress Gateway: если Calico уже ваш CNI и движок сетевых политик, вам нужен полноценный Gateway API на базе Envoy и при этом критична единая модель безопасности для ingress и внутрикластерного трафика с поддержкой от вендора. Это прямая альтернатива Cilium Gateway для тех, кто исторически стоит на Calico и не хочет менять сетевой фундамент ради application-layer networking;
Istio: только если вам реально нужен service mesh — тогда Gateway API становится естественным единым языком как для внешнего, так и для внутреннего трафика;
Kong/APISIX/Traefik: если ваша задача — полноценный API-management или вам важна их специфическая специализация, а Gateway API — лишь способ конфигурации.
Итог
Gateway API — это правильное архитектурное решение давних проблем Ingress: типизированная спецификация вместо аннотаций и чёткое разделение ролей. Но «универсальной переносимости» в полном смысле он не даёт: базовая маршрутизация стандартизирована, а всё интересное (политики, rate limiting, авторизация) снова уходит в вендорную специфику через Policy Attachment.
Поэтому выбор реализации — это по-прежнему выбор экосистемы и dataplane, как и в эпоху Ingress. Разница в том, что теперь у вас есть хотя бы общий язык для 80% типовых сценариев, и менять реализацию стало менее болезненно, чем переписывать сотни аннотаций. А такие решения, как Cilium Gateway и Calico Ingress Gateway, показывают новый тренд: ingress перестаёт быть изолированным компонентом и срастается с сетевой платформой и моделью безопасности кластера в единое целое.
Мигрируйте осознанно. Начните с conformance-отчётов нужных вам реализаций, выпишите список своих текущих аннотаций и проверьте, во что каждая из них превращается в выбранной реализации. И тестируйте на своём профиле трафика — число маршрутов, доля keep-alive, размер страниц, объём network-policy правил и включённые L7-фильтры влияют на результат сильнее, чем выбор между конкретными платформами. Именно этот аудит, а не бенчмарки RPS, чаще всего и определяет реальную стоимость перехода.
Делитесь в комментариях, какие реализации используете вы и почему. И подписывайтесь на блог Data Sapience на Habr и наш Telegram-канал.
