Kubernetes Gateway API 1.6 Graduates TCPRoute and UDPRoute to Standard, Splits Off a New Experimental API Group
Gateway API 1.6 promotes TCPRoute and UDPRoute to GA, closing a gap for raw TCP/UDP workloads, and moves experimental resources into a new API group.
Overview
Kubernetes SIG Network has graduated TCPRoute and UDPRoute, Gateway API’s resources for routing raw TCP and UDP traffic, from the Experimental channel to Standard in version 1.6.0, giving cluster operators a stable, portable way to plug non-HTTP workloads into a Gateway for the first time, according to the official Kubernetes blog. The release, announced in a blog post published Monday, August 3, 2026 by Beka Modebadze of Google and Ricardo Katz of Red Hat, also splits Gateway API’s experimental resources into a separate, clearly marked API group.
What We Know
Gateway API has, in the project’s own words, “become the standard for modern, role-oriented, and expressive service networking in Kubernetes,” but until this release its stable routing model covered only HTTP and TLS traffic, according to the Kubernetes blog. As the blog post puts it, “Workloads that speak a raw protocol over TCP or UDP—databases, DNS, VoIP, gaming, IoT telemetry—had no portable way to plug into a Gateway. Users either fell back to a plain Kubernetes Service or to an implementation-specific CRD that doesn’t travel between Gateway controllers.”
TCPRoute (tracked as GEP-2644) and UDPRoute (GEP-2645) close that gap. Per the Kubernetes blog, the two resources “route traffic to backends based on protocol and port alone, no L7 awareness required,” and with version 1.6.0 “both have graduated from the Experimental channel to Standard and moved to the v1 API version. The v1alpha2 version of each was deprecated as of the v1.6 release and will be removed in a future release.” The blog credits Nick Young, Ricardo Katz, and Zac Nixon as leads on the feature. The GitHub release notes confirm the graduation at the changelog level, crediting TCPRoute’s promotion to pull request #4920 and UDPRoute’s to #4923, both authored by Zac Nixon.
In practice, a cluster operator now attaches a TCPRoute to a Gateway listener configured with protocol: TCP; the Kubernetes blog’s example shows traffic arriving on a Gateway’s port 12345 proxied to a backend service on port 6000, with the blog noting that “omitting sectionName and port from parentRefs attaches the route to every TCP listener on the Gateway instead of a single one.” UDPRoute, the post says, “follows the same pattern; swap the listener protocol and the route kind.”
Alongside the TCPRoute and UDPRoute graduation, the release moves experimental resources — including a new XBackend resource added to Experimental status — into a distinct API group, gateway.networking.x-k8s.io, carrying an “X” prefix, which the Kubernetes blog says is meant “to make experimental vs. standard boundaries crystal clear.” The GitHub release notes list a further set of changes shipped in the same version: the number of allowed Certificate Authority references per resource rises from 8 to 16, TLSRoute’s CRD validation now allows up to 1,024 hostnames and rules per resource, BackendTLSPolicy can be combined with other route types, and the gateway infrastructure object’s annotation limit increases to 16. The experimental SessionPersistence API’s idleTimeout field was removed, and project documentation was migrated from MkDocs to Docsy alongside a new controller-matching wizard.
A follow-up patch, v1.6.1, published July 16, 2026, contains only test and conformance fixes — including corrections to TCPRouteMultipleRoutesAttachment port handling and flaky weighted-routing conformance tests — and introduces no new API surface, according to its GitHub release notes.
The v1.6.0 code itself shipped in late June 2026, ahead of the August 3 blog write-up, according to the Kubernetes blog and the GitHub release page.
The graduation lands as Kubernetes operators have been under pressure to migrate off Ingress-NGINX and onto Gateway API-based alternatives; The Machine Herald has previously reported on the Ingress2Gateway migration tool reaching its 1.0 release as part of that broader push.
What We Don’t Know
The Kubernetes blog post and GitHub release notes do not specify a target release for removing the deprecated v1alpha2 versions of TCPRoute and UDPRoute, beyond saying it will happen “in a future release.” Neither source details which specific Gateway API controller implementations (such as Envoy Gateway, Istio, or Cilium) already support the newly graduated TCPRoute and UDPRoute resources at the v1 API version, or on what timeline vendors plan to adopt them.