Kubernetes Gateway API 1.6 stabilizes TCP and UDP: should you replace network CRDs?

Gateway API 1.6 moves TCPRoute and UDPRoute into the Standard channel and the v1 API. Kubernetes teams finally have a stable, portable model for layer-four protocols such as databases, DNS, VoIP, games and IoT telemetry without depending on a controller-specific custom resource.

The release also separates experimental work more clearly. Future unstable resources move to gateway.networking.x-k8s.io and receive an X prefix. That makes maturity visible in the API name, but platforms testing those resources must track manifests carefully.

The short answer

A portable route for raw protocols

Gateway API already had a stable foundation for HTTP and TLS. Raw TCP or UDP traffic was commonly exposed through a LoadBalancer Service or provider CRD. The latter made configuration difficult to move between NGINX, Traefik, GKE Gateway and other controllers.

TCPRoute connects a Gateway's TCP listener to a backend by port without inspecting the application protocol. UDPRoute follows the same model. A platform can separate Gateway infrastructure owned by the network team from routes managed by application teams.

Standard status means the API shape, core behavior and conformance tests have reached a production-oriented level. It does not mean every controller extension behaves identically.

What it changes for databases and internal services

A PostgreSQL database, broker or game server can share Gateway infrastructure with other traffic while retaining a separate listener. Kubernetes permissions can allow a team to attach routes to selected listeners without changing public addresses or global certificates.

The model standardizes manifests but does not replace security controls. A TCP route does not automatically encrypt traffic, authenticate clients or create a NetworkPolicy. The carried protocol still needs TLS where appropriate, and the cluster must restrict lateral communication.

For UDP, connectionless behavior makes observability and balancing harder. Timeouts, affinity and packet handling still depend heavily on the controller and network provider.

Experimental APIs move address

Experimental resources previously shared gateway.networking.k8s.io with standard APIs, with alpha versions indicating instability. The new structure uses gateway.networking.x-k8s.io and an X-prefixed kind such as XBackend or XMesh.

This prevents an unstable resource from looking durable in inventories and policies. When it graduates, it changes group and drops the prefix, requiring an explicit migration. GitOps tools and policy generators must understand both groups.

A cautious migration plan

Inventory v1alpha2 TCPRoute and UDPRoute resources along with proprietary CRDs serving the same purpose. Confirm that the installed controller advertises Gateway API 1.6 conformance for these resources, not merely generic Gateway API support.

Install 1.6 CRDs in a test environment, convert one non-critical flow and compare addresses, ports, backend health and restart behavior. Test failure paths too: unauthorized routes, wrong namespaces, missing backends and incompatible listeners.

Production migration needs rollback. Two resources cannot always bind the same port simultaneously; a second Gateway or temporary address may be required before switching DNS.

Conformance does not erase product differences

Gateway API has a conformance suite, but implementations can support different profiles and optional features. Provider annotations, timeout policies, metrics and WAF integrations may still create lock-in.

The realistic goal is not perfect portability but a standard core every team can read. Extensions should be isolated and documented so their migration cost remains visible.

Gateway API 1.6 fills an important gap between a basic Service and proprietary networking CRDs. TCPRoute and UDPRoute can now provide the shared foundation, provided teams test the actual controller and do not confuse stable routing with automatic security.