Gateway API v1.6 graduates TCPRoute and UDPRoute to the stable v1 API, giving Kubernetes a portable way to route raw TCP and UDP traffic through Gateways. The release also introduces a new experimental API group, gateway.networking.x-k8s.io, with X-prefixed resource names to make the experimental versus standard boundary explicit.
TCPRoute and UDPRoute reach GA for layer 4 workloads
Until this release, Gateway API offered stable routing only for HTTP and TLS traffic at layer 7. Workloads that speak raw protocols — databases, DNS, VoIP, gaming, IoT telemetry — had to fall back to plain Kubernetes Services or implementation-specific CRDs that did not travel between Gateway controllers. TCPRoute and UDPRoute close that gap by routing traffic based on protocol and port alone, with no layer 7 awareness required.
Both resources have moved from the Experimental channel to Standard and now live in the gateway.networking.k8s.io/v1 API group. The previous v1alpha2 versions were deprecated as of v1.6 and will be removed in a future release. A Gateway listener must declare protocol TCP or UDP and explicitly allow the corresponding route kind in its allowedRoutes section before a route can attach.
A TCPRoute example shows a Gateway listener on port 12345 with protocol TCP allowing TCPRoute attachment. The route references that listener by name and sectionName, then forwards traffic to a backend Service named my-foo-service on port 6000. UDPRoute follows the identical pattern, swapping the listener protocol to UDP and the route kind to UDPRoute. Omitting sectionName and port from parentRefs attaches the route to every matching listener on the Gateway.
XBackend arrives as an experimental decorator for backends
Gateway API v1.6 introduces XBackend in the new experimental group gateway.networking.x-k8s.io/v1alpha1. The resource acts as a general-purpose decorator for Service and other backend types, built on ideas from the upstream EndpointSelector KEP. It allows the community to extend backend configuration with use cases that are difficult or dangerous to handle with the stable Service resource, whose flexibility creates edge cases and whose stability blocks new concepts.
The first version of XBackend supports ExternalHostname destinations, which are ruled out from Service support in Gateway API because of confused deputy attack risks. For XBackend, this support is an Extended or Optional feature, letting implementations and users opt in once they understand the security tradeoffs. This capability is especially useful for egress scenarios such as cluster-hosted agentic workloads calling external AI APIs.
An example shows an HTTPS Gateway listener with TLS termination, an XBackend of type ExternalHostname pointing to api.ai-provider.com, and an HTTPRoute that references the XBackend by name, kind, and group. The community is also working on moving session persistence, retries, TLS origination, and similar per-application configuration from XBackendTrafficPolicy into XBackend. The XBackend API is experimental and its behavior can change; it is not ready for production.
Experimental resources move to a separate API group
Previously, experimental resources shared the standard gateway.networking.k8s.io API group and were distinguished only by alpha version strings such as v1alpha2. TCPRoute and UDPRoute were the last resources to graduate under that scheme. Going forward, new experimental resources are defined in gateway.networking.x-k8s.io with an X prefix on their type names — for example XBackend and XMesh.
When an experimental resource graduates to Standard, it is renamed into the gateway.networking.k8s.io group and drops the X prefix, the same way XMesh is expected to become Mesh. This separation makes the experimental versus standard boundary explicit at the API group level rather than relying on version strings alone, reducing the risk of accidentally depending on unstable APIs in production clusters.
Six Gateway controllers already report conformance with v1.6: Agentgateway, Airlock Microgateway, GKE Gateway, kgateway, NGINX Gateway Fabric, and Traefik Proxy. Practitioners can install the v1.6 CRDs from the release notes and follow the Gateway API documentation for detailed guides. The project welcomes contributions through the Kubernetes Slack channel #sig-network-gateway-api, weekly community meetings, and the kubernetes-sigs/gateway-api GitHub repository.
What to do next
Teams running TCP or UDP workloads should evaluate migrating from raw Services or vendor CRDs to the new v1 TCPRoute and UDPRoute resources for portable layer 4 routing. Controller maintainers need to implement the new API group separation and XBackend support. Start by checking your Gateway controller's v1.6 conformance report and updating CRD installations.
Source: Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard (GCP).
