系列：《Kubernetes 入口流量的 2026 新標準：Gateway API × Envoy Gateway × Traefik × Istio Ambient》
Kubernetes 把叢集內部的服務發現與負載平衡解決得很完整，但「流量如何從叢集外進來」這一題，長期缺少一個能同時滿足可攜性、權限模型與協定覆蓋的規格層答案。
Gateway API 是這個問題的現行答案。它在 2026 年 4 月發布 v1.5，多項功能進入 Stable，並且已有十餘個通過一致性測試的實作。
這 30 天要處理的核心問題不是「有沒有新東西」，而是三件更具體的事：這套規格的架構設計解決了什麼、各實作的取捨差在哪裡、以及可攜性到底能兌現到什麼程度。
Gateway API 的設計可以歸納成三個決策，它們彼此支撐。
GatewayClass ← 叢集管理員：叢集提供哪幾種入口、由誰實作
↑ 被引用
Gateway ← 平台團隊：對外埠號、TLS 憑證、網域邊界、誰能綁上來
↑ 被綁定
HTTPRoute ← 應用團隊：自己服務的路徑匹配與後端指向
拆分的理由是 RBAC 的授權粒度。RBAC 的最小單位是資源，若不同角色關心的設定共存於同一個資源，授權就無法切開——給了寫入權限，應用團隊同時就能改動 TLS 設定與網域宣告。
拆開之後，三個角色各自 apply 自己的檔案，互不干擾。搭配的雙向同意機制是：Route 用 parentRefs 主動指名綁定對象，Gateway 用 allowedRoutes 宣告接受哪些 namespace，兩邊都同意才成立。
這是整套規格中最具實質影響的設計。Day 4 拆解模型，Day 10 用三份受限的 kubeconfig 實測權限確實切開。
路徑改寫、標頭注入、流量鏡像、權重分流——這些行為在 Gateway API 中都是有 schema 的型別化欄位：
rules:
- matches:
- path:
type: PathPrefix
value: /api
filters:
- type: URLRewrite
urlRewrite:
path:
type: ReplacePrefixMatch
replacePrefixMatch: /
backendRefs:
- name: api-v1
port: 8080
weight: 90
- name: api-v2
port: 8080
weight: 10
型別化帶來四項具體收益：API Server 在套用當下就能擋下錯誤、編輯器能補全、kubectl explain 可直接查詢、以及最重要的——匹配語意由規格明文定義，因此同一份設定換到另一個實作會得到相同的路由結果。
規格涵蓋不到的進階功能（限流、JWT 驗證、熔斷）則交給 Policy Attachment 機制：規格定義附著方式，各實作定義自己的 Policy CRD。取捨很清楚——核心路由邏輯可攜，進階功能不可攜。
| 資源 | 用途 | 發布通道 |
|---|---|---|
HTTPRoute |
HTTP / HTTPS 路由 | Standard |
GRPCRoute |
gRPC，理解 service/method 語意 | Standard |
TLSRoute |
依 SNI 路由，不解密 | Experimental |
TCPRoute |
任意 TCP | Experimental |
UDPRoute |
任意 UDP | Experimental |
五種 Route 綁到同一個 Gateway，共用同一套 listener 與權限判定。對外開放一個 Redis 不需要學另一套資源模型。
Day 2 會把這三個決策背後的架構約束完整推導一遍。
30 天無法涵蓋所有實作。本系列選了三個，因為它們代表三種不同的架構取向。
ClientTrafficPolicy / BackendTrafficPolicy / SecurityPolicy）已成為業界參考範本底層的 Envoy 是目前最主流的 L7 代理，Istio、Cilium、kgateway、Consul 的資料平面都是它。因此 Day 5-10 的六天規格深潛以 Envoy Gateway 進行——這六天學到的規格知識，換任何實作都適用。
IngressRoute CRD本系列針對 2026 年的新叢集，只涵蓋 ambient mode，sidecar mode 於 Day 21 以對照表交代。
當後端從 REST API 變成 LLM 推論服務時，傳統 Gateway 的假設會全面失效：
| 假設 | 傳統 API | LLM 推論 |
|---|---|---|
| 請求時長 | 毫秒 | 秒到分鐘 |
| 回應形式 | 一次回完 | 串流 |
| 成本計算單位 | 請求數 | token 數 |
| 負載平衡策略 | round-robin 可用 | round-robin 是災難 |
最後一項是關鍵。不同推論後端的 KV cache 命中率、佇列深度、GPU 記憶體狀態差異極大，隨機分配等同於浪費算力。
Kubernetes 社群的答案是 Gateway API Inference Extension（GIE）：透過 Envoy 的 ext-proc 機制，讓一個 Endpoint Picker 介入路由決策，把請求導向最合適的推論後端。
2026 年的現況：
InferencePool 已升到 v1，API group 從 inference.networking.x-k8s.io 移至 inference.networking.k8s.io
InferenceModel 在 v1.2 更名為 InferenceObjective
Day 27-29 會完整實作這一套。GIE 是 Gateway API 的官方擴充，屬於同一條主線的自然延伸。
iThome鐵人賽
看影片追技術