Gateway API v1.6 进入稳定阶段意味着什么：TCPRoute、UDPRoute 与迁移判断

团队已经用 Gateway API 管理 HTTP 流量，下一步想把数据库代理、DNS 或实时传输服务也接进同一套入口时，最容易误判的是“协议资源稳定了，所以控制器一定能直接接”。Gateway API v1.6 的确把 TCPRoute 和 UDPRoute 提升到了 Standard，但这代表 API 契约成熟，不代表每个实现、每个 GatewayClass 都同时具备完整能力。

Gateway API v1.6 到底稳定了哪一层

Kubernetes 官方在 Gateway API v1.6 发布说明中明确，TCPRoute 与 UDPRoute 从较早阶段进入 Standard。这里的“稳定”首先约束资源模型和协作方式：Gateway、监听器以及路由资源之间的关系更适合被控制器长期实现，团队也可以围绕它设计配置审查和发布流程。

它并不自动改变集群里的数据面。GatewayClass 仍然决定由哪个控制器接管，控制器还要把路由翻译成负载均衡器、代理或节点转发规则。换句话说，API 状态稳定了，运行时能力仍要在自己的实现上验证。

先按业务负载判断，而不是按新闻标题迁移

如果现有服务全是 HTTP/HTTPS，Ingress 或 HTTPRoute 已经满足需求，迁移到 TCPRoute 不会凭空带来更高吞吐。真正值得评估的是同一个集群入口是否同时承载了非 HTTP 协议，团队是否希望把证书、监听器、访问审计和发布审批放到同一个资源体系中。

这一步的结果应当是一张端口清单，而不是一句“统一网关”。记录监听地址、协议、后端 Service、是否需要源地址保留，以及现有入口的健康检查方式。没有这些约束，后面很容易把 HTTP 的验收标准套到 TCP 或 UDP 上。

迁移前必须核对 GatewayClass 和控制器能力

配置资源之前，先看集群里的 GatewayClass 是否被控制器接受：

kubectl get gatewayclass
kubectl describe gatewayclass public-gw
kubectl get gateway -A -o wide

重点不是命令有没有返回，而是状态里的 Accepted、控制器名称和事件信息。TCPRoute 或 UDPRoute 创建后，还要查看路由的父级引用是否被接受、是否绑定到预期的 Gateway。不同实现对字段、端口冲突、跨命名空间引用和 UDP 转发的支持可能不同，不能只根据资源版本号推断结果。

可以把核对结果写入发布单：控制器版本、GatewayClass 名称、支持的 RouteKind、监听器端口、失败事件和回滚命令。这样 API 升级新闻才真正转成了工程决策。

三种落地方式的取舍

第一种是保持现有 HTTP 入口，只在新协议服务上增加一个独立 Gateway。这种方式改动最小，适合先验证控制器能力，但会多维护一个外部地址或负载均衡器。

第二种是在同一个 Gateway 上增加不同协议的监听器，再分别绑定 HTTPRoute、TCPRoute 或 UDPRoute。它能统一入口和审计，但要提前解决端口占用、证书配置与不同健康检查模型的差异。

第三种是保留旧入口，把 Gateway API 作为灰度入口。DNS、客户端配置或上游代理只切一小部分流量；指标和连接失败率稳定后再扩大范围。对有长连接的 TCP 服务，这通常比一次性切换更稳妥。

上线验收要分协议设置观察点

HTTPRoute 可以看状态码、路径命中和响应延迟；TCPRoute 更应关注连接建立成功率、活跃连接数、后端重置和空闲超时；UDPRoute 则要看报文到达率、丢包、会话跟踪和端口复用。只看 Gateway 的 Accepted 状态，最多说明控制面接受了资源，不能证明数据面已经正常转发。

第一次切换建议只放一个低风险端口，保留旧 Service 或旧负载均衡入口。验收通过后再扩展到生产端口；出现路由未绑定、连接被重置或 UDP 报文异常时，先回切入口，再根据控制器事件定位，不要在流量持续抖动时反复改资源。

常见问题

TCPRoute 进入 Standard 后，所有 Kubernetes 控制器都支持吗？

不一定。Standard 描述的是 Gateway API 的资源成熟度，实际支持仍由控制器和 GatewayClass 声明，必须查实现文档并在集群中核对状态。

只有 HTTP 服务，需要立即从 Ingress 迁移吗？

通常没有必要。若现有 Ingress 稳定且没有新的协议治理需求，可以继续维护；迁移应由路由能力、审计和运维统一性驱动。

UDPRoute 的验收为什么不能照搬 HTTPRoute？

UDP 没有 HTTP 状态码和请求路径，验收要围绕报文到达、丢包、会话和后端响应设计，最好用协议客户端做端到端测试。

迁移失败时最小回滚动作是什么？

保留旧入口并把客户端或 DNS 切回旧地址，随后删除或暂停新路由，保存 Gateway、Route 状态和控制器事件，避免只留下“发布失败”的结论。

把稳定 API 变成可控迁移

Gateway API v1.6 值得关注的地方，不是“又多了两个资源名”，而是 TCP 和 UDP 流量终于可以在更成熟的契约下参与入口治理。落地时按协议盘点负载，确认 GatewayClass 能力，选择独立入口或同 Gateway 监听器，再用小端口灰度和协议专属指标验收，迁移才有可回退的边界。