Gateway API v1.6 promotes TCPRoute and UDPRoute to Standard, and puts a clock on the v1alpha2 shapes

Gateway API v1.6.0 shipped on June 30 and the SIG Network write-up landed on August 3, and the CI-visible change is straightforward: TCPRoute and UDPRoute are now v1 resources on the Standard channel, and the v1alpha2 versions of both are deprecated on the same release. Cluster manifests that still reference gateway.networking.k8s.io/v1alpha2 for either route type will keep working for now, but the countdown to their removal has started.

What graduated, and what moved

Per the release post, TCPRoute (GEP-2644) and UDPRoute (GEP-2645) both crossed from Experimental into Standard, tracked under the v1 API version alongside the existing HTTPRoute and TLSRoute lineup. The functional model is what SIG Network describes as raw L4 routing: TCPRoute and UDPRoute match on protocol and port only, with no HTTP-layer awareness. A route can pin to a single listener via sectionName, or, if sectionName is omitted, attach to every listener on the parent Gateway that matches the route's protocol. That is the whole matching surface. There is nothing to configure at the request layer, because there is no request layer.

The other structural change is that experimental resources are moving to a distinct API group, gateway.networking.x-k8s.io, with an X prefix on the type names. The Standard channel keeps gateway.networking.k8s.io. The point of the split, per the post, is to make the experimental-versus-standard boundary a property of the API group rather than a channel flag on the CRD bundle. Anything you install from the experimental group is meant to be visibly experimental in the manifest itself.

What this actually does to your pipelines

If your platform is already stamping HTTPRoute at v1 through GitOps, TCPRoute and UDPRoute now sit next to it as first-class Standard resources rather than as feature-flagged experiments. That is the operational unlock: databases, DNS, VoIP endpoints, gaming, IoT telemetry, anything that speaks over a fixed TCP or UDP port instead of HTTP, can be routed through the same Gateway your L7 traffic already flows through, on an API that carries the usual Standard-channel commitments.

The deprecation is where CD teams should look first. The v1alpha2 TCPRoute and UDPRoute types are still present, but they are on the way out; the release post says they will be removed in a future release without naming which one. Any Helm chart, kustomization, controller reconciler or policy engine that hardcodes apiVersion: gateway.networking.k8s.io/v1alpha2 for one of these two kinds is now a scheduled break. A grep across your manifest repos costs nothing and buys a migration window.

The routing model, minus the marketing

The TCPRoute example the release calls out looks roughly like this once you strip the vendor framing:

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: <route-name>
spec:
  parentRefs:
    - name: <gateway-name>
      sectionName: <listener-name>   # omit to attach to every matching listener
  rules:
    - backendRefs:
        - name: <service-name>
          port: <backend-port>

There is no host header, no path, no method. A packet lands on the listener, and if the protocol matches it goes to a backend. The upshot at 3am: when a TCPRoute is misbehaving, the debugging surface is the Gateway status, the listener status, and whether the parentRefs/sectionName binding actually resolved. That is a much smaller haystack than an HTTPRoute incident, and it is worth codifying in the runbook while the feature is new to the team.

Sharp edges to plan for

Two things are worth flagging up front. First, the release post itself notes that experimental resources are the ones moving to gateway.networking.x-k8s.io, so any manifest that previously assumed everything sits under gateway.networking.k8s.io needs a sweep before the next controller bump. Second, the shape of the experimental surface is now explicitly designed to churn: types under the X prefix are the ones intended to change. If a CD workflow pins to something in that group, treat it as unstable by definition, not by convention.

There is also what the release does not say. The post does not commit to a removal date for v1alpha2 TCPRoute and UDPRoute, only that a future release will remove them. That is the shape of these deprecations, and the safe read is to migrate now while it is a rename, not later while it is an outage.