前言¶

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 最值得動手試的部分。