前言¶

Gateway API 是 Kubernetes SIG Network 社区推动的下一代服务网络 API，目标是替代 Ingress 在 HTTP/TLS 场景下的角色，并进一步统一 Ingress 与 Service Mesh 的路由表达。相比 Ingress 只覆盖七层 HTTP，Gateway API 采用角色导向的设计——基础设施运维、集群运维、应用开发者各管各的 CRD，语义也更贴近实际网关能力。

Gateway API 版本：v1.6.0（2026 年 6 月 30 日发布；Kubernetes 官方博客于 2026 年 8 月 3 日解读）

在 v1.6 之前，Gateway API 的 Standard 通道已经稳定支持 HTTPRoute、GRPCRoute 等 L7 路由，但数据库、DNS、VoIP、游戏、IoT 等依赖原始 TCP/UDP 协议的工作负载，要么退回普通 Service，要么绑定某个 Gateway 实现厂商的私有 CRD，跨控制器移植性很差。v1.6 的核心变化，就是把 TCPRoute 和 UDPRoute 从 Experimental 通道晋升到 Standard，API 版本迁移到 gateway.networking.k8s.io/v1，L4 负载均衡终于有了与 HTTPRoute 同级别的可移植标准。

本文基于 Kubernetes 官方博客 与 GitHub Release v1.6.0 核实要点，梳理 L4 路由 GA 的含义、配置方式，以及实验 API 组分离带来的演进路径。

TCPRoute 与 UDPRoute：L4 路由补齐最后一块拼图¶

解决了什么问题¶

在 v1.6 之前，Gateway API 只提供 HTTP 和 TLS 的稳定路由模型。TCP/UDP 裸协议流量没有可移植的 Gateway 接入方式——MySQL 集群、DNS 服务、SIP 中继、实时游戏协议，都落在这个空白里。

TCPRoute 和 UDPRoute 的语义很直接：只按协议和端口路由，不需要 L7 感知。流量从 Gateway Listener 进来，转发到 backendRefs 指定的 Service 端点，与 HTTPRoute 的 parentRefs + rules 结构一脉相承。

晋升 Standard 意味着什么¶

根据官方发布说明，两项资源在本版本中完成以下变更：

1. 从 Experimental 通道毕业，进入 Standard 通道，达到 GA 稳定性。
2. API 版本迁移到 gateway.networking.k8s.io/v1。
3. 旧版 v1alpha2 自 v1.6 起标记为 deprecated，未来版本将移除。

对应 GEP 编号：GEP-2644（TCPRoute）、GEP-2645（UDPRoute）。社区同步增加了 UDPRoute 一致性测试、GATEWAY-UDP 一致性 profile，以及 TCPRoute 的 SupportTCPRoute 特性标记，方便各 Gateway 控制器实现方对标验收。

TCPRoute 配置示例¶

Gateway 需要先声明允许 TCPRoute 挂载的 Listener：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: foo
      protocol: TCP
      port: 12345
      allowedRoutes:
        kinds:
          - kind: TCPRoute

TCPRoute 挂载到该 Listener，将流量转发到后端 Service：

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: tcp-app
spec:
  parentRefs:
    - name: example-gateway
      sectionName: foo
  rules:
    - backendRefs:
        - name: my-foo-service
          port: 6000

Gateway 的 12345 端口收到的 TCP 流量，会被代理到 my-foo-service 的 6000 端口端点。如果在 parentRefs 中省略 sectionName 和 port，路由会挂载到 Gateway 上所有 TCP Listener，而不是某一个。

UDPRoute 配置示例¶

UDPRoute 模式相同，只需把 Listener 协议和 Route 类型换成 UDP：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: foo
      protocol: UDP
      port: 12345
      allowedRoutes:
        kinds:
          - kind: UDPRoute
---
apiVersion: gateway.networking.k8s.io/v1
kind: UDPRoute
metadata:
  name: udp-app
spec:
  parentRefs:
    - name: example-gateway
      sectionName: foo
  rules:
    - backendRefs:
        - name: my-foo-service
          port: 6000

与 Ingress 演进、Service Mesh 统一路径¶

Gateway API 从设计之初就不只是「Ingress 2.0」。Ingress 只描述集群入口的 HTTP 路由；Gateway API 用 Gateway + Route 的组合，同时覆盖南北向入口和东西向 Mesh 场景。HTTPRoute 早已 Standard，Mesh 相关的 XMesh 等资源仍在实验通道推进；v1.6 把 L4 也纳入 Standard 后，同一个 Gateway 控制面可以同时管理 HTTPRoute、TCPRoute、UDPRoute，混合协议负载的集群不再需要 Ingress + 私有 L4 CRD + Mesh 策略三套体系并行。

