13 мин

8.1K

Сейчас ландшафт сетей Kubernetes переживает самую значительную трансформацию со времен появления Ingress API в 2015 году. Gateway API прошел путь от бета-версии до General Availability и продолжает развиваться: к 2026 году — версия 1.4. Это фундаментальная переархитектура того, как трафик моделируется, управляется и защищается в Cloud-Native-окружениях. Это руководство — исчерпывающий анализ экосистемы вокруг этого стандарта: разбираем архитектурные подходы, характеристики производительности и наборы функций ведущих реализаций.

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

Команда VK Cloud перевела статью для тех, кто уже несколько лет живет с зоопарком Ingress-аннотаций под NGINX, Traefik и ALB и сейчас выбирает, на что мигрировать. Автор разбирает Gateway API в его нынешнем состоянии (версия 1.4, GA), сравнивает пять Production-Ready-реализаций — Envoy Gateway, Istio в Ambient Mode, Cilium, Kong и NGINX Gateway Fabric — и дает фреймворк выбора под конкретный профиль нагрузки. Никакого маркетинга и «лучшего решения для всех»: цифры по Latency и CPU, архитектурные компромиссы, явные пределы масштабирования каждой модели.

Смена парадигмы: от Ingress к Gateway API

Чтобы понять сравнительные достоинства современных реализаций, сначала разберем недостатки, которые они призваны устранить. Ведь Gateway API — это структурное исправление ограничений ресурса Ingress.

Структурные ограничения Ingress API

Ingress API разработали в эпоху, когда кластеры Kubernetes часто были небольшими, однотенантными и ориентированными в первую очередь на простую HTTP-маршрутизацию. Он давал монолитный конфигурационный объект, который объединял предоставление инфраструктуры с маршрутизацией приложений. Эта связанность оказалась катастрофической для мультитенантных операций: Cluster Operator, управляющий инфраструктурой балансировщика нагрузки, вынужден был плотно координироваться с разработчиками приложений, определяющими маршруты. Часто это приводило к конфликтам прав доступа и случайным сбоям.

Следующая таблица подчеркивает ключевые структурные различия между устаревшей моделью Ingress и современной архитектурой Gateway API.

Спецификация Ingress была печально известна тем, что ее недостаточно проработали. В ней не хватало стандартизированных полей для продвинутых, но обычных требований: разделения трафика, манипуляции заголовками, тайм-аутов. Чтобы заполнить пробел, вендоры ввели аннотации — строковые пары «ключ — значение», специфичные для каждого контроллера. Например, правило перезаписи требовало специальной аннотации для NGINX, но совершенно другой — для Traefik или HAProxy. Этот зоопарк аннотаций (Annotation Sprawl) уничтожал переносимость: перенос приложения из кластера на базе NGINX в кластер на базе AWS ALB требовал полного переписывания манифестов Ingress.

Философия дизайна Gateway API: ролевая декомпозиция

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

GatewayClass управляется Platform Provider — например, облачным провайдером или командой Platform Engineering. Действует как шаблон, определяющий, какой контроллер будет обрабатывать трафик. Например, кластер может иметь один GatewayClass для AWS Load Balancer, обращенного в интернет, и другой — для внутреннего Envoy-прокси.

Gateway управляется Cluster Operator. Этот ресурс представляет собой развернутый экземпляр физического или логического балансировщика нагрузки. Определяет listeners, включая порты, протоколы и настройки терминации TLS. Что важно, ресурс Gateway ничего не знает о бэкендах приложений — он знает только, как принимать трафик.

Routes (HTTPRoute, GRPCRoute, TLSRoute, TCPRoute и UDPRoute) управляются разработчиками приложений. Эти ресурсы привязываются к Gateway и определяют логику маршрутизации запросов от Listener к фактическим Kubernetes-сервисам. Привязка позволяет разработчикам независимо контролировать свою логику маршрутизации, если у них есть разрешение на присоединение к Gateway.

