Gateway API
How does Gateway API decide whether a route may use a shared entry point? A GatewayClass names the implementation, a Gateway in the operator namespace admits routes only from its own namespace by default, and an HTTPRoute from another namespace is not Accepted until a listener allowedRoutes admits its namespace. A backendRef into a third namespace also needs a ReferenceGrant there, and until then a rule with no filters and only that backend returns HTTP 500.
Play the animation 6 steps, animated, best on a wide screen
Gateway API, step by step
-
Gateway API is an add-on whose kinds are custom resources. The cluster-scoped GatewayClass example names the controller that implements it in controllerName, and reads Accepted True once that controller takes it. Gateway shared-gw in namespace infra uses that class and declares an HTTPS listener on 443 with its certificate in certificateRefs. Its allowedRoutes keeps the default, from Same, and here the implementation runs a proxy for the Gateway.
Play from step 1 -
HTTPRoute web is created in namespace shop: parentRefs names shared-gw, and one rule sends shop.io/ to Service web in namespace web. The listener admits routes from infra alone, so the route reads Accepted False, reason NotAllowedByListeners.
Play from step 2 -
Gateway shared-gw is edited: allowedRoutes becomes from Selector, matching namespace shop, and the route turns Accepted True. Its backendRef points into namespace web, where no ReferenceGrant allows it, so ResolvedRefs reads False, reason RefNotPermitted, and the implementation configures no backend for the rule.
Play from step 3 -
A client sends HTTPS for shop.io/ to the Gateway address. The proxy terminates TLS and matches the accepted rule, but the only backendRef of that rule is invalid and the rule has no filters, so the request must get HTTP 500 instead of being forwarded.
Play from step 4 -
ReferenceGrant from-shop is created in namespace web, allowing HTTPRoutes in namespace shop to reference its Services. The backendRef resolves and ResolvedRefs turns True, so the rule now has a backend: Service web, which selects Pod web.
Play from step 5 -
The same request now matches Host and path against a configuration built from the Gateway and the HTTPRoute, and the rule has a backend. An implementation may send it to the Service IP or to the backing EndpointSlices, and here the proxy forwards straight to Pod web at 10.244.1.5.
Play from step 6