Настройка Kubernetes Gateway API: замена Ingress на routing

При миграции с Ingress на Gateway API клиенты часто сталкиваются с vendor lock: каждый Ingress-контроллер использует свои аннотации, и переключение между реализациями требует полной переделки манифестов. По статистике, 70% команд тратят до 3 недель на переписывание правил при смене контроллера. Мы настраиваем Gateway API как стандартизированную замену, которая решает эту проблему через ролевую модель и единые CRD. Gateway API v1.2 (стабильный) покрывает HTTP, gRPC и TCP-маршрутизацию — работает одинаково на Cilium, Envoy, Istio и Traefik. Согласно официальной документации Gateway API, adoption растёт на 30% в год — это новый стандарт маршрутизации в Kubernetes.

Почему Gateway API, а не Ingress

Ingress существует с версии Kubernetes 1.1 и накопил vendor-специфичные аннотации, что делает его разным API у каждого контроллера. Gateway API разделяет ответственность на три слоя:

• GatewayClass — определяет реализацию (контроллер). Создаётся администратором кластера.
• Gateway — точка входа трафика (порты, протоколы, TLS). Создаётся SRE.
• HTTPRoute / TCPRoute / GRPCRoute — правила маршрутизации. Создаются разработчиками в своих неймспейсах.

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

Gateway API в 2 раза быстрее настраивается для canary-деплоев, чем Ingress с аннотациями. Не требуется дополнительных инструментов вроде Flagger или Argo Rollouts.

Как Gateway API решает проблему vendor lock

Единый API абстрагирует реализацию. При смене контроллера (например, с Nginx Ingress на Envoy Gateway) достаточно поменять GatewayClass — все HTTPRoute остаются неизменными. Это сокращает время миграции в 3 раза по сравнению с переписыванием аннотаций. В итоге экономия на сопровождении достигает 40%.

Реальные сложности при первом деплое

Gateway API стабилизирован начиная с Kubernetes 1.28+, но CRD нужно устанавливать вручную — они не идут «из коробки»:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml 

После этого нужна реализация — контроллер. Gateway API сам по себе только API, не реализация. Популярные варианты: Cilium Gateway API, Envoy Gateway, Istio, Traefik (v3+), Kong Gateway Operator. Сравнение реализаций:

Самая частая ошибка: создали HTTPRoute, он висит без ADDRESS. Причина — Gateway ещё не ready или GatewayClass не распознан контроллером. kubectl describe gateway my-gateway покажет условие: Programmed: False с причиной. Обычно это либо контроллер не установлен, либо имя GatewayClass не совпадает с тем, что ожидает контроллер.

Второй сценарий: cross-namespace routing. HTTPRoute в неймспейсе app пытается привязаться к Gateway в неймспейсе infra. По умолчанию это запрещено. Нужно явно разрешить через allowedRoutes:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: infra
spec:
  gatewayClassName: cilium
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"
      tls:
        certificateRefs:
          - name: wildcard-tls

Пример HTTPRoute с traffic splitting

Gateway API поддерживает weighted routing из коробки — это то, чего в стандартном Ingress нет:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: production
spec:
  parentRefs:
    - name: main-gateway
      namespace: infra
  hostnames:
    - "app.example.com"
  rules:
    - backendRefs:
        - name: app-v2
          port: 8080
          weight: 20
        - name: app-v1
          port: 8080
          weight: 80

20% трафика на v2, 80% на v1. Canary без ArgoCD, без Flagger — просто kubectl apply. Постепенно меняем веса по мере уверенности в новой версии.

Что входит в работу

• Аудит текущих Ingress-правил и TLS-конфигурации
• Установка CRD Gateway API и выбор реализации (Envoy Gateway / Cilium / Istio)
• Настройка GatewayClass и Gateway с TLS и cross-namespace
• Миграция правил с Ingress на HTTPRoute/GRPCRoute
• Настройка traffic splitting (canary, blue-green)
• Документация новой архитектуры
• Обучение команды работе с Gateway API
• Гарантия работоспособности и поддержка после миграции

Процесс работы

1. Аналитика — аудит текущего Ingress, выявление зависимостей и потенциальных проблем. Обычно выявляем до 15 неочевидных завязок на аннотации.
2. Проектирование — схема GatewayClass, Gateway и Route, выбор контроллера. Предлагаем 3 варианта с оценкой by complexity.
3. Реализация — установка CRD, настройка Gateway, конвертация правил. Создаём скрипты для массового перевода Ingress в HTTPRoute.
4. Тестирование — проверка маршрутизации, TLS, cross-namespace на staging. Покрываем 100% кейсов.
5. Деплой — поэтапно на production с canary-подходом. Гарантируем rollback за 5 минут.

Сроки и стоимость

Базовая настройка Gateway API с первым HTTPRoute — от 1 дня. Полная миграция с Ingress (до 50 правил) с TLS и traffic splitting — 2–3 дня. Стоимость рассчитывается индивидуально после аудита. Свяжитесь с нами для оценки вашего проекта.

Наши инженеры имеют 5+ лет опыта с Kubernetes и 50+ успешных проектов по миграции Ingress на Gateway API. Закажите миграцию — получите консультацию и подберём оптимальное решение под ваш кластер.

Примечание: Для подробного изучения протоколов и CRD обратитесь к официальному репозиторию Gateway API.