Why this matters
For years, the Gateway API was the story of HTTP routing on Kubernetes. Ingress was for web traffic, and everything else - databases, message queues, game servers - had to hack around it or run its own load balancers.
Gateway API v1.6 changes that. TCPRoute and UDPRoute have graduated to standard. That means the same declarative, portable Gateway API now covers non-HTTP workloads with first-class support.
What graduated
The v1.6 release promotes TCPRoute and UDPRoute out of experimental. This is not a small footnote. It is the Gateway API formally becoming the universal L4 routing layer for Kubernetes.
- TCPRoute lets you route raw TCP by port and hostname, with weighted backends and timeouts.
- UDPRoute does the same for UDP, which matters for game servers, DNS, and streaming workloads.
- Both use the same Gateway resources, policies, and providers as HTTPRoute, so the mental model stays consistent.
Why this is bigger than it sounds
The Gateway API was designed to be the successor to Ingress, and for HTTP workloads it already is. What held it back was the long tail of non-HTTP services that still needed per-cluster LoadBalancer Services, manual port mappings, and provider-specific annotations.
With TCPRoute and UDPRoute standard, that long tail shrinks. A team running Postgres, Redis, a game backend, and a web API on the same cluster can now describe all of it with one Gateway API model, one policy layer, and one set of provider implementations.
What to do next
- Upgrade your Gateway API CRDs to v1.6 when your provider supports it.
- Audit the LoadBalancer Services you created for non-HTTP workloads and look for TCPRoute/UDPRoute equivalents.
- Standardize on Gateway API policies across both L4 and L7 workloads instead of mixing annotations.
- Test the migration on a non-production cluster first - the resource shape changes.
The Gateway API just became the universal routing layer for Kubernetes. TCP and UDP workloads are no longer second-class citizens.
The bigger picture
Every Kubernetes release moves the platform toward a smaller set of standard, portable primitives. Gateway API v1.6 is one more step in that direction: one routing model for everything, whether it speaks HTTP, raw TCP, or UDP.
This is the kind of platform engineering work I do: Kubernetes, infrastructure as code, and migrations that ship reliably. If your cluster is still running a patchwork of Ingresses and LoadBalancer Services, this is a good moment to consolidate.