Q24: Ingress Controllers vs. Kubernetes Gateway API: Architecture, TLS termination, and traffic routing. - DevOps & Kubernetes (50 Qs)

Evolution: Ingress vs. Gateway API

While standard Ingress provided basic Layer 7 HTTP routing, its monolithic specification forced cloud vendors to rely on brittle, non-standard annotations. The Gateway API is the next-generation standard designed with role-oriented separation of concerns.

sql

Ingress (Monolithic):
[ Ingress Resource ] -> Combines routing rules, TLS, annotations, and controller bindings into one file.

Gateway API (Role-Oriented Separation):
+------------------------------------+
| GatewayClass (Infra Provider)      | -> Defines controller implementation (e.g., Envoy, Cilium)
+------------------------------------+
                  |
                  v
+------------------------------------+
| Gateway (Cluster Operator / DevOps)| -> Defines IP, TLS certificates, and listener ports (443, 80)
+------------------------------------+
                  |
                  v
+------------------------------------+
| HTTPRoute (Application Developer)  | -> Defines path matching, canary weights, headers, rewrites
+------------------------------------+

Canary Deployment with Gateway API (Traffic Weight Splitting)

Unlike standard Ingress which required complex NGINX annotations, Gateway API natively supports percentage-based traffic splitting:

yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-canary
spec:
  parentRefs:
    - name: production-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v1
      backendRefs:
        - name: api-stable
          port: 8080
          weight: 90 # 90% traffic to stable version
        - name: api-canary
          port: 8080
          weight: 10 # 10% canary traffic