对正在从 Ingress 迁移的团队，常见路径是：

1. 先用 HTTPRoute 替换 Ingress 的 HTTP 规则，Gateway 承担 TLS 终止。
2. 数据库、消息队列等 TCP 后端，逐步改用 TCPRoute，去掉实现绑定的 L4 注解或 CRD。
3. 若已部署 Service Mesh，Gateway API 的 Route 资源可与 Mesh 策略在同一 API 语义下协作，减少「入口一套、Mesh 一套」的配置分裂。

官方博客将 TCPRoute/UDPRoute 毕业定位为「让 Gateway API 成为跨 L4/L7 的完整、通用 Ingress 与 Mesh 网络 API」的关键里程碑，这个判断与上述迁移路径一致。

实验 API 组分离：XBackend 与 x-k8s.io¶

v1.6 的另一条主线，是实验资源与标准资源的 API 组边界彻底分开。

为什么要分家¶

此前，实验资源与标准资源共用 gateway.networking.k8s.io 组，仅靠 v1alpha2 这类版本号区分。TCPRoute 和 UDPRoute 是最后一批在该机制下毕业的资源。从今往后：

• Standard 资源继续留在 gateway.networking.k8s.io。
• 实验资源迁入独立组 gateway.networking.x-k8s.io，类型名加 X 前缀（如 XBackend、XMesh）。
• 实验资源毕业后，会去掉 X 前缀、迁入标准组——官方举例 XMesh 预期将来变为 Mesh。

这样在 API 组层面就能一眼区分「能进生产」与「还在迭代」，不再只依赖版本字符串。

XBackend 是什么¶

XBackend（GEP-4894）是 v1.6 引入的实验资源，作为 Service 等后端的 Gateway 原生装饰器。Kubernetes Service 稳定且灵活，但 Gateway API 很难在 Service 上安全地扩展某些概念——例如在 Service 里直接支持 ExternalName 存在 confused deputy 类安全风险。

XBackend 第一版支持 ExternalHostname 类型，指向集群外部的 FQDN，适合出站（Egress）场景，比如集群内 Agent 工作负载访问云侧 AI API。官方明确标注：XBackend 仍为实验性质，行为可能变化，不宜直接用于生产。

Gateway 侧 TLS 仍由 Gateway Listener 权威配置；XBackend 描述外部目的地：

apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XBackend
metadata:
  name: ai-provider-api
  namespace: ai-apps
spec:
  type: ExternalHostname
  externalHostname:
    hostname: api.ai-provider.com

HTTPRoute 引用 XBackend 而非 Service：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
spec:
  rules:
    - backendRefs:
        - name: ai-provider-api
          kind: XBackend
          group: gateway.networking.x-k8s.io

社区还在推进将 Session Persistence 等配置从 XBackendTrafficPolicy 合并进 XBackend，以及出站 Gateway 相关 GEP——值得关注，但尚未 Standard。

升级与落地建议¶

若你已在 Experimental 通道使用 v1alpha2 的 TCPRoute/UDPRoute，建议尽快迁移到 v1 API 版本，避免未来版本移除旧 API 时被动升级。

落地前请确认所用 Gateway 控制器是否通过 v1.6 一致性测试。官方博客发布时列出了当日已合规的实现清单，各厂商支持节奏不同，以 Gateway API 文档 与对应控制器 Release Note 为准。

安装 CRD 与控制器版本时，对齐 v1.6.0 Release Note 中的变更说明；GitHub 上 v1.6.1（2026 年 7 月 16 日）主要是测试与一致性修复，不影响上述 API 毕业结论。

小结¶

Gateway API v1.6 把 L4 路由从「实验能力」推进到「标准能力」，TCPRoute/UDPRoute 与 HTTPRoute 站在同一稳定性层级，Ingress 演进与 Service Mesh 统一 API 的路径更加清晰。实验创新则收敛到 gateway.networking.x-k8s.io 与 X 前缀命名，XBackend 为出站与外部后端提供了可扩展的试验田。

如果你维护的是混合 HTTP + TCP/UDP 的 K8s 集群，现在可以开始评估：哪些 Service 仍依赖厂商私有 L4 CRD，能否用 Standard 通道的 TCPRoute/UDPRoute 替换——这是 v1.6 最值得动手试的部分。