Ingress vs Gateway API: выбор и migration

Если Gateway API лучше во всём, зачем держать Ingress? Если Ingress работает, зачем мигрировать на Gateway API? На 2026 правильный ответ — держать оба и понимать, когда какой использовать. Ingress остаётся, Gateway API — дополняет, не заменяет.

Этот урок — про практический выбор и migration paths.

Side-by-side сравнение

Когда что использовать

Используйте Ingress, если:

• Существующий setup работает, нет проблем — не надо чинить то, что не сломано
• Только HTTP/HTTPS workloads, простые routing-правила
• Команда уже знает Ingress, экспертиза вокруг nginx annotations
• Кластер ограничен ресурсами и не хочется устанавливать дополнительные CRD и controllers
• На CKAD-экзамене — ваше main expertise должно быть в Ingress

Используйте Gateway API, если:

• Новый проект, greenfield
• Нужен L4 routing (TCP/UDP — БД, MQ, kafka, custom protocols)
• Нужен gRPC routing с матчингом по service/method
• Нужно cross-namespace routing (платформа в одном NS, app в другом)
• Хотите native canary deployments через weight
• Несколько команд делят Ingress controller и наступают друг другу на ноги — нужен role separation
• Хочется уйти от vendor lock-in через annotations

Используйте оба, если:

• В кластере legacy Ingress, новые проекты пишут на Gateway API. Контроллеры могут поддерживать оба одновременно (ingress-nginx, Istio, Cilium).

Где Gateway API ощутимо лучше

1. Canary deployments без annotations

Ingress (с nginx canary annotations):

# Стабильный Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-stable
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: api-v1, port: { number: 80 } }
---
# Canary через annotations (nginx-specific)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: api-v2, port: { number: 80 } }

Два Ingress, vendor-specific аннотации, работает только в nginx.

Gateway API:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs: [{ name: gateway }]
  hostnames: [api.example.com]
  rules:
    - backendRefs:
        - { name: api-v1, port: 80, weight: 90 }
        - { name: api-v2, port: 80, weight: 10 }

Один объект, native поле weight, портативно между controllers.

2. L4 routing

Ingress: не умеет TCP/UDP. Приходится использовать Service type: LoadBalancer (дорого) или костыли вроде tcp-services-configmap в ingress-nginx (vendor-specific).

Gateway API:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: tcp-gateway
spec:
  listeners:
    - name: postgres
      port: 5432
      protocol: TCP
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: postgres
spec:
  parentRefs: [{ name: tcp-gateway, sectionName: postgres }]
  rules:
    - backendRefs: [{ name: postgres, port: 5432 }]

Один Gateway на множество TCP-сервисов, native поддержка.

3. gRPC

Ingress: для gRPC нужны annotations вида nginx.ingress.kubernetes.io/backend-protocol: GRPC, и матчинг только по path.

Gateway API: GRPCRoute с матчингом по proto service/method:

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: orders
spec:
  parentRefs: [{ name: gateway }]
  rules:
    - matches:
        - method:
            service: order.OrderService
            method: ListOrders
      backendRefs:
        - { name: orders-grpc, port: 50051 }

4. Cross-namespace TLS

Ingress: TLS Secret должен быть в том же namespace что Ingress. Это вынуждает либо дублировать Secret в каждом namespace, либо ставить Ingress в shared namespace.

Gateway API: через ReferenceGrant платформенная команда держит cert в platform namespace, app teams ссылаются:

spec:
  listeners:
    - name: https
      tls:
        certificateRefs:
          - name: wildcard-tls
            namespace: platform   # cross-NS!

Где Gateway API НЕ лучше (или хуже)

1. Installation overhead

Gateway API — это CRDs, которые надо ставить отдельно. Ingress — встроен. Для маленьких кластеров overhead не оправдан.

2. Ecosystem maturity

cert-manager поддерживает Gateway API, но его annotation-based интеграция с Ingress отшлифована за годы. Многие helm charts (например, Bitnami) генерируют Ingress объекты, не Gateway API.

3. Learning curve

Три объекта вместо одного, ReferenceGrant, allowedRoutes — больше понятий. Для приложения с одним Ingress это overkill.

4. Tooling

kubectl ingress для создания imperative ingress на экзамене — быстрый шорткат. Аналогичной короткой команды для HTTPRoute пока нет.

Migration paths

Если у вас Ingress в production и есть желание мигрировать на Gateway API — несколько паттернов.

Pattern 1: Параллельная работа (recommended)

Оставить старые Ingress как есть. Новые приложения писать на Gateway API. Со временем — постепенно мигрировать старые когда туда всё равно вносятся изменения.

