Ambassador API Gateway：雲端原生 API 管理方法
在微服務和雲端原生應用的時代，API Gateway 在管理和保護服務之間的通信方面發揮著至關重要的作用。Ambassador API Gateway 作為 Kubernetes 原生解決方案而廣受歡迎，能夠高效處理 API 流量。本文將探討 Ambassador 的關鍵功能、其架構以及與傳統 API Gateway 的比較。
什麼是 API Gateway？
API Gateway 充當微服務的入口，提供以下核心功能：
- 身份驗證與授權 – 透過 OAuth、JWT 或 API 金鑰來管理存取控制。
- 流量管理 – 路由、負載平衡和速率限制。
- 安全性 – TLS 終止、請求驗證和防止攻擊。
- 可觀察性 – 記錄、追蹤和監控 API 使用情況。
傳統的 API Gateway（如 Kong、Apigee 和 AWS API Gateway）廣泛應用於單體和混合架構。然而，Kubernetes 原生應用需要更動態、可擴展且適合 DevOps 的解決方案——這正是 Ambassador 發揮作用的地方。
介紹 Ambassador API Gateway
Ambassador 是基於 Envoy 的 API Gateway，專為 Kubernetes 設計。它作為 Ingress 控制器，促進 北-南（外部）流量 管理。
Ambassador 的關鍵功能
- Kubernetes 原生
- Ambassador 專為 Kubernetes 打造，使用自訂資源定義（CRDs）進行配置，而非傳統的靜態配置文件。
- 基於 Envoy Proxy
- Ambassador 採用 Envoy Proxy 作為核心，從其先進的網路功能、彈性和可擴展性中受益。
- 去中心化配置
- 與單體 API Gateway 不同，Ambassador 允許微服務團隊獨立配置路由和策略。
- 身份驗證與安全性
- 支援 OAuth2、JWT 驗證和外部身份驗證服務。
- 實施 mTLS（雙向 TLS），確保服務間安全通信。
- 流量控制與速率限制
- 提供先進的 負載平衡、熔斷機制和故障轉移策略。
- 實施 速率限制，防止濫用並確保公平使用。
- 可觀察性與監控
- 無縫整合 Prometheus、Grafana 和 OpenTelemetry 以獲取即時洞察。
- 內建 分佈式追蹤 支援，如 Jaeger 和 Zipkin。
Ambassador API Gateway 的運作方式
1. 部署架構
- Ambassador 以 Kubernetes 部署 運行，通常透過 Kubernetes Service 曝露。
- 它與 Ingress Controllers（如 NGINX 或 Kubernetes API Server）集成，管理外部流量。
- 每個微服務都可以透過 Kubernetes 註解或 CRD 定義自己的路由規則。
2. 流量路由範例
以下是使用 AmbassadorMapping CRD 配置微服務路由的示例：
apiVersion: getambassador.io/v3alpha1
kind: Mapping
metadata:
name: my-service
spec:
prefix: /my-api/
service: my-service.default.svc.cluster.local:8080
timeout_ms: 5000
此配置確保 /my-api/ 的請求被路由到運行於 8080 端口的 my-service。
3. 身份驗證範例
要整合 JWT 身份驗證，可以定義以下配置：
apiVersion: getambassador.io/v3alpha1
kind: AuthService
metadata:
name: jwt-auth
spec:
auth_service: auth-service.default:443
proto: http
allowed_request_headers:
- "Authorization"
此設置確保所有傳入請求都必須包含有效的 JWT 令牌，才會被轉發到微服務。
Ambassador 與傳統 API Gateway 的比較
| 功能 | Ambassador | Kong | AWS API Gateway | Apigee |
|---|---|---|---|---|
| Kubernetes 原生 | ✅ 是 | ⚠️ 部分支援 | ❌ 否 | ❌ 否 |
| Envoy Proxy | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 |
| 基於 CRD 的配置 | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 |
| 身份驗證 | ✅ 是 | ✅ 是 | ✅ 是 | ✅ 是 |
| 可觀察性 | ✅ Prometheus、Grafana | ✅ Kong Vitals | ✅ CloudWatch | ✅ Stackdriver |
| 無伺服器支援 | ⚠️ 限制 | ✅ 是 | ✅ 是 | ✅ 是 |
| 雲端原生整合 | ✅ 是 | ✅ 是 | ✅ 是 | ✅ 是 |
何時應使用 Ambassador API Gateway？
如果您的應用符合以下條件，Ambassador 會是一個絕佳選擇： ✅ 應用 Kubernetes 原生，並依賴微服務架構。 ✅ 需要 完全聲明式與 GitOps 友好的 API Gateway。 ✅ 需要 高效能 並基於 Envoy Proxy。 ✅ 需要 可擴展性，支援 動態路由和服務發現。
然而，如果您需要 深入的 API 商業化、細粒度分析或伺服器無 API 支援，傳統 Gateway（如 Apigee 或 AWS API Gateway）可能更合適。
結論
Ambassador API Gateway 提供了一個強大的 Kubernetes 原生解決方案，用於管理微服務架構中的 API 流量。憑藉其 Envoy 核心、去中心化配置 和 Kubernetes 的一流支援，它提供了一個可擴展且開發者友好的 API Gateway 替代方案。
如果您正在 Kubernetes 上運行微服務，並尋找一個高效可擴展的 API Gateway，Ambassador 絕對值得考慮！
您是否在 Kubernetes 設置中使用 Ambassador？歡迎在評論中分享您的經驗！