Стандартизация расширенного управления трафиком

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

Разделение трафика поддерживается нативно. Ресурс HTTPRoute включает поле weight в своих backendRefs, что дает нативные канареечные деплои во всех соответствующих реализациях.

Модификация заголовков. Фильтры для добавления, удаления или изменения заголовков запросов и ответов стандартизированы. Это гарантирует, что определение маршрута остается валидным независимо от того, какой Data Plane используется: Envoy, NGINX или Pipy.

Маршрутизация между неймспейсами обрабатывается ресурсом ReferenceGrant. Он позволяет Gateway в неймспейсе Infra маршрутизировать трафик к Service в неймспейсе App через механизм безопасного рукопожатия — через явные RBAC-подобные гранты, а не через неявное доверие.

Три архитектурные модели реализации

API стандартен, но движки, приводящие его в действие, сильно различаются. В ландшафте 2025 года доминируют три архитектурные парадигмы: модель Envoy-Native, модель NGINX-Adapter и модель Kernel-Native eBPF.

Модель Envoy-Native

Envoy Proxy стал де-факто Data Plane для Cloud-Native-эпохи, и многие реализации Gateway API по сути являются Control Plane для Envoy. В этой модели, которую используют Envoy Gateway, Contour, Istio и Gloo, ресурсы Kubernetes транслируются контроллером в нативный конфигурационный протокол Envoy — xDS.

У такой архитектуры значительные преимущества. Envoy богат функциональностью и поддерживает продвинутые алгоритмы балансировки нагрузки, Circuit Breaking (размыкатель цепи) и глобальное ограничение частоты запросов «из коробки». Поскольку Gateway API сильно вдохновлен возможностями Envoy, часто наблюдается почти 1:1 соответствие между полями API и конфигурацией Envoy — это дает высокую точность реализации.

Однако модель не лишена издержек. Слой трансляции, преобразующий объекты Kubernetes в xDS, может быть ресурсоемким. В больших кластерах с тысячами маршрутов Control Plane должен пересчитывать весь граф зависимостей и отправлять обновления прокси Data Plane. Как показывают бенчмарки, эффективность этого цикла согласования значительно варьируется между такими реализациями, как Istio, и другими.

Модель NGINX-Adapter

NGINX остается самым популярным веб-сервером в мире, и его экосистема адаптировалась к Gateway API через проекты вроде NGINX Gateway Fabric и Kong. В отличие от модели согласованности в конечном счете у Envoy через xDS, NGINX традиционно полагался на конфигурационные файлы, которые требовали перезагрузки процесса для применения изменений.

Современные реализации NGINX смягчают штраф за перезагрузку разными стратегиями. Kong использует OpenResty для динамической маршрутизации трафика на основе данных, хранящихся в памяти, — это избавляет от перезагрузок при изменениях маршрутов. NGINX Gateway Fabric использует API NGINX Plus в коммерческой версии или высокооптимизированные перезагрузки конфигурации в версии OSS для применения состояния.

Проблема этой архитектуры — несоответствие моделей (Impedance Mismatch). Высокодинамичная и распределенная природа Gateway API естественно сочетается с дизайном Envoy, но для NGINX требует сложности слоя адаптации. Например, у NGINX Gateway Fabric наблюдался всплеск нагрузки на CPU, когда активны несвязанные контроллеры. Это указывает на неэффективность фильтрации потока событий Kubernetes по сравнению с более зрелыми контроллерами Envoy.

Модель Kernel-Native eBPF

Cilium представляет передовой край высокопроизводительных сетей и переносит Data Plane в ядро Linux с помощью eBPF. В традиционной прокси-модели пакет проходит через TCP-стек ядра, копируется в пользовательское пространство, где находится прокси, обрабатывается и затем копируется обратно в ядро для пересылки. Это переключение контекста влечет за собой задержку.

