Redesigning Ingress: Docker 的 Ingress 系統遷移實踐與技術解析

引言

在雲原生架構快速演進的背景下，Ingress 系統作為 Kubernetes 中流量管理的核心組件，其效能與靈活性直接影響服務的可擴展性與穩定性。Docker 在遷移其 Ingress 系統時，面臨舊有架構的瓶頸與技術挑戰，最終選擇以 Envoy Gateway 為核心，結合 Open Telemetry 與 XDS 標準，重新設計整體流量管理方案。本文將深入解析此遷移過程的技術細節與關鍵決策。

主要內容

技術或工具的定義與基本概念

Ingress 系統 是 Kubernetes 中用於管理外部流量訪問內部服務的組件，傳統方案常依賴 HAProxy 或 EngineX 等代理工具，但隨著服務規模擴張，其限制逐漸顯現。

Envoy Gateway 是 CNCF 認證的開源項目，作為 Kubernetes 原生的 Ingress 控制器，提供動態 XDS 配置、豐富的路由模型與自服務路由能力。其核心元件 Envoy Proxy 作為數據平面，負責流量轉發與策略執行，而 Envoy Gateway 則作為控制平面，管理路由策略與配置生成。

重要的特性或功能

1. 動態 XDS 配置：Envoy Gateway 支援透過 Gateway API 進行實時配置更新，避免傳統控制檯的高可用性風險。

2. Open Telemetry 整合：提供全鏈路追蹤與觀察性能力，解決 HAProxy 無支援 Open Telemetry 的缺陷。

3. 金絲雀部署與流量切換：透過 AWS ALB 的權重路由機制，實現灰度部署與即時回滾，降低遷移風險。

4. 策略校驗與安全機制：利用 OPA Agent 驗證路由配置，防止重複域名/路徑等錯誤，並透過 Envoy Admin Console 限制遠端寫入端點。

實際的應用案例或實作步驟

1. 網絡層遷移：

   • 從 NLB（L4）遷移至 ALB（L7），使用 Route 53 DNS 權重調整逐步切換。
   • 調整應用層以處理 ALB 新增的 X-Forwarded-For 頭部 IP 地址。

2. 配置管理：

   • 使用 Helm Chart 管理路由配置，透過 Kubernetes 註解定義流量規則（如 http.route 與 trafficPolicy）。
   • 支援 Canaries 部署：例如 90% 流量保留 HAProxy，10% 導向 Envoy。

3. 關鍵技術整合：

   • 速率限制：使用 Envoy Rate Limiter（Go 服務）與 XDS 動態配置。
   • 觀察性：整合 Open Telemetry 與 Envoy 原生追蹤能力。

該技術的優勢與挑戰

優勢：

• 性能提升：吞吐量提升 4 倍，核心資源使用減少 50%。
• 可靠性增強：LB 切換與控制平面分離降低故障風險。
• 資源優化：減少 Sidecar 與代理層次，降低運維複雜度。

挑戰：

• Gateway API 限制：部分功能（如全球速率限制、IP 標籤）需透過 XDS Patch Policy 手動擴展。
• 金絲雀部署複雜性：需自建解決方案分離數據平面與控制平面，Argo CD 需手動複製配置物件。
• Envoy Admin Console 安全機制：無遠端安全存取功能，需透過 Port Forward 排查，限制寫入端點防止誤操作。

總結

Docker 的 Ingress 系統遷移案例展現了 Envoy Gateway 在現代雲原生架構中的關鍵角色。透過整合 XDS 標準、Open Telemetry 與 Gateway API，該方案有效解決了傳統 HAProxy 與 EngineX 的瓶頸，並提升系統的可觀察性與靈活性。然而，遷移過程中的 Gateway API 侷限與金絲雀部署複雜性，仍需透過 XDS Patch Policy 與控制平面擴展進行補強。未來，隨著 Envoy Gateway 的持續演進，其在 Kubernetes 生態中的影響力將進一步擴張。