Topic 9.4
Gateway API: The Successor to Ingress
In one line
Gateway API splits traffic configuration by role (GatewayClass, Gateway, HTTPRoute), supports traffic splitting and header matching natively, and works across implementations, fixing Ingress's annotation sprawl.
Think of it like this
An airport. The airport authority builds terminals (GatewayClass/infrastructure), the terminal manager decides which gates exist and who may use them (Gateway), and each airline configures its own flights to gates (HTTPRoutes). Nobody edits another team's settings.
Key ideas
- 01
RESOURCES:
GatewayClass(which implementation: Envoy Gateway, Istio, Cilium, NGINX Gateway Fabric, AWS/GKE controllers),Gateway(listeners: ports, protocols, hostnames, TLS certificates, and which namespaces may attach routes), and routes:HTTPRoute,GRPCRoute,TLSRoute,TCPRoute. Routes in app namespaces attach to a shared Gateway viaparentRefs. - 02
FEATURES in the standard (no annotations): path, header, and query matching; weighted
backendRefsfor canaries (90/10 splits); request/response header modification; redirects and URL rewrites; request mirroring; timeouts. Cross-namespace references require an explicitReferenceGrant. - 03
Why it matters: Ingress mixed infrastructure and app concerns in one object and pushed everything else into controller-specific annotations (Phase 3). The popular Ingress-NGINX controller is being retired, so new clusters should start with Gateway API (Platform Engineering course, Mission 0.2 builds a full setup with cert-manager and ExternalDNS).
Code & diagrams
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: checkout, namespace: checkout }
spec:
parentRefs: [{ name: shop-gw, namespace: gateway }]
hostnames: ["checkout.shoplite.dev"]
rules:
- matches: [{ headers: [{ name: x-beta, value: "true" }] }]
backendRefs: [{ name: checkout-v2, port: 80 }] # beta testers → v2
- backendRefs:
- { name: checkout-v1, port: 80, weight: 90 }
- { name: checkout-v2, port: 80, weight: 10 } # 10% canaryExplain it without notes
What problem does the Gateway/Route split solve compared with Ingress?
Practice
Migrate an Ingress with two paths (/api → api service, / → web service) and TLS to Gateway API.
Done when you can
I can write Gateways and HTTPRoutes with matches and weights
I can explain Gateway API's role model