Gateway API v1.6 的 TCPRoute 和 UDPRoute 有哪些变化

如果你的 Kubernetes 工作负载不是 HTTP，而是数据库连接、DNS、VoIP 或 IoT 遥测，Gateway API v1.6 的变化值得关注：TCPRoute 和 UDPRoute 已从 Experimental Channel 进入 Standard Channel，并使用 v1 API 版本。旧的 v1alpha2 版本从 v1.6 起被弃用，未来会移除。

官方资料：https://kubernetes.io/blog/2026/08/03/gateway-api-v1-6-release/

这不是“所有 Gateway API 资源都稳定了”，也不是“换成 v1 就自动兼容所有控制器”。正确的判断方式是：先区分协议层，再确认 CRD 与控制器支持，最后才决定是否迁移。

一、先看结论：v1.6 稳定了什么

Gateway API v1.6.0 在 2026 年 6 月 30 日发布，Kubernetes 官方发布说明把变化归纳为两条主线：

• TCPRoute 和 UDPRoute 进入 Standard Channel：两个资源都进入 gateway.networking.k8s.io/v1，可以用来表达原始四层 TCP/UDP 路由。
• 实验资源使用独立 API Group：新的实验能力转移到 gateway.networking.x-k8s.io，并使用带有 X 前缀的资源名，例如 XBackend。

因此，升级时最重要的不是只搜索“v1.6”，而是逐项确认资源所在的发布通道、API Group、版本号和控制器的实现状态。Gateway API 的 Standard Channel 是稳定使用建议，不等于每个实现都在同一天支持全部资源。

二、它解决的是 L4 路由，不是 HTTP 规则的另一种写法

HTTPRoute 关注路径、方法、请求头等 L7 信息；TCPRoute 和 UDPRoute 则只需要根据协议和端口把连接或数据报送到后端。它们适合没有 HTTP 语义、也不需要解码应用层内容的服务。

这一区分带来一个实际结果：如果应用本来就只暴露 TCP 或 UDP，继续把它包装成 HTTP 规则并不能增加可移植性；而直接采用对应的 Route 类型，可以让 Gateway 的监听协议、路由类型和后端关系更清楚。

三、读懂一条四层路由的组成关系

官方示例的关系可以压缩成四个检查点：Gateway 提供监听器，监听器声明 TCP 或 UDP 协议；allowedRoutes.kinds 限定允许挂载的 Route 类型；Route 通过 parentRefs 指向监听器；规则再用 backendRefs 指向 Service。

# Gateway 只允许 TCPRoute 挂载到这个 TCP 监听器
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: tcp-entry
      protocol: TCP
      port: 12345
      allowedRoutes:
        kinds:
          - kind: TCPRoute
---
# TCPRoute 选择上面的监听器，并把连接转发到 Service 的 6000 端口
apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: tcp-app
spec:
  parentRefs:
    - name: example-gateway
      sectionName: tcp-entry
  rules:
    - backendRefs:
        - name: my-foo-service
          port: 6000

这里的关键不是 YAML 的字段数量，而是边界是否一致：监听器是 TCP，允许的 Route 是 TCPRoute，Route 的父引用落到对应监听器，后端端口则由 Service 暴露的实际协议端点承接。UDPRoute 的结构相同，只需要把监听器协议和 Route 类型换成 UDP。

四、升级时按四层清单检查，而不是直接替换字符串

如果现有配置仍使用 v1alpha2，可以按下面顺序判断：

1. 确认资源：只迁移 TCPRoute、UDPRoute 及其关联的 Gateway Listener，先不要把 XBackend 等实验资源混进同一批改动。
2. 确认 CRD 来源：使用 Gateway API v1.6 对应的 Standard 安装内容，确保集群里已经有 gateway.networking.k8s.io/v1 的资源定义。
3. 确认控制器：查看目标 Gateway 实现对 v1.6 和 TCPRoute/UDPRoute 的兼容说明或一致性测试结果；Standard Channel 不会替控制器自动升级。
4. 确认监听器：检查 protocol、端口、allowedRoutes 与 Route 类型是否配套，尤其不要把 TCPRoute 误挂到 HTTP 监听器。
5. 确认回退边界：保留旧配置和发布说明，先在非生产环境确认控制器能识别 v1，再安排正式迁移。

代码层面的修改通常不复杂，但运维风险集中在“CRD 已升级、控制器未升级”或“Route 已改版本、监听器却没有允许对应 Kind”这两类不对称状态。把它们拆成独立检查项，比一次性全量替换更容易定位问题。

五、别把 Standard 和 Experimental 混在一起

v1.6 引入的 XBackend 是实验资源，使用 gateway.networking.x-k8s.io API Group，官方明确提示它的行为仍可能变化，不应当按照生产稳定能力理解。TCPRoute 和 UDPRoute 则属于另一条路径：它们从实验通道毕业，进入标准通道，并落到 gateway.networking.k8s.io/v1。

可以用一个简单规则避免误判：看到 gateway.networking.k8s.io/v1，先按 Standard 资源检查；看到 gateway.networking.x-k8s.io 或 X 前缀，先按 Experimental 资源评估兼容性和变更风险。最终仍以目标控制器的实现说明为准。

六、最后用速查表决定是否迁移

一句话总结：Gateway API v1.6 的核心收益，是把 TCPRoute 和 UDPRoute 带入了更稳定、更可移植的标准 API 边界；迁移的核心工作，则是同步检查 CRD、控制器、监听器和 Route 之间的关系。把稳定资源与实验资源分开评估，升级会更稳。

相关问题

TCPRoute 和 HTTPRoute 能共用一个 Gateway 吗？

可以考虑共用同一个 Gateway，但要为不同协议配置对应 Listener，并在 allowedRoutes 中允许匹配的 Route Kind。是否支持还要看具体实现。

v1alpha2 能继续使用吗？

官方发布说明已经将 TCPRoute 和 UDPRoute 的 v1alpha2 标记为弃用。短期兼容不代表长期安全，新的迁移计划应优先面向 v1。

进入 Standard Channel 是否代表所有控制器都支持？

不是。Standard Channel 描述的是 Gateway API 的稳定性边界，仍需查看目标控制器的版本与一致性支持情况。