Emissary Ingress 4.0：雲原生網關的演進與社區驅動未來

引言

在雲原生架構快速演進的背景下，服務於 Kubernetes 的 API 網關技術持續革新。Emissary Ingress 作為一個開源項目，專注於解決集群內外通訊的關鍵問題，並透過持續版本迭代與社區協作，逐步成為雲原生生態系的重要組成部分。本文將深入探討 Emissary Ingress 的技術特性、版本演進路徑，以及其在 CNCF 生態中的定位與未來方向。

技術定義與核心概念

Emissary Ingress 是一個基於 Kubernetes 的 API 網關解決方案，主要功能為提供集群內資源的外部訪問能力。其設計目標包含：

• 解決 Ingress 問題：透過安全的通訊協議，讓外部用戶訪問集群內服務。
• API Gateway 功能：支援路由、認證授權、流量分割、金絲雀發佈、重試、熔斷、限流等高階功能。
• 開發者導向設計：提供自服務且角色分離的意見導向式配置語言，降低使用門檻。

作為 CNCF 生態系的一部分，Emissary Ingress 的設計與實作嚴格遵循雲原生架構標準，並透過社區協作持續優化。

技術特性與功能

1. 基於 Kubernetes CRD 的設計

Emissary Ingress 透過 Kubernetes Custom Resource Definitions（CRD）實現配置管理。早期版本（V1/V2）因未遵循 CRD 規範，導致後續版本需透過轉換 Webhook 解決兼容性問題。現行版本（3.10.0）為 Emissary 3 系列的最終版本，已逐步解決舊版問題，例如移除下劃線、標準化時間單位等。

2. Gateway API 的整合

Emissary Ingress 支援 Gateway API（尚未完全實現），未來可能作為轉換層，取代現有的 Envoy 組件。此設計方向有助於與 CNCF 推廣的 Gateway API 標準對接，提升生態系兼容性。

3. 開發者友好性

項目強調簡化配置語言，避免過於複雜的設定。透過意見導向式配置，開發者可快速建立與調整 API 網關行為，同時降低學習曲線。

4. 端點處理與授權模型

Emissary Ingress 支援 Endpoint Slices，並在 V4 版本中兼容不同端點類型。其授權模型為開放源碼，無企業版授權，與 Ambassador Edge Stack 的商業模式形成對比。

版本演進與挑戰

V1/V2 的問題

早期版本（V1/V2）因未遵循 CRD 規範，導致後續版本需透過轉換 Webhook 解決兼容性問題，增加維護成本。

V3 的遷移與成本

V3 alpha1 引入 CRD 轉換 Webhook，但導致維護成本上升。此階段的設計目標為解決舊版問題，並為 V4 做準備。

V4 的遷移計畫

V4 版本的關鍵變更包括：

• 新 API 組（需移除 ambasador.io 域名）
• 支援同時運行 V3/V4（透過不同 API 組）
• 移除無用 CRD 轉換代碼
• 修復舊版問題（如標準化時間單位）

此遷移計畫旨在降低維護成本，並提升與 Gateway API 的整合能力。

版本混淆問題

過去因 Ambassador Edge Stack 發布錯誤的 3.12.2 鏡像，導致 Emissary 的 artifact 被誤標，造成版本混淆。此問題已透過遷移至 GHCR（GitHub Container Registry）解決，確保未來版本管理的穩定性。

未來方向與社區參與

Emissary 4.0.0 的目標

• 完成 CRD 組遷移
• 支援 Gateway API（可能取代 Envoy）
• 提供工具協助版本遷移

Ingress EngineX 轉 Ingate

Ingate 基於 Gateway API 開發，可能推動 Gateway API 功能的完善，並與 Emissary Ingress 形成協同效應。

社區驅動的維護

Emissary Ingress 已完全脫離 Ambassador Labs，成為獨立社區專案。未來需更多開發者參與維護與功能開發，並透過 CNCF Slack 協作（舊 Ambassador Lab Slack 已停用）。

總結

Emissary Ingress 透過持續版本迭代與社區協作，逐步成為雲原生生態系的重要組成部分。其 V4 版本的遷移計畫與 Gateway API 整合，將進一步提升其作為 API 網關的競爭力。開發者應關注官方鏡像倉庫（GHCR）的版本管理，並參與社區協作，以確保技術的持續演進與穩定性。