前言
之前聊過 Easegress 搭配 Kubernetes Gateway API 的基本玩法，這次想更進一步，分享一下怎麼在完全不動程式碼的前提下，光靠設定檔就能幫 K8s Gateway API 加上熔斷、限流、重試等進階功能。對我來說，這才是 Easegress 最吸引人的地方。
本文重點：不改任何一行程式碼，就讓 Kubernetes Gateway API 擁有彈力容錯（Resilience）的能力。
K8s Gateway API 為什麼需要被增強？
Easegress 本身就有很完整的彈性容錯機制，像是熔斷（Circuit Breaker）、限流（Rate Limiting）、重試（Retry）等等，這些都能有效保護後端服務。但如果你看目前 Kubernetes Gateway API 的標準規範，它主要聚焦在流量轉發、負載平衡、重新導向這些基本功能，對於後端服務的「保護」機制其實還沒有明確定義。
所以問題來了：怎麼讓 Gateway API 也具備這些保護能力？答案就是透過 Easegress 的擴充機制。
Easegress 架構一覽
先看一下 Easegress 整體的架構設計：
關鍵機制：ExtensionRef
Kubernetes Gateway API 提供了一個叫做 ExtensionRef 的擴充點，讓你可以在 HTTPRoute 裡面引用叢集中的自訂資源。這就是 Easegress 跟 Gateway API 之間的「黏合劑」。以下是一個 HTTPRoute 設定範例：
| 欄位 | 值 | 說明 |
|---|---|---|
| apiVersion | gateway.networking.k8s.io/v1 | Gateway API 版本 |
| kind | HTTPRoute | 路由類型 |
| filters.type | ExtensionRef | 使用擴充引用 |
| extensionRef.group | easegress.megaease.com | Easegress 資源群組 |
| extensionRef.kind | FilterSpec | 自訂資源種類 |
| extensionRef.name | rate-limiter | 引用的限流器名稱 |
Easegress Gateway Controller 會辨識這些 ExtensionRef 設定，並自動轉換成對應的 Easegress 組態，讓 HTTPRoute 瞬間擁有限流能力。
透過 CRD 整合 Easegress 功能
為了讓 Easegress 的進階功能跟 Kubernetes 無縫整合，我們會用 Custom Resource Definition（CRD）來定義擴充資源。相比直接用 ConfigMap，CRD 的影響範圍更小、彈性也更好。
CRD 只保留三個核心屬性：
| 屬性 | 說明 |
|---|---|
| name | Filter 的名稱（所有 Easegress Filter 通用） |
| kind | Filter 的類型（例如 RateLimiter、CircuitBreaker） |
| spec | Filter 的具體 YAML 配置 |
這樣的設計兼顧了相容性與簡潔性。
實戰：限流器 + 響應修改器
接下來用兩個實際的 Filter 來示範：RateLimiter（限流器）和 ResponseAdaptor（響應修改器）。
建立 FilterSpec 資源
限流器的設定：每 5 秒只允許 1 個請求通過。
| 設定項 | 值 | 意義 |
|---|---|---|
| kind | RateLimiter | 限流器類型 |
| limitRefreshPeriod | 5000ms | 限流重置週期 |
| limitForPeriod | 1 | 週期內允許請求數 |
| url prefix | / | 套用到所有路徑 |
響應修改器的設定：在 HTTP 回應中加上自訂 Header。
| 設定項 | 值 |
|---|---|
| kind | ResponseAdaptor |
| header.add | X-Eg-Response-Adaptor: "true" |
在 HTTPRoute 中引用
建立 HTTPRoute 時，只需要在 filters 區塊用 ExtensionRef 分別引用上面建立的限流器和響應修改器，Easegress Gateway Controller 就會自動把對應的能力掛載進去。
測試驗證
在 minikube 環境中，把 Gateway 的連接埠對應到 nodePort 30081，然後用 curl 測試：
| 請求次序 | HTTP 狀態碼 | 特殊 Header | 說明 |
|---|---|---|---|
| 第一次請求 | 200 OK | X-Eg-Response-Adaptor: true | ResponseAdaptor 生效，正常回應 |
| 第二次請求（5 秒內） | 429 Too Many Requests | X-Eg-Rate-Limiter: too-many-requests | RateLimiter 生效，請求被限流 |
結果很清楚：第一次請求正常回應且多了自訂 Header，第二次在限流週期內的請求直接被擋下回傳 429。
進階：熔斷器與重試策略
除了限流和響應修改，Easegress 當然也支援更進階的彈性容錯機制：
| Filter 類型 | 關鍵設定 | 說明 |
|---|---|---|
| CircuitBreaker（熔斷器） | slidingWindowType: TIME_BASED, failureRateThreshold: 60, slidingWindowSize: 200 | 基於時間窗口的熔斷，失敗率超過 60% 就觸發 |
| Retry（重試） | maxAttempts: 3, waitDuration: 500ms | 最多重試 3 次，每次間隔 500 毫秒 |
這些都可以透過同樣的 CRD + ExtensionRef 機制掛載到任何 HTTPRoute 上。
小結
透過 Easegress 的 Gateway Controller 搭配 Kubernetes Gateway API 的 ExtensionRef 擴充點，我們可以在不修改任何程式碼的情況下，輕鬆為 Gateway API 加上限流、熔斷、重試、響應修改等進階功能。這種做法的好處是：設定即功能，維護成本低，而且完全符合 Kubernetes 的聲明式管理哲學。
參考資源
- Kubernetes Gateway ExtensionRef 規範
- Easegress Gateway Controller 文件
- Easegress Filter 參考手冊
- Easegress 彈性容錯教學
發佈留言