TCPRoute lands cleanly in Gateway API v1.6
Gateway API v1.6.0 promotes TCPRoute and UDPRoute to Standard in the gateway.networking.k8s.io/v1 API group. The older v1alpha2 forms are deprecated and will go in a future release, so the new shape is the one to use for long-lived manifests.
The useful part is not the new badge on the API. It is the portability. Raw TCP and UDP workloads now have a controller-neutral attachment model, instead of depending on whatever a given Gateway implementation felt like shipping that month.
Listener attachment still decides who gets in
A route does nothing until a Gateway listener allows it. For TCP, the listener needs protocol: TCP, a port, and allowedRoutes.kinds that includes TCPRoute. UDP uses the same pattern with UDPRoute.
That gate matters because attachment is explicit. A TCPRoute can point at a Gateway, but if the listener does not permit that kind, it stays out. A route can also omit sectionName and port in parentRefs, which attaches it to every TCP listener on that Gateway. Handy, if broad attachment is what you intended. Dangerous, if it was not.
The routing model stops at protocol and port
TCPRoute and UDPRoute do not inspect payloads, headers, or anything else people sometimes wish raw L4 routing could magically infer. Traffic is forwarded based on protocol and port alone. That keeps the model simple and predictable, but it also means there is no pretending this is HTTP routing wearing a fake moustache.
The backend side is just as spare. backendRefs point at a Service and a port, such as a route on Gateway port 12345 proxying to my-foo-service endpoints on port 6000. That is the whole game: listener attachment on one side, backend forwarding on the other.
Parent refs and backend refs do the actual work
parentRefs decides which Gateway listener a route attaches to. backendRefs decides which Service and port receive traffic. The two together define the path, and neither one has much room for creative interpretation.
That lack of creativity is useful. It avoids the odd edge cases that come with trying to squeeze Layer 7 assumptions into Layer 4 traffic. TCP connections stay TCP connections. UDP datagrams stay UDP datagrams. The controller does not need to guess intent from bytes it cannot parse.
UDPRoute follows the same shape without pretending to be HTTP
UDPRoute uses the same listener attachment and backend forwarding pattern as TCPRoute. The API does not bolt on extra semantics just to look familiar. That is the right call for L4 routing, where the controller only needs to know where the traffic came from and where it should go next.
For clusters already using GatewayClass-based service networking, this is the clean boundary. Gateways manage attachment, listeners control what can bind, and routes forward to Service ports without dragging in L7 behaviour. The result is not fancy, but it is portable, and that is usually what people wanted in the first place.