Архитектура Cilium пытается обойти это. Для трафика уровня L4 Cilium использует eBPF-программы, прикрепленные к сетевому интерфейсу, для прямой маршрутизации пакетов — это дает производительность, близкую к линейной скорости на Bare-Metal. Однако eBPF не может легко обрабатывать сложный парсинг уровня L7 — модификацию HTTP-заголовков или транскодирование gRPC. Поэтому Cilium использует гибридную модель: L4 обрабатывается в ядре, а трафик L7 передается в Envoy-прокси в пользовательском пространстве, управляемый Cilium.

Эта объединенная архитектура создает операционную сложность. Шлюз больше не просто под, а распределен по сетевому стеку всего кластера. Обновление реализации шлюза часто означает обновление самого CNI — высокорисковая операция, затрагивающая весь трафик кластера.

Глубокое погружение: экосистема Envoy-Native

Envoy Gateway: эталонная реализация стандарта

Envoy Gateway — это проект CNCF, инициированный для канонической и вендор-нейтральной реализации Gateway API для Envoy. Он родился из консолидации усилий Tetrate, Ambassador и других, чтобы остановить фрагментацию Ingress-контроллеров на базе Envoy.

Envoy Gateway работает по модели управляемой инфраструктуры. Когда пользователь создает ресурс Gateway, контроллер Envoy Gateway обнаруживает это и автоматически предоставляет необходимые ресурсы Kubernetes — Deployments, Services и HorizontalPodAutoscaler — для развертывания пула Envoy-прокси. Это отличается от старых контроллеров вроде Contour, где развертывание прокси часто было ручным или статическим.

Контроллер использует xDS-сервер для отправки динамических обновлений этим предоставленным прокси. Он поддерживает разделение ответственности: Control Plane может находиться в одном неймспейсе, управляя Gateway, распределенными по тенантным неймспейсам, при этом сохраняя строгие границы RBAC.

Envoy Gateway поддерживает всю широту стандарта: HTTPRoute, GRPCRoute, TLSRoute, TCPRoute и UDPRoute. Реализует разделение трафика и модификацию заголовков как стандартные базовые возможности. Что важно, Envoy Gateway решает проблему Policy Gap в Gateway API через свои кастомизированные ресурсы Policy. BackendTrafficPolicy настраивает алгоритмы балансировки нагрузки, тайм-ауты соединений и Circuit Breaking. SecurityPolicy обрабатывает аутентификацию и настройки CORS — пользователи могут защищать API без развертывания отдельного Sidecar аутентификации. EnvoyPatchPolicy — это мощный аварийный люк: пользователи могут внедрять сырую конфигурацию Envoy в формате JSON непосредственно в xDS-поток, если им нужна расширенная функция, еще не представленная в Gateway API.

Contour: зрелый предшественник

Contour — это выпускной проект CNCF и один из первых Ingress-контроллеров, принявших Envoy. Изначально он определил свой собственный CRD под названием HTTPProxy, который стал первопроходцем многих концепций, теперь найденных в Gateway API, например делегирования маршрутов между неймспейсами.

Contour теперь поддерживает Gateway API наряду с HTTPProxy. Он маппит listeners Gateway на порты Envoy, которыми управляет. Однако Contour работает преимущественно как статический Provisioner: предполагает, что пул Envoy уже развернут, и управляет конфигурацией, а не динамически разворачивает новые Envoy Deployments на каждый ресурс Gateway, как Envoy Gateway.

Многие пользователи остаются на HTTPProxy, потому что он все еще поддерживает Edge-кейсы, которые Gateway API еще догоняет. Однако обязательство Contour — приоритизировать Gateway API для будущей разработки функций. Пользователям, мигрирующим на Contour сегодня, рекомендуется использовать ресурсы Gateway API и применять HTTPProxy только тогда, когда конкретная функция отсутствует в стандарте.

Конвергенция Service Mesh: Istio и Cilium

Граница между Ingress и Service Mesh растворяется. Gateway API — катализатор этой конвергенции: единый язык как для North-South, так и для East-West-трафика.

