Как выбрать между Ingress API и Gateway API для крупной мультиарендной платформы, и какие здесь компромиссы?

Короткий ответ

Однозначно лучшего выбора нет: Ingress API проще, широко поддержан и достаточен для базовой HTTP-маршрутизации, тогда как Gateway API даёт более выразительную ролевую модель (разделение ответственности между администратором инфраструктуры, владельцем Gateway и командами, управляющими маршрутами) и более богатые возможности маршрутизации (включая TCP/UDP, продвинутый traffic splitting), но требует перехода на новую, менее давно устоявшуюся экосистему и зависит от зрелости её поддержки у выбранного Ingress-контроллера/провайдера.

Как это работает подробнее

Ingress API исторически ограничен HTTP/HTTPS-маршрутизацией и полагается на нестандартизированные аннотации конкретного контроллера для любой продвинутой функциональности (rate limiting, canary, rewrite правила), что делает конфигурацию менее портируемой между разными реализациями контроллеров. Gateway API вводит отдельные ресурсы с чётким разделением ролей (GatewayClass/Gateway — управляется платформенной командой, HTTPRoute/TCPRoute и т.п. — управляется командами приложений), стандартизируя продвинутые возможности маршрутизации без необходимости в proprietary-аннотациях.

• Компромисс. внедрение Gateway API оправдано, когда реальная сложность платформы (много команд, много разных типов трафика, потребность в продвинутой маршрутизации) уже упирается в ограничения Ingress и proprietary-аннотаций; для меньших платформ с простыми требованиями к маршрутизации переход может добавить сложность без ощутимой выгоды — решение стоит принимать с учётом конкретной зрелости используемого контроллера, стоимости миграции существующих Ingress-манифестов и реальной потребности в ролевом разделении, а не исходя из того, что Gateway API "более новый" стандарт.

Пример кода

manifest.yamlКопировать

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: checkout-route, namespace: team-checkout }
spec:
  parentRefs: [{ name: shared-gateway, namespace: platform }]
  rules:
    - matches: [{ path: { type: PathPrefix, value: "/checkout" } }]
      backendRefs: [{ name: checkout, port: 8080 }]

Что использовать на практике

• Практика. для мультиарендной платформы с чётким разделением "платформенная команда управляет точкой входа, продуктовые команды управляют своими маршрутами" ролевая модель Gateway API концептуально точнее отражает реальное разделение ответственности, чем плоская модель Ingress, где подобное разделение приходится имитировать через RBAC и соглашения. Переход, однако, требует, чтобы используемый Ingress-контроллер (или отдельный Gateway-контроллер) поддерживал Gateway API на нужном уровне зрелости, и может потребовать параллельной поддержки обоих API на время миграции существующих маршрутов.

Подводные камни

• Риски. частая ошибка — называть Gateway API безусловно лучшим выбором только потому, что он новее стандарт, не проверив уровень его поддержки у конкретного используемого контроллера; также кандидаты иногда путают роли Gateway/GatewayClass и HTTPRoute с обычным объектом Ingress, не видя заложенного разделения ответственности.