How Does Gateway API Compare to Ingress?

Q: How Does Gateway API Compare to Ingress?

Gateway API is the successor to Ingress, offering a more expressive, role-oriented, and extensible routing model. It separates infrastructure concerns (GatewayClass, Gateway) from application routing (HTTPRoute), supports TCP/UDP/gRPC natively, and eliminates the need for controller-specific annotations.

Detailed Answer

The Gateway API is the next generation of Kubernetes service networking, designed to overcome the limitations of Ingress. It provides a more expressive, portable, and role-oriented way to configure traffic routing.

Why Ingress Needed a Successor

Ingress has served Kubernetes well, but has fundamental limitations:

Annotation sprawl: Advanced features require controller-specific annotations that are not portable
HTTP-only: No native support for TCP, UDP, or gRPC
Flat model: No separation between infrastructure and application concerns
Limited extensibility: Adding new features requires new annotations or CRDs per controller

Gateway API Resource Model

Gateway API introduces three resource layers:

GatewayClass  → Infrastructure provider defines the type (managed by provider)
    └── Gateway  → Cluster operator configures the listener (managed by ops)
          └── HTTPRoute  → Developer defines routing rules (managed by dev)

GatewayClass (Infrastructure Provider)

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: cloud-lb
spec:
  controllerName: example.com/gateway-controller

Gateway (Cluster Operator)

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: infra
spec:
  gatewayClassName: cloud-lb
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-tls
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"
    - name: http
      protocol: HTTP
      port: 80

HTTPRoute (Application Developer)

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-routes
  namespace: app-team
spec:
  parentRefs:
    - name: production-gateway
      namespace: infra
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api-v1
          port: 80
          weight: 90
        - name: api-v2
          port: 80
          weight: 10
    - matches:
        - path:
            type: PathPrefix
            value: /v2
      backendRefs:
        - name: api-v2
          port: 80

Comparison: Ingress vs Gateway API

| Feature | Ingress | Gateway API | |---|---|---| | Protocols | HTTP/HTTPS only | HTTP, HTTPS, TCP, UDP, gRPC, TLS | | Traffic splitting | Via annotations (non-portable) | Native weighted backendRefs | | Header-based routing | Via annotations | Native match rules | | Role separation | None | GatewayClass / Gateway / Route | | Cross-namespace routing | No | Yes, with explicit grants | | Extensibility | Annotations | ExtensionRefs, Policy objects | | Portability | Low (annotation-dependent) | High (standardized API) |

Key Advantages of Gateway API

1. Traffic Splitting (Canary/Blue-Green)

rules:
  - backendRefs:
      - name: app-v1
        port: 80
        weight: 90    # 90% of traffic
      - name: app-v2
        port: 80
        weight: 10    # 10% of traffic

This is a first-class feature — no annotations needed.

2. Header-Based Routing

rules:
  - matches:
      - headers:
          - type: Exact
            name: x-canary
            value: "true"
    backendRefs:
      - name: canary-service
        port: 80

3. Cross-Namespace Routing

Application teams can attach routes to a shared Gateway in a different namespace:

spec:
  parentRefs:
    - name: shared-gateway
      namespace: infra         # Gateway in infra namespace
      sectionName: https       # Specific listener

4. TCP and UDP Routing

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: database-route
spec:
  parentRefs:
    - name: tcp-gateway
  rules:
    - backendRefs:
        - name: database-service
          port: 5432

When to Use Which

| Situation | Recommendation | |---|---| | New cluster, greenfield project | Gateway API | | Existing cluster with Ingress working fine | Stay with Ingress, plan migration | | Need TCP/UDP routing | Gateway API | | Need traffic splitting | Gateway API | | Need cross-namespace routing | Gateway API | | Simple HTTP routing only | Either works | | Controller does not support Gateway API | Ingress |