Istio: всеобъемлющая платформа

Istio полностью принял Gateway API; собственные API Gateway и VirtualService для задач Ingress теперь Deprecated в пользу стандарта.

Новый Ambient Mode Istio — это революционная архитектура, влияющая на то, как реализован Gateway API. В традиционном Sidecar Mode Envoy работает в каждом поде. В Ambient Mode легкий и разделяемый L4-прокси под названием ztunnel работает на каждой ноде и обрабатывает mTLS и TCP-маршрутизацию. Обработка L7 выгружается в Waypoint proxy — по сути, Envoy Gateway, развернутые на каждый Service Account.

Когда пользователь определяет Gateway в Istio Ambient, разворачивается Waypoint proxy. Этот прокси применяет политики HTTPRoute для трафика, входящего в Mesh или перемещающегося между сервисами. Значит, Gateway API теперь интерфейс для политики внутреннего трафика Mesh, а не только внешнего доступа.

Istio использует Gateway API для привязки своих мощных политик безопасности. AuthorizationPolicy может быть прикреплена к Gateway для гранулярного контроля доступа. Реализация строго безопасна и придерживается стандартов FIPS для шифрования по умолчанию — это отличает ее от Cilium, который полагается на WireGuard или IPsec.

В бенчмарках Istio стабильно в топе по эффективности Control Plane. Его способность распространять изменения маршрутов на Data Plane измеряется в миллисекундах — значительно быстрее Traefik или NGINX. В Ambient Mode накладные расходы Data Plane резко снижены, и это делает Istio наиболее масштабируемым вариантом для больших и динамичных окружений.

Cilium: Kernel-Native-претендент

Cilium подходит к Gateway API снизу вверх и расширяет свои возможности CNI. Реализация Gateway API в Cilium уникальна: это не отдельный контроллер, а встроенный в Cilium-Operator и Cilium-Agent. Когда создается Gateway, Cilium транслирует это в eBPF-карты для L4-маршрутизации и конфигурацию Envoy — для L7.

Cilium Agent работает на каждой ноде и управляет разделяемым инстансом Envoy. Это создает риск конкуренции за ресурсы: единственный шумный тенант на ноде теоретически мог бы истощить разделяемый инстанс Envoy и повлиять на весь L7-трафик на этой ноде. Это контрастирует с Envoy Gateway или Istio, которые могут разворачивать выделенные прокси на каждый Gateway.

Cilium превосходит по пропускной способности L4, но его реализация Gateway API показала хрупкость при масштабировании. Бенчмарки показывают: в условиях частых изменений маршрутов или высокой нагрузки на соединения Cilium может входить в состояния, когда трафик отбрасывается, и требовать перезапуска компонентов. Кроме того, в стресс-тестах загрузка процессора может превышать нагрузку Istio в 15 раз. Эти данные предполагают: Cilium мощен, но его архитектура может столкнуться с пределами масштабирования, которых нет у архитектур с выделенными прокси.

NGINX и Legacy-экосистема

NGINX Gateway Fabric: эволюция гиганта

NGINX Gateway Fabric запустили, чтобы заменить почтенный контроллер Ingress-NGINX. Это реализация с нуля: Control Plane переписан на Go для нативной поддержки Gateway API.

Проект сохраняет строгое разделение между OSS и коммерческими функциями. Версия OSS поддерживает стандартные HTTPRoute и GRPCRoute, используя оптимизированные перезагрузки конфигурации для обновлений. Версия NGINX Plus добавляет Enterprise-функции непосредственно в интеграцию Gateway: активные проверки работоспособности, валидацию JWT и Key-Value-хранилища для разделения состояния между репликами.

NGINX Gateway Fabric оптимизирован под высокую пропускную способность. NGINX как Data Plane невероятно эффективен в обслуживании статических ассетов и обработке высокого количества соединений с низким потреблением памяти. Однако Control Plane менее зрелый, чем у Istio. Наблюдалось, что он чувствителен к шуму в кластере и дает всплеск нагрузки на CPU, когда другие контроллеры вносят несвязанные изменения, — логика фильтрации событий еще оптимизируется.

