#kubernetes#envoy-gateway#gateway-api#envoy-proxy#ingress

K8S Envoy Gateway 系列總覽：比 Ingress 更像現代人的流量入口

10 min read

如果你以前接觸 Kubernetes 對外流量，多半是從 Ingress 開始。它能用，而且很多場景真的夠用。但一碰到更複雜的需求，例如多 listener、多團隊分工、gRPC、TCP、TLS passthrough、精細流量政策，常常就會變成「靠 annotation 撐世界」的局面，最後 YAML 長得像咒語，維運的人也像在解封印。

這時候，Gateway API + Envoy Gateway 就很像新版裝備。它不是把事情搞更複雜，而是把原本混在一起的責任拆清楚，讓入口流量、路由規則、TLS 安全設定、協定類型與團隊分工都比較好理解。

它到底是什麼

先用一句白話講完：

  • Envoy Proxy：真正接流量、轉送請求的資料面，也可視為 Gateway Proxy
  • Envoy Gateway：幫你管理 Envoy Proxy 的控制平面
  • Gateway API：你在 Kubernetes 裡宣告流量規則的標準介面

可以把它想成：

  • Gateway API 是你寫需求單
  • Envoy Gateway 是負責翻譯與派工的主管
  • Envoy Proxy 是真的在門口站崗的保全

這樣拆開的好處是，你不用直接手刻低階 Envoy 設定，也不需要再把各種控制器私有 annotation 背到滾瓜爛熟。你宣告的是 Kubernetes 資源，Envoy Gateway 會幫你把它們翻譯成 Envoy Proxy 真正能執行的設定。

Gateway vs Ingress：差在哪裡

先講結論：Ingress 沒有過時，但 Gateway API 更適合中大型、需要進一步治理的場景。

比較項目 Ingress Gateway API
入口資源模型 大多把入口與路由寫在同一個物件 把 GatewayClass、Gateway、Route 拆開
表達能力 以 HTTP/HTTPS 為主，進階需求常靠 annotation 原生支援多種 route 類型與更清楚欄位
擴充方式 很多能力仰賴不同 controller 的私有 annotation 有標準欄位，也允許實作方提供 CRD 擴充
協定支援 多數聚焦 Web/HTTP 可處理 HTTPRoute、GRPCRoute、TCPRoute、TLSRoute
團隊分工 比較容易把平台與應用設定混在一起 更適合平台團隊管入口、應用團隊管路由
可攜性 annotation 常與特定 controller 綁死 標準化程度更高，跨實作可讀性較好

如果你的需求只是：

  • 單一網站或簡單 API
  • 基本 path/host 路由
  • 團隊規模不大

那 Ingress 還是能打。但如果你的需求開始包含：

  • 一個入口要服務多個協定
  • 多 listener、多網域、多憑證
  • HTTP 和 gRPC 並存
  • 想把平台入口和應用路由拆權限
  • 想讓設定更像正式 API，而不是 annotation 許願池

那 Gateway API 就會開始顯得很香。

為什麼不是只用 Ingress

官方 Gateway API 的目標，就是解決 Ingress 在大型場景常見的幾個痛點：

  • 表達力更好：路由、TLS、流量政策、協定類型更清楚
  • 可攜性更高：少一點綁死某家 controller 的私房 annotation
  • 角色分工更自然：平台團隊管入口，應用團隊管路由

舉例來說，Ingress 常常會長這樣：

metadata:
  annotations:
    some.ingress.controller/rewrite-target: /
    some.ingress.controller/auth-type: basic
    some.ingress.controller/ssl-redirect: "true"

不是說它不能用，而是當需求變多時，annotation 很容易變成 YAML 版神祕黑魔法。Gateway API 比較像把這些需求拉回正式欄位，讀起來更像「設定」，不是「許願池」。

這套東西的分層結構

官方概念頁把 Envoy Gateway 分成三層，這個腦圖值得先記住：

  • User Configuration：你寫的 Gateway API 與 Envoy Gateway 擴充 CRD
  • Envoy Gateway Controller：讀取這些資源，轉換成可執行設定
  • Envoy Proxy：真正接住線上流量的資料面

也就是說，平常你大部分時間是在改「上層宣告」，不是直接 SSH 進代理層改低階設定。這就是 Kubernetes-native 的舒服之處。

你會在這個系列學到什麼

