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？歡迎在評論中分享您的經驗！