Kubernetes Gateway API v1.6 Graduates TCPRoute and UDPRoute to General Availability

Kubernetes’ Gateway API project has graduated TCPRoute and UDPRoute, its resources for routing raw TCP and UDP traffic, out of the experimental channel and into General Availability. The Kubernetes SIG Network team detailed the milestone in a blog post published today, walking through changes that shipped with the Gateway API v1.6.0 release in late June 2026.

The Gap Gateway API Just Closed

Gateway API is the Kubernetes-native successor to Ingress, and it has had a stable, standard way to route HTTP and TLS traffic for several releases through resources like HTTPRoute and TLSRoute. Anything speaking a different protocol over raw TCP or UDP, such as databases, DNS servers, VoIP systems, game servers, or IoT telemetry collectors, had no equivalent standard-channel way to attach to a Gateway. Cluster operators either wrote implementation-specific configuration tied to one particular Gateway controller, or fell back on older, less portable networking primitives to expose that traffic.

TCPRoute and UDPRoute close that gap. Both resources previously lived in Gateway API’s experimental channel at the v1alpha2 API version. As of v1.6.0, they move to the v1 API version inside the Standard channel, Gateway API’s designation for features that have passed the project’s conformance test suite and are considered production-ready across implementations. The v1alpha2 versions of both resources are now deprecated and will be removed in a future release, so anyone piloting them from the experimental channel needs to migrate their manifests to the v1 API group. Kubernetes credits Nick Young, Ricardo Katz, and Zac Nixon for leading the graduation work, tracked as GEP-2644 for TCPRoute and GEP-2645 for UDPRoute.

What a TCPRoute Looks Like

The pattern mirrors HTTPRoute. A Gateway declares a listener for the TCP or UDP protocol, and a TCPRoute or UDPRoute attaches to that listener to describe where the traffic should go:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: foo
      protocol: TCP
      port: 12345
      allowedRoutes:
        kinds:
          - kind: TCPRoute
---
apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: tcp-app
spec:
  parentRefs:
    - name: example-gateway
      sectionName: foo
  rules:
    - backendRefs:
        - name: my-foo-service
          port: 6000

Traffic arriving on the Gateway’s port 12345 is proxied to my-foo-service’s endpoints on port 6000. Leaving sectionName and port out of parentRefs attaches the route to every TCP listener the Gateway exposes, instead of just one. UDPRoute follows the same pattern: swap the listener’s protocol to UDP and the route’s kind to UDPRoute.

The Rest of the v1.6.0 Release

TCPRoute and UDPRoute are the headline change, but v1.6.0 shipped several smaller adjustments alongside them, according to the project’s release notes on GitHub:

• HTTPRoute retry validation now requires unique retry status codes and at least one retry attempt
• The limit on Certificate Authority references rose from 8 to 16
• TLSRoute’s hostname limit rose from 16 to 1024, and its rule limit rose to match
• BackendTLSPolicy can now be combined with more route types than before
• Gateway infrastructure objects can now carry up to 16 annotations
• An XBackend resource entered experimental status, and a Standardized Telemetry API was added as provisional
• The project’s documentation site migrated from MkDocs to the Docsy framework, and gained a new controller-matching wizard

The release also carries one breaking change: the spec field on ReferenceGrant is now required, where it was previously optional.

Why It Matters

Gateway API’s core pitch is portability: write one manifest and expect it to behave the same way regardless of which Gateway controller implements it, because every Standard-channel resource has to pass the same conformance suite. Pushing TCPRoute and UDPRoute through that same bar gives teams running non-HTTP workloads on Kubernetes the same portability guarantee that HTTP and TLS traffic has had for several releases already. It also removes one more reason to keep a separate, implementation-specific load balancer configuration alongside Gateway API just to expose a database or a UDP-based service.

The graduation of TCPRoute and UDPRoute closes one of Gateway API’s last major gaps between HTTP-style traffic and everything else. Teams currently running either resource from the experimental channel should plan a migration to the v1 API group before the v1alpha2 versions are removed in a future release, and the full v1.6.0 changelog and migration notes are available in the project’s GitHub release.