Gateway API v1.6 TCPRoute 标准化后如何评估现有入口规则

Gateway API v1.6.0 已把 TCPRoute 和 UDPRoute 提升到 Standard，并将 TCPRoute 的稳定 API 版本推进到 v1。但这不等于现有入口规则可以直接替换：控制器是否支持 v1.6、监听器是否允许 TCPRoute、旧规则是否存在同监听器冲突，都要分别确认。真正稳妥的做法，是先把“规范已标准化”和“当前数据面能正确转发”拆成两件事，再决定迁移。

Gateway API v1.6 变化的重点不是“能不能用”，而是“谁支持”

这次发布的工程信号很明确：TCPRoute 从 Experimental 进入 Standard，API 版本从 v1alpha2 走向 v1，旧版本已被标记为 deprecated，未来会移除。同时，新的实验资源开始使用独立的 gateway.networking.x-k8s.io API 组。对平台团队来说，第一项工作不是全量改 YAML，而是建立四列清单：控制器版本、Gateway API CRD 包版本、TCPRoute 支持级别、当前生产入口数量。

这里要特别防止一个误判：CRD 能接受 kind: TCPRoute，只说明 Kubernetes API 层能存下对象，不代表具体 Gateway controller 已实现 v1 TCP 转发。应以控制器发布说明、实现文档和对应版本的 conformance 报告交叉确认；没有报告时，按“待验证”处理。

四个字段先核对：监听器、绑定、冲突、后端

把每条旧入口规则按下面的顺序检查，效率比先改版本号高。监听器的 protocol 必须是 TCP；HTTP 或 HTTPS listener 不应接受 TCPRoute。若 Gateway 显式设置了 allowedRoutes.kinds，其中还必须允许 TCPRoute。这两项不满足时，优先看 Route status 中的 Accepted 和原因，而不是反复重建对象。

sectionName 更适合表达“这条路由绑定某个命名 listener”；只按 port 绑定虽然灵活，却把路由和 Gateway 的端口结构耦合得更紧。对于已有生产入口，我会先保留明确的 listener 名称，再把端口绑定作为需要单独评审的例外。

同一个 TCP listener，多个规则不代表可以分流

TCP 连接不像 HTTP 请求，没有主机名、路径这样的七层匹配条件。如果两条 TCPRoute 都指向同一个 listener，规范定义的结果是：它们可能都显示为 Accepted，但实际只有优先级更高的一条获得流量。优先级先看 metadata.creationTimestamp，时间相同再按 namespace/name 的字典序判断。

因此迁移前要把“对象被接受”和“连接真的到了哪个 Service”分开记录。建议导出所有 TCPRoute 的 parentRefs，按 listener 分组，给每组标记唯一预期后端；发现一个 listener 有多个生产规则时，先拆分端口或 listener，再做 v1 迁移。不要用重命名或重新 apply 来碰运气，因为创建时间变化本身就可能改变胜者。

用状态条件和小流量连接完成最后验收

规则文件改完后，至少核对三层结果：Route 的 Accepted 是否为 True，后端引用的 ResolvedRefs 是否为 True，实际 TCP 连接是否到达预期 Service。后端不存在、端口错误或跨命名空间没有合法授权时，TCPRoute 可能仍被接受，但连接必须被拒绝；这说明“对象存在”不能代替“后端可用”。

验收顺序可以固定为：先在非生产 Gateway 创建 v1 小样本，再用明确的 TCP 客户端验证连接方向，最后观察控制器事件和后端连接数，确认没有旧路由抢流。只有状态条件、连接结果和监控观测三者一致，才把剩余规则分批替换。这个节奏也能把控制器实现差异留在灰度阶段，而不是在全量切换后才暴露。

常见问题

TCPRoute 升级到 v1 后，旧 v1alpha2 对象必须立刻删除吗？

不应直接删除。先确认控制器和 CRD 的迁移支持，再把对象转换到 v1，并保留可回滚的清单；v1alpha2 已 deprecated，未来会移除，但切换时机仍取决于实现和集群发布节奏。

为什么 TCPRoute 和 UDPRoute 可以使用同一个端口？

TCP 和 UDP 是不同传输协议，控制器可以为同一数字端口分别建立 TCP、UDP listener；检查时仍要分别核对协议、Route kind 和后端 Service。

看到 Accepted=True 就能判断入口已经可用吗？

不能。Accepted 只说明路由附着关系成立，还要看 ResolvedRefs、Service endpoints 和真实连接结果；后端引用无效时，连接可能按规范被拒绝。