Налаштування Kubernetes Gateway API: заміна Ingress на стандартизований маршрутизатор

При міграції з 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.