learninfra · Linux · Networking · Kubernetes · System Design · AI Infrastructure · Exam blueprints · Drills

Gateway API (CKA)

The successor to Ingress: a GatewayClass, a Gateway and HTTPRoutes, owned by different people, with traffic splitting built in.

An interactive Kubernetes lesson: 22 steps, about 32 minutes, on a live simulation in your browser.

The shop is served through an Ingress today: shop.example.com goes to the web Service, and the stream is green. Now the api team wants to release version 2 to ten percent of users first.

Ingress cannot express that. The spec covers hosts, paths and TLS, and stops. Everything else, including weights, header matching, rewrites and redirects, was left to annotations that each controller invents for itself. The ones on the right work on ingress-nginx and mean nothing to any other controller.

What you will learn

  1. Where Ingress runs out

    • Where Ingress runs out: Ingress standardised host and path. Everything beyond that lives in annotations that only one controller understands.

  2. Three objects, three owners

    • GatewayClass: who implements it: The Gateway API is a set of CRDs plus a controller you install. The GatewayClass says which controller answers.
    • Gateway: where traffic enters: A Gateway is the door: address, ports, protocols, certificates. It holds no routing rules.
    • HTTPRoute: where traffic goes: An HTTPRoute attaches to a Gateway with parentRefs, then routes: hostnames, matches, backendRefs.
    • Three owners: GatewayClass: the provider. Gateway: the platform team. HTTPRoute: the app team. Three kinds, so RBAC can keep them apart.
    • Drill: which class is installed?

  3. Matching requests

    • Two teams, one hostname: A Gateway merges all routes attached to it. For each request the most specific match wins, not the oldest route.
    • Matches and filters: matches decide which requests a rule takes. filters change the request. backendRefs say where it goes.
    • Ingress and Gateway API side by side

  4. Splitting traffic by weight

    • Version 2, running and unused
    • Send a tenth of the traffic to v2: Weights are proportions: a backend gets weight ÷ total. 90 and 10 is the same split as 9 and 1. Weight 0 gets nothing.
    • Break it: the canary crashes
    • Roll back, fix, promote: With a weighted route, shifting traffic means editing two numbers. Rollback is the same edit reversed, and no pod restarts.

  5. Namespaces and consent

    • A route from another namespace: A route attaching to a Gateway is a request. The Gateway's listener decides which namespaces it accepts routes from; the default is its own.
    • allowedRoutes: the Gateway's side: Attachment is a handshake: the route names the Gateway in parentRefs, and the Gateway admits the route's namespace in allowedRoutes.
    • ReferenceGrant: the target's side: A reference into another namespace needs the consent of that namespace's owner: a ReferenceGrant, created where the target lives.

  6. TLS and troubleshooting

    • TLS belongs to the listener: The certificate lives on the Gateway's listener, not on the route. App teams get HTTPS without ever holding the key.
    • Break it: the controller is gone
    • Read the status conditions: Accepted: the parent took it. Programmed: the proxy is configured. ResolvedRefs: the backends exist and are permitted. Read these before you curl.
    • Drill: why is my route not working?

  7. Recap & playground

    • Cheat sheet
    • Playground