The Kubernetes SIG Network community has released Gateway API v1.6.0 (June 30, 2026). This update marks a significant shift in the project's maturity, moving raw Layer 4 (TCP and UDP) routing to stable status and introducing a new experimental resource for egress traffic. The release also refines API boundaries to separate experimental innovation from standard features.
TCP and UDP Routing Graduate to Standard
Historically, Gateway API provided a stable routing model exclusively for HTTP and TLS traffic. Workloads relying on raw protocols—such as databases, DNS servers, VoIP, gaming, and IoT telemetry—had to rely on standard Kubernetes Services or implementation-specific Custom Resource Definitions (CRDs) that lacked portability.
With v1.6.0, Gateway API graduates TCPRoute and UDPRoute to the Standard channel. Both resources are now available in the gateway.networking.k8s.io/v1 API version, replacing the previous v1alpha2 versions, which are deprecated and scheduled for removal in a future release.
This standardization allows users to route raw L4 traffic through the Gateway API without falling back to the underlying Service object.
Configuration Examples
To enable TCP routing, a Gateway listener must explicitly allow TCPRoute attachments. Below is a configuration snippet for a Gateway and a corresponding 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
---
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
UDP routing follows the same pattern. A listener configured for UDP will accept UDPRoute resources, forwarding traffic to the specified backend service port.
Experimental API Group Separation
To make the distinction between standard and experimental features clearer, v1.6 introduces a new API group for experimental resources: gateway.networking.x-k8s.io.
Previously, experimental resources were distinguished only by their version (e.g., v1alpha2) within the standard group. Going forward, new experimental resources will be defined in this separate group, and their names will carry an X prefix (e.g., XBackend, XMesh). When an experimental resource graduates to Standard, it will be renamed (e.g., XMesh becomes Mesh) and moved to the standard group.
XBackend Resource for Egress
The release introduces XBackend, an experimental resource designed to act as a general-purpose decorator for Service objects and other backend types within Gateway API.
The Kubernetes Service resource is stable and flexible, but this stability limits the ability to introduce new concepts. The XBackend resource aims to address this by allowing the community to extend it for use cases that are difficult or risky to handle with Services alone.
Key features include support for ExternalHostname destinations. This support is particularly relevant for egress scenarios—such as cluster-hosted agentic workloads connecting to cloud AI APIs—but comes with a security caveat.
Security Warning: The use of ExternalHostname in XBackend is considered an Extended/Optional feature. It is ruled out from standard Service support in Gateway API due to the possibility of confused deputy attacks. Users must opt in and understand these security tradeoffs.
Below is an example configuration for an egress Gateway using an XBackend to route to an external cloud API:
# Backend resource for 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
---
# HTTPRoute referencing XBackend
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
spec:
rules:
- backendRefs:
- name: ai-provider-api
kind: XBackend
group: gateway.networking.x-k8s.io
Community efforts are also underway to move Session Persistence and other configuration (such as retries and TLS origination) from XBackendTrafficPolicy directly into XBackend to allow per-application configuration.
Conformance and Involvement
Gateway API relies on an extensive conformance test suite to ensure consistent behavior. On the day of the release, the following implementations were reported as conformant with v1.6:
- Agentgateway
- Airlock Microgateway
- GKE Gateway
- kgateway
- NGINX Gateway Fabric
- Proxy
- Traefik
The Kubernetes community encourages users to try out v1.6.0 with their preferred Gateway controller and to get involved via the project's Slack channel, community meetings, and GitHub repository.