The API that takes ownership seriously
The best thing about the Kubernetes Gateway API isn’t a new feature. It’s the answer to a question the old APIs never asked: Who owns this?
- Date
- Topic
- Gateway-api
- Sources
- 6
- Reading time
- 3 min
- Version
- Translation
In report #27 the Gateway API was stage zero ahead of the move to Ambient. But it pays off even without that move.
Figure as text
Diagram of the three Gateway API resources as a stack with their owners: GatewayClass (infrastructure, which implementation runs), Gateway (platform team: Listener, ports, TLS and the allowedRoutes bar) and HTTPRoute (application team). An HTTPRoute from the namespace team-a attaches to the Gateway via parentRef and is accepted (Accepted: True), a route from another namespace ends at the allowedRoutes bar (Accepted: False). Next to it three consequences: by default only the Gateway's own namespace, every namespace boundary needs the consent of both sides, the boundary can be read with kubectl. Below, two boxes: the handshake (the route names the Gateway via parentRef, the Gateway admits it via allowedRoutes) and the honest part (the lock only holds if RBAC plays along; anyone who may create Gateways or VirtualServices walks past it). Punchline: The organizational question lives in the API server, not in the wiki.
A VirtualService describes the routing. By default, how far the VS reaches is decided by its author: mesh-wide unless stated otherwise (report #5). Until now, ownership was only ever a note on the door, not a door with a lock: convention plus levers that someone has to pull first (report #6).
The Gateway API builds the boundary into the API design itself. Three resources, three owners:
GatewayClass belongs to infrastructure: which implementation is run at all.
Gateway belongs to the platform team: Listener, ports, TLS. And the decisive line: allowedRoutes.
HTTPRoute belongs to the application team, in its own namespace.
A route attaches to a Gateway via parentRef. Whether it takes effect there is decided by the Gateway’s owner through allowedRoutes: from which namespaces, with which route types. The default only admits the Gateway’s own namespace. The docs call this a handshake: every namespace boundary needs the consent of both sides. A policy engine no longer has to rebuild this boundary, it sits directly in the object model.
We know this from earlier reports: local effect belongs to the team, mesh-wide effect to the platform (reports #4 and #6). The redirect pattern from report #5, a tenant hijacking someone else’s traffic, becomes structurally harder: at the Gateway, a route only takes effect where someone has allowed it to attach. If it attaches directly to someone else’s Service in the mesh, it only applies to calls from its own namespace.
The honest part: the lock only holds if RBAC plays along. Anyone who may create Gateways builds their own entrance anyway. Anyone who may still write VirtualServices still holds the pattern from report #5, so the levers from report #6 remain mandatory there. And on a shared Listener, several teams can claim the same hostname. A Listener per hostname or a suitable admission policy settles that.
For decision makers this means: the ownership question that otherwise escalates in operations meetings is a property of the API here. Less policy glue that needs maintaining, and the actual boundary can simply be read with kubectl.
For the first time, the organizational question lives directly in the API server rather than in the wiki.
According to its own docs, Istio intends to make the Gateway API the default API for traffic management in the future. What it takes to move a grown VirtualService estate there comes next week. TL;DR: more than the usual mapping tables promise.
