Gateway API против Ingress: как выбрать реализацию и не пожалеть

Значимый прорыв формирует отрасль ИИ: roman_timoshevskiy 51 минуту назад Gateway API против Ingress: как выбрать реализацию и не пожалеть Средний 13 мин 940 Блог компании Data Sapience DevOps * Kubernetes * Системное администрирование * IT-инфраструктура * Аналитика Привет, Хабр! Меня зовут Роман Тимошевский, и я являюсь лидом команды 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.

io/* аннотаций — это не переносимая конфигурация, а проприетарный конфиг NGINX, замаскированный под стандартный объект Kubernetes. Переезд на другой контроллер означает переписывание всего. Вторая проблема — отсутствие разделения ролей.

Отраслевые последствия

В Ingress всё свалено в один объект: и инфраструктурная часть (порты, TLS, IP), и прикладная (маршруты, пути). Это значит, что разработчик приложения и платформенная команда работают с одним и тем же ресурсом, что порождает конфликты прав и ответственности. Gateway API проектировался именно как ответ на эти две боли.

Что такое Gateway API концептуальноGateway API — это не контроллер, а набор CRD и спецификация поведения, развиваемые в рамках SIG-Network. Ключевая идея — разделение ответственности через несколько ресурсов:Архитектурная схема компонентов Gateway APIАрхитектурная схема компонентов Gateway API:GatewayClass — аналог StorageClass. Определяет, какая реализация (контроллер) будет обрабатывать Gateway.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.