Gateway API v1.6：TCPRoute和UDPRoute成为标准
内容提要
Kubernetes Gateway API v1.6.0发布，新增TCPRoute和UDPRoute标准路由，支持L4协议，并引入实验性XBackend资源，用于外部主机名等场景。实验资源移至独立API组，明确边界。该版本提升服务网络通用性，获广泛实现支持。
延伸解读
L4路由标准化的意义
TCPRoute和UDPRoute成为标准路由，意味着Kubernetes用户现在可以用统一的API处理数据库、DNS、VoIP等基于L4协议的工作负载，无需依赖特定实现或回退到普通Service。这提升了服务网络的通用性和可移植性，使得跨不同Gateway控制器的配置更加一致。
XBackend的引入与安全考量
XBackend作为实验性资源，支持ExternalHostname目标，用于出口场景（如访问外部AI API）。但该功能被标记为Extended/Optional，因为存在混淆代理攻击风险。用户需理解安全权衡后选择启用，且XBackend行为可能变化，不宜用于生产环境。
实验与标准API的清晰划分
新实验资源被移至独立的gateway.networking.x-k8s.io API组，并采用X前缀命名，如XBackend和XMesh。这改变了以往仅靠版本号区分实验与标准的方式，使边界在API组层面显式化。未来实验资源毕业为标准时，将重命名并移入标准组，如XMesh预计变为Mesh。
Q&A
Gateway API v1.6.0 新增了哪些标准路由类型？
Gateway API v1.6.0 新增了 TCPRoute 和 UDPRoute 作为标准路由类型，用于支持第四层（L4）协议的路由，例如数据库、DNS、VoIP、游戏和 IoT 遥测等原始 TCP/UDP 流量。
TCPRoute 和 UDPRoute 在 Gateway API 中如何工作？
TCPRoute 和 UDPRoute 通过监听器（listener）和路由规则将流量转发到后端服务。例如，在 Gateway 中定义一个 TCP 监听器，然后创建 TCPRoute 并指定 parentRefs 指向该监听器，再通过 backendRefs 指定后端服务和端口。流量到达 Gateway 的指定端口后，会被代理到后端服务的对应端口。
Gateway API v1.6.0 中 XBackend 资源的作用是什么？
XBackend 是 Gateway API v1.6.0 引入的实验性资源，用于扩展后端类型，支持 Service 之外的目标，例如外部主机名（ExternalHostname）。它旨在解决 Service 的灵活性和稳定性带来的限制，并支持出口（egress）场景，如访问外部 AI API。
Gateway API 中实验性资源和标准资源如何区分？
从 v1.6.0 开始，实验性资源被移至独立的 API 组 gateway.networking.x-k8s.io，并且 API 类型名称带有 X 前缀（如 XBackend、XMesh）。当实验性资源毕业为标准资源时，会移入标准 API 组 gateway.networking.k8s.io 并去掉 X 前缀。这种分离使得实验与标准的边界更加明确。
TCPRoute 和 UDPRoute 从实验到标准的过程是怎样的？
TCPRoute 和 UDPRoute 在 v1.6.0 中从实验通道毕业为标准，并移至 v1 API 版本。同时，v1alpha2 版本被弃用，并将在未来版本中移除。
Gateway API v1.6.0 对服务网络通用性有何意义？
Gateway API v1.6.0 通过将 TCPRoute 和 UDPRoute 标准化，扩展了对第四层协议的支持，使得原本只能使用 Kubernetes Service 或特定实现 CRD 的原始 TCP/UDP 工作负载，现在可以以可移植的方式接入 Gateway。这标志着 Gateway API 向成为完整的、通用的服务网络 API 迈出了重要一步，覆盖了 L4 和 L7 协议。