這套系列現在會照「先做出來，再變強」的順序走，包含這篇總覽在內總共 10 篇：

  1. 快速上手：先把 Envoy Gateway 裝起來，跑通第一條 HTTP 流量
  2. 核心概念：搞懂 GatewayClass、Gateway、Listener、Envoy Proxy
  3. HTTP 路由實戰：深入 HTTPRoute 的 host、path、header、filter、timeout
  4. TLS 與安全：把 HTTPS 接起來，理解 certificateRefs、TLS termination、TLSRoute
  5. 最佳實踐：整理正式上線前該有的習慣
  6. Route 類型速查表：快速判斷 HTTPRoute、GRPCRoute、TCPRoute、TLSRoute 怎麼選
  7. Listener 設計指南：學會多 port、多 hostname、多入口的拆法
  8. 多 Namespace 與團隊分工：掌握 allowedRoutes、ReferenceGrant 與共享入口治理
  9. 狀態與除錯手冊：讀懂 Accepted、ResolvedRefs、Programmed 與最短排錯流程

如果你只是想先感受一下 Envoy Gateway 的手感，直接去下一篇就好。先跑起來，比先把所有名詞背完更重要，這跟健身一樣，先進場比先研究 30 支 YouTube 影片更有用。

你會遇到的核心資源

初學者最容易卡住的點，是以為 Gateway API 只有 Gateway 跟 HTTPRoute。其實它是一整個資源家族。

GatewayClass

定義「這個叢集要用哪個 Gateway 實作」。
對 Envoy Gateway 來說，核心是 controllerName 要指向正確的 controller。

Gateway

定義「入口長什麼樣」。
例如要開哪個 port、聽哪個 protocol、TLS 怎麼掛、允許哪些 route 附掛。

Listener

Listener 是 Gateway 裡最重要的單位之一。
你可以把它想成 Gateway 上的一個對外插槽，每個插槽會定義：

  • port
  • protocol
  • hostname
  • TLS 設定
  • allowedRoutes

很多人把 Gateway 想成一個黑盒子，但實際上真正決定入口行為的，通常是裡面的每個 listener。

Route 家族

  • HTTPRoute：HTTP/HTTPS 流量，最常用
  • GRPCRoute：gRPC 流量，能以 service/method 為匹配條件
  • TCPRoute：原始 TCP 流量，不解析 HTTP 語意
  • TLSRoute：根據 TLS SNI 做路由，常見於 TLS passthrough 場景

這些 route 的共通點都是：
它們不負責「開門」，而是負責「進門後怎麼分流」。

最小心智模型

先記住這張腦內地圖：

GatewayClass  # 這個叢集要用哪一種 Gateway 實作
Gateway       # 這個入口開哪些 listener
Listener      # 某個 port / protocol / hostname / TLS 插槽
Route         # 進來後要怎麼分流
Service       # 叢集內真正提供服務的後端
Envoy Proxy   # 最終實際承接流量的資料面

最小範例長這樣：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo
spec:
  parentRefs:
    - name: eg
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - name: backend
          port: 3000

你現在不用把每個欄位都背起來，只要先知道它在做什麼：

  • parentRefs：這條規則要掛到哪個 Gateway
  • hostnames：哪個網域進來要吃這條規則
  • backendRefs：最後要送到哪個 Service

一眼看懂什麼時候用哪個 Route

需求 建議資源
網站、REST API、Header / Path 路由 HTTPRoute
gRPC service / method 路由 GRPCRoute
純 TCP 服務，例如自訂協定或非 HTTP 服務 TCPRoute
想保留端到端 TLS，加密流量不在 Gateway 解開 TLSRoute

這個判斷方式很實用。看到需求先別急著寫 YAML，先問自己一句：

「我現在在處理的是 HTTP、gRPC，還是單純 TCP / TLS 流量？」

一句話總結

Envoy Gateway 不是另一個你非學不可的新名詞，而是把 Kubernetes 對外流量這件事，從「能用就好」提升到「比較像工程系統」的做法。

💡 如果你是第一次碰這套東西，不要一開始就想把所有 CRD 全學完。先裝起來、先打通第一個請求，再回頭看概念，吸收會快很多。

下一步

下一篇直接動手，把 Envoy Gateway 裝到叢集裡，跑通第一個 Gateway + HTTPRoute： 👉 快速上手