Preface¶
Gateway API is the next-generation service networking API driven by the Kubernetes SIG Network community, with the goal of replacing Ingress in HTTP/TLS scenarios and further unifying routing expressions between Ingress and Service Mesh. Unlike Ingress which only covers layer 7 HTTP traffic, Gateway API adopts a role-oriented design – infrastructure operators, cluster operators, and application developers each manage their own CRDs, with semantics that are much closer to actual gateway capabilities.
Gateway API Version: v1.6.0 (released on June 30, 2026; official Kubernetes blog interpretation on August 3, 2026)
Prior to v1.6, the Standard channel of Gateway API had already stably supported L7 routing resources such as HTTPRoute and GRPCRoute. However, workloads relying on raw TCP/UDP protocols, such as databases, DNS, VoIP, gaming, IoT, etc., either had to fall back to ordinary Services or bind to private CRDs of specific Gateway implementations, resulting in poor cross-controller portability. The core change in v1.6 is promoting TCPRoute and UDPRoute from the Experimental channel to Standard, migrating the API version to gateway.networking.k8s.io/v1, finally bringing a portable standard for layer 4 load balancing on par with HTTPRoute.
This article verifies key points based on the official Kubernetes blog and GitHub Release v1.6.0, sorting out the meaning of L4 routing GA, configuration methods, and the evolution path brought by the separation of experimental API groups.
TCPRoute and UDPRoute: Completing the Last Piece of the L4 Routing Puzzle¶
What Problems Did It Solve¶
Prior to v1.6, Gateway API only provided stable routing models for HTTP and TLS traffic. There was no portable Gateway access method for raw TCP/UDP protocol traffic – MySQL clusters, DNS services, SIP trunks, real-time gaming protocols all fell into this gap.
The semantics of TCPRoute and UDPRoute are straightforward: route purely by protocol and port, no L7 awareness required. Traffic enters through the Gateway Listener and is forwarded to the Service endpoints specified in backendRefs, following the same parentRefs + rules structure as HTTPRoute.
What Does Promotion to Standard Channel Mean¶
According to the official release notes, the two resources have undergone the following changes in this version:
1. Graduated from the Experimental channel and entered the Standard channel, reaching GA stability.
2. API version migrated to gateway.networking.k8s.io/v1.
3. The legacy v1alpha2 version has been marked as deprecated starting from v1.6, and will be removed in future versions.
Corresponding GEP numbers: GEP-2644 (TCPRoute), GEP-2645 (UDPRoute). The community has also added UDPRoute conformance tests, the GATEWAY-UDP conformance profile, and the SupportTCPRoute feature tag for TCPRoute, making it easier for various Gateway controller implementers to pass acceptance checks.
TCPRoute Configuration Example¶
The Gateway first needs to declare a Listener that allows mounting TCPRoute:
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
Mount the TCPRoute to this Listener to forward traffic to the backend Service:
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
TCP traffic received on port 12345 of the Gateway will be proxied to the endpoints of port 6000 on my-foo-service. If you omit sectionName and port in parentRefs, the route will be mounted to all TCP Listeners on the Gateway instead of a specific one.
UDPRoute Configuration Example¶
The UDPRoute pattern is identical, just replace the Listener protocol and Route type with UDP:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: example-gateway
spec:
gatewayClassName: example-gateway-class
listeners:
- name: foo
protocol: UDP
port: 12345
allowedRoutes:
kinds:
- kind: UDPRoute
---
apiVersion: gateway.networking.k8s.io/v1
kind: UDPRoute
metadata:
name: udp-app
spec:
parentRefs:
- name: example-gateway
sectionName: foo
rules:
- backendRefs:
- name: my-foo-service
port: 6000
Evolution Path with Ingress and Service Mesh Unification¶
Gateway API was never designed to be just “Ingress 2.0”. Ingress only describes HTTP routing at the cluster ingress; Gateway API uses the Gateway + Route combination to cover both north-south ingress and east-west Service Mesh scenarios. HTTPRoute has long been part of the Standard channel, while Mesh-related resources such as XMesh are still being advanced in the Experimental channel. After v1.6 brought L4 routing into the Standard channel, the same Gateway control plane can now manage HTTPRoute, TCPRoute, and UDPRoute simultaneously, eliminating the need for three parallel systems: Ingress + proprietary L4 CRDs + Mesh policies for clusters with mixed protocol workloads.
For teams migrating from Ingress, the common path is:
1. First replace Ingress HTTP rules with HTTPRoute, with the Gateway handling TLS termination.
2. Gradually migrate TCP backends such as databases and message queues to TCPRoute, removing implementation-bound L4 annotations or CRDs.
3. If you have already deployed a Service Mesh, Gateway API Route resources can collaborate with Mesh policies under the same API semantics, reducing configuration fragmentation between “ingress one set” and “Mesh one set”.
The official blog positions the graduation of TCPRoute/UDPRoute as a key milestone towards “making Gateway API a complete, universal Ingress and Mesh networking API spanning L4/L7”, which aligns with the above migration path.
Separation of Experimental API Groups: XBackend and x-k8s.io¶
Another major thread in v1.6 is the complete separation of API group boundaries between experimental resources and standard resources.
Why the Split¶
Previously, experimental and standard resources shared the gateway.networking.k8s.io group, distinguished only by version strings such as v1alpha2. TCPRoute and UDPRoute were the last batch of resources to graduate under this mechanism. From now on:
- Standard resources will remain in gateway.networking.k8s.io.
- Experimental resources will move to the independent group gateway.networking.x-k8s.io, with an X prefix added to their type names (e.g. XBackend, XMesh).
- After experimental resources graduate, the X prefix will be removed and they will be moved to the standard group – the official example is that XMesh is expected to become Mesh in the future.
This allows one to immediately distinguish between “production-ready” and “still in iteration” resources at the API group level, no longer relying solely on version strings.
What is XBackend¶
XBackend (GEP-4894) is an experimental resource introduced in v1.6, serving as a Gateway-native decorator for backends such as Services. Kubernetes Service is stable and flexible, but Gateway API has difficulty safely extending certain concepts directly on Services – for example, directly supporting ExternalName in Services carries confused deputy-style security risks.
The first version of XBackend supports the ExternalHostname type, pointing to an external FQDN outside the cluster, suitable for egress scenarios, such as in-cluster Agent workloads accessing cloud-side AI APIs. The official clearly notes: XBackend is still experimental, behavior may change, and should not be used directly in production.
TLS configuration on the Gateway side is still handled authoritatively by the Gateway Listener; XBackend describes the external destination:
apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XBackend
metadata:
name: ai-provider-api
namespace: ai-apps
spec:
type: ExternalHostname
externalHostname:
hostname: api.ai-provider.com
Reference the XBackend instead of a Service in HTTPRoute:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
spec:
rules:
- backendRefs:
- name: ai-provider-api
kind: XBackend
group: gateway.networking.x-k8s.io
The community is also working on merging configurations such as Session Persistence from XBackendTrafficPolicy into XBackend, as well as egress Gateway-related GEPs – these are worth following, but have not yet reached Standard status.
Upgrade and Deployment Recommendations¶
If you have been using v1alpha2 TCPRoute/UDPRoute from the Experimental channel, it is recommended to migrate to the v1 API version as soon as possible to avoid forced upgrades when the legacy API is removed in future versions.
Before deployment, confirm whether your Gateway controller has passed the v1.6 conformance tests. The official blog listed the compliant implementation list on the day of release, but vendor support schedules vary, so refer to the Gateway API documentation and the corresponding controller’s release notes for accurate information.
When installing CRDs and controller versions, align with the change notes in the v1.6.0 release; GitHub v1.6.1 (released July 16, 2026) mainly includes test and conformance fixes, and does not affect the above API graduation conclusions.
Summary¶
Gateway API v1.6 advances L4 routing from “experimental capability” to “standard capability”, putting TCPRoute/UDPRoute on the same stability level as HTTPRoute, and making the path for Ingress evolution and Service Mesh unification clearer. Experimental innovations have been consolidated into the gateway.networking.x-k8s.io group with the X prefix naming convention, and XBackend provides an extensible testbed for egress and external backends.
If you maintain a Kubernetes cluster with mixed HTTP + TCP/UDP workloads, you can now start evaluating: which Services still rely on vendor-specific proprietary L4 CRDs, and whether they can be replaced with TCPRoute/UDPRoute from the Standard channel – this is the most worthwhile part to try out in v1.6.