# Параллельно работают:
kubectl get ingress -A         # legacy
kubectl get httproute -A       # new

Большинство controllers (ingress-nginx, Istio, Cilium) поддерживают оба одновременно. Routing-правила не конфликтуют — у них разные API objects.

Pattern 2: Auto-translation tools

Есть инструменты, которые автоматически конвертируют Ingress → HTTPRoute:

• ingress2gateway — open-source CLI (kubernetes-sigs/ingress2gateway). Читает Ingress объекты, генерирует Gateway + HTTPRoute YAML.

ingress2gateway print --namespace=default
# Выведет HTTPRoute + Gateway YAML

Покрывает базовые случаи. Annotations не транслируются (т.к. они vendor-specific) — это придётся переписать вручную в filters.

Pattern 3: Strangler fig pattern

Поднять Gateway API параллельно с Ingress. Постепенно перенаправлять trafic с Ingress на Gateway API через DNS или header-routing. Когда весь трафик ушёл — удалить Ingress.

1. Старт: 100% trafic → Ingress → backend
2. Добавляем HTTPRoute → backend (тот же)
3. DNS делим: api.example.com → Ingress LB (NS1), api-new.example.com → Gateway LB (NS2)
4. Постепенно meadow.example.com → Gateway
5. Финал: удаляем Ingress

Controllers, поддерживающие оба

CKAD-перспектива

На экзамене встретится Ingress чаще, чем Gateway API. Curriculum v1.33 явно упоминает Gateway API, но в задачах исторически Ingress доминирует. Стратегия:

• Глубоко знать Ingress: kubectl create ingress шорткат, host/path/pathType, TLS Secret тип kubernetes.io/tls, ingressClassName, longest-match алгоритм.
• Концептуально знать Gateway API: три объекта, parentRefs, простой HTTPRoute. Уметь прочитать YAML.

Типовые задачи:

# Ingress (вероятный вопрос)
kubectl create ingress web --class=nginx \
  --rule='app.example.com/api*=api:80' \
  --rule='app.example.com/web*=web:80'

# Gateway API (менее вероятный, но возможный)
# Создать HTTPRoute, attach к существующему Gateway
cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs: [{ name: gateway, namespace: infra }]
  hostnames: [api.example.com]
  rules:
    - matches: [{ path: { type: PathPrefix, value: /v1 } }]
      backendRefs: [{ name: api-v1, port: 80 }]
EOF

Future: куда движется ecosystem

На 2026:

1. Gateway API растёт быстрее Ingress в новых проектах и Cloud-managed offering
2. Service mesh (Istio, Linkerd, Cilium) использует Gateway API как стандартный entry point — постепенно service mesh и Gateway API сливаются
3. Multi-cluster routing — Gateway API планирует extension для cross-cluster routing (alpha)
4. GAMMA initiative — service-to-service traffic (раньше делалось через mesh-specific objects) тоже идёт через Gateway API
5. Ingress остаётся stable, но новые фичи там не добавляются. Это maintenance mode.

То есть в долгосрочной перспективе Gateway API заменит Ingress, но это процесс на 5-10 лет, не на год.

Принятие решения: чек-лист

Какой API использовать для нового проекта?

1. Нужен L4 (TCP/UDP) routing?
   - Да → Gateway API
   - Нет → шаг 2

2. Нужен native gRPC routing?
   - Да → Gateway API
   - Нет → шаг 3

3. Несколько teams делят routing инфраструктуру?
   - Да → Gateway API (role separation)
   - Нет → шаг 4

4. Cross-namespace TLS или backend Service?
   - Да → Gateway API
   - Нет → шаг 5

5. Команда уже знает Ingress, нет времени учить новое?
   - Да → Ingress
   - Нет → шаг 6

6. Хочется минимизировать vendor lock-in?
   - Да → Gateway API
   - Нет → Ingress (тоже ОК для простых случаев)

Для 90% простых веб-приложений — Ingress нормально работает. Gateway API нужен когда упираетесь в его ограничения.

Summary

Ingress:

• Простой, стабильный, везде работает
• Хорошо для HTTP/HTTPS workloads с базовыми annotations
• Идеален для CKAD-экзамена и большинства production setup

Gateway API:

• Современный, выразительный, портативный
• Решает реальные проблемы: L4, gRPC, role separation, cross-NS
• Будущее routing API в Kubernetes
• Стоит изучить, чтобы быть готовым на горизонте 2-5 лет

Практика:

• В production: оба могут жить параллельно
• В новых проектах: рассмотрите Gateway API, особенно если нужны его фичи
• В legacy: оставляйте Ingress, мигрируйте постепенно при необходимости