The Kubernetes SIG Network community is thrilled to share the release of Gateway API v1.6.0, which was released on June 30th of this year!Gateway API has become the standard for modern, role-oriented,and expressive service networking in Kubernetes.In previous releases, Gateway API established a production-grade foundationfor HTTP and TLS layer 7 traffic.With version 1.6.0, Gateway API takes a major step forward by expandingstandard layer 4 protocol routing and introducing cleaner API boundaries for experimental innovation.Here is a quick summary of what's new in Gateway API v1.6.0:TCPRoute and UDPRoute Graduate to Standard: Raw L4 TCP and UDP traffic routing reach GA stability in the v1 API version.Experimental API Group Separation: Experimental resources transition to a distinct API group (gateway.networking.x-k8s.io) with an X prefix to make experimental vs. standard boundaries crystal clear.Let's dive into the details!TCPRoute and UDPRoute graduate to StandardLeads: Nick Young, Ricardo Katz and Zac NixonGEP-2644 - TCPRouteGEP-2645 - UDPRouteUntil now, Gateway API only offered a stable routing model for HTTP and TLS traffic.Workloads that speak a raw protocol over TCP or UDP - databases,DNS, VoIP, gaming, IoT telemetry - had no portable way to pluginto 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 and UDPRoute close that gap: they route traffic to backends based on protocol and port alone, no L7 awareness required.With this release, 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.How it worksA Gateway needs a listener that allows TCPRoute attachment:apiVersion: gateway.networking.k8s.io/v1kind: Gatewaymetadata: name: example-gatewayspec: gatewayClassName: example-gateway-class listeners: - name: foo protocol: TCP port: 12345 allowedRoutes: kinds: - kind: TCPRouteA TCPRoute then attaches to that listener and forwards traffic to a backend:apiVersion: gateway.networking.k8s.io/v1kind: TCPRoutemetadata: name: tcp-appspec: parentRefs: - name: example-gateway sectionName: foo rules: - backendRefs: - name: my-foo-service port: 6000Traffic arriving on the Gateway's port 12345 is proxied to the endpoints of my-foo-service on port 6000. Omitting sectionName and port from parentRefs attaches the route to every TCP listener on the Gateway instead of a single one.UDPRoute follows the same pattern; swap the listener protocol and the route kind:apiVersion: gateway.networking.k8s.io/v1kind: Gatewaymetadata: name: example-gatewayspec: gatewayClassName: example-gateway-class listeners: - name: foo protocol: UDP port: 12345 allowedRoutes: kinds: - kind: UDPRoute---apiVersion: gateway.networking.k8s.io/v1kind: UDPRoutemetadata: name: udp-appspec: parentRefs: - name: example-gateway sectionName: foo rules: - backendRefs: - name: my-foo-service port: 6000XBackend arrives in ExperimentalLeads: Keith Mattix IIGEP-4894 - Backend ResourceGateway API v1.6 introduces the new XBackend resource, which is a general-purpose decorator for Service (and other backend types) within Gateway API.The Service resource is an amazing, stable, and flexible object, but that comes with some costs: The flexibility creates a lot of edge cases that Gateway API needs to handle, and the stability makes it impossible to add new concepts to Service.The XBackend resource builds on the ideas in the upstream EndpointSelector KEP, to add a Gateway API-native object that still targets the backend app, while allowing the community to extend it to handle use cases that are difficult or dangerous to handle with Service.The first version of XBackend includes support for ExternalHostname destinations, which are ruled out from Service support in Gateway API because of the possibility of confused deputy attacks.For XBackend, this support is an Extended/Optional feature, allowing implementations and users to opt in once they understand the security tradeoffs.This support is very useful for egress use cases (which are most commonly used for cluster-hosted agentic workloads), which the community is also working towards formalizing in GEPs about Gateways for Egress (work in progress, stay tuned!)The XBackend API is experimental and its behavior can change, do not assume it is ready for productionAn example of a Gateway with an ExternalName backend that can be used for egress to a cloud AI API is as follows:# Gateway-level TLS remains authoritative for incoming connectionsapiVersion: gateway.networking.k8s.io/v1kind: Gatewayspec: listeners: - name: https protocol: HTTPS tls: certificateRefs: - name: gateway-cert---# Backend resource for external destinationapiVersion: gateway.networking.x-k8s.io/v1alpha1kind: XBackendmetadata: name: ai-provider-api namespace: ai-appsspec: type: ExternalHostname externalHostname: hostname: api.ai-provider.com---# HTTPRoute referencing XBackendapiVersion: gateway.networking.k8s.io/v1kind: HTTPRoutespec: rules: - backendRefs: - name: ai-provider-api kind: XBackend group: gateway.networking.x-k8s.ioThe community is also working on moving Session Persistence config from XBackendTrafficPolicy into XBackend, along with other use cases like retries, TLS origination and similar config that is useful to be able to configure per-application rather than per-Route.Experimental resources move off the standard API groupPreviously, experimental resources shared the same API group as standard ones - gateway.networking.k8s.io - distinguished only by a v1alpha2-style version. TCPRoute and UDPRoute were the last resources to graduate under that scheme.Going forward, new experimental resources are defined in a separate group,gateway.networking.x-k8s.io,and the names of their API types get an X prefix - for example XBackend and XMesh.When one of these graduates to Standard, it's renamed into the gateway.networking.k8s.io groupand drops the X prefix, the same way XMesh is expected to become Mesh.This separation makes the experimental/standard boundary explicit at the API group level, rather than relying on version strings alone.What's next & getting involvedThe graduation of TCPRoute and UDPRoute to Standard marks an essential milestonein making Gateway API a complete, universal ingress and mesh networking APIfor Kubernetes workloads across layer 4 and layer 7 protocols.Try it outYou can start using Gateway API v1.6.0 today with your favorite Gateway controller implementation:Check out the Gateway API Documentation for detailed guides and API references.View the v1.6.0 Release Notes for complete details on the CRD installation and changes.Gateway API relies on an extensive conformance test suite to ensure consistent,portable behavior across all implementations.Here is a list of the implementations that are conforment with v1.6 on the day we published the article:AgentgatewayAirlock MicrogatewayGKE GatewaykgatewayNGINX Gateway FabricTraefik ProxyGet involvedGateway API is an open, community-driven project built under Kubernetes SIG Network. We welcome contributions, feedback, and participation from everyone!Join our Slack Channel: Join #sig-network-gateway-api on the Kubernetes Slack.Attend Community Meetings: We hold weekly community meetings. Check out the SIG Network Calendar for dates and agendas.Contribute on GitHub: File issues, suggest enhancements (GEPs), or submit PRs at kubernetes-sigs/gateway-api.AcknowledgmentsA huge thank you to all the contributors, reviewers, maintainers, and implementation authors whose hard work made Gateway API v1.6.0 possible!