Kong: платформа API Management

Kong рассматривает Gateway API как стандартизированную точку входа в свою более широкую экосистему API Management. Отличительная черта Kong — система плагинов. Стандартные поля Gateway API обрабатывают маршрутизацию, но Kong поощряет пользователей применять ресурсы KongPlugin, прикрепленные к Routes, для расширенной логики: трансформации, ограничения частоты запросов, логирования.

Kong дает глубокую кастомизацию через плагины на Lua. Это мощная возможность для организаций, которым нужно запускать сложную бизнес-логику на уровне шлюза. Однако у Kong самый широкий разрыв между OSS- и Enterprise-предложениями. Критические операционные функции — GUI, продвинутая аналитика, OIDC-плагины — доступны только в Enterprise. Для организаций, строго ищущих Open-Source-решение, это ограничение часто дисквалифицирует Kong в пользу Envoy Gateway, который включает OIDC и ограничение частоты запросов в своем бесплатном Open Core.

Матрица функций и соответствия

Бенчмарки и операционная реальность

Синтез данных из бенчмарк-наборов выявляет критические уровни производительности. Для L4-трафика Cilium не имеет равных. Для чистой передачи TCP/UDP-пакетов его eBPF-датапас обходит накладные расходы ядра и обеспечивает пропускную способность, ограниченную только аппаратным сетевым интерфейсом.

Для L7-трафика Istio Ambient и Envoy Gateway идут практически вровень. Удаление Sidecar в Ambient Mode устранило штраф за двойной Hop и снизило задержку Mesh до уровней, близких к Bare-Metal.

Update Latency — это скрытый убийца операций. Когда разработчик пушит маршрут, время, необходимое для его активации, варьируется. Istio и Kong распространяют изменения за миллисекунды, а изменения в NGINX Gateway Fabric и Traefik могут занимать секунды. Это накапливается в CI/CD-пайплайнах, развертывающих сотни сервисов.

Таблица ниже суммирует ключевые характеристики производительности, наблюдаемые во время стресс-тестирования.

Как выбрать: фреймворк под профиль нагрузки

На основе этого анализа предлагаем фреймворк принятия решений для корпоративного внедрения.

Искателю стандартизации рекомендуем Envoy Gateway. Для организаций, которым нужен чистый, Open-Source- и стандарт-совместимый Ingress без сложности Service Mesh, Envoy Gateway — оптимальный выбор. Он дает OIDC, ограничение частоты запросов и расширенную маршрутизацию «из коробки» без лицензионных платежей.

Архитектору Service Mesh рекомендуем Istio в Ambient Mode. Если в конечном счете цель — защитить East-West трафик, начните с Istio. Использование его для Gateway API сегодня плавно закладывает фундамент для mTLS и наблюдаемости завтра. Ambient Mode значительно снижает барьер входа: устраняет операционную головную боль управления Sidecar.

Инженеру «производительность любой ценой» рекомендуем Cilium. Если рабочая нагрузка доминируется L4-трафиком (стриминговые медиа или игровые серверы), eBPF Data Plane Cilium дает ощутимые преимущества. Однако будьте готовы к более крутому Learning Curve в отладке и потенциальным пределам масштабируемости L7.

Бизнесу монетизации API рекомендуем Kong Enterprise. Если шлюз — это продукт, генерирующий доход и требующий порталов для разработчиков, Kong Enterprise — единственный жизнеспособный кандидат в этом списке. Остальные — инфраструктурные шлюзы, тогда как Kong — это платформа API Marketplace.

Сильные и слабые стороны с одного взгляда

Чтобы дополнительно помочь в процессе принятия решений, приведем сводку ключевых сильных и слабых сторон каждой реализации для Production-окружений.