搭配 Azure Kubernetes Service 中部署的微服務使用 Azure APIM
適用於：所有 API 管理 層
微服務相當適合用來建置 API。 使用 Azure Kubernetes Service (AKS)，您可以在雲端中快速部署和操作微服務架構。 然後，您可以利用 Azure API 管理 (API 管理)，將微服務發佈為內部與外部取用的 API。 本文說明使用 AKS 部署 API 管理的選項。 這是以已經具備 Kubernetes、API 管理和 Azure 網路的基本知識為前提。
背景
將微服務發佈為取用的 API 時，管理微服務與取用微服務的用戶端之間的通訊可能很困難。 有許多跨領域考量，例如驗證、授權、節流、快取、轉換和監視。 無論微服務是否公開給內部或外部用戶端，這些考量都適用。
API 閘道模式可解決這些疑慮。 API 閘道可作為微服務的前端、將用戶端與您的微服務分離、增加另一層安全性，並藉由消除處理跨領域考量的負擔來降低微服務的複雜度。
Azure API 管理是解決 API 閘道需求的周全解決方案。 您可以快速為您的微服務建立一致的新式閘道，並將其發佈為 API。 作為完整的生命週期 API 管理解決方案，它也提供額外的功能，包括 API 探索、API 生命週期管理和 API 分析的自助開發人員入口網站。
一起使用時，AKS 和 API 管理提供平台來部署、發佈、保護、監視及管理微服務 API。 本文將探討一些搭配 APIM 部署 AKS 的選項。
Kubernetes 服務和 API
在 Kubernetes 叢集中，容器會部署在 Pod 中，這是暫時性，而且有生命週期。 背景工作節點消失時，節點上執行的 Pod 就會遺失。 因此，Pod 的 IP 位址可以隨時變更。 我們無法依賴它來與 Pod 通訊。
為了解決此問題，Kubernetes 引進服務的概念。 Kubernetes Service 是抽象層，可定義 Pod 的邏輯群組，並啟用這些 Pod 的外部流量暴露、負載平衡和服務探索。
當我們準備透過 API 管理將微服務發佈為 API 時，我們必須考量如何將 Kubernetes 中的服務對應至 API 管理中的 API。 沒有設定的規則。 這取決於您一開始設計業務功能或網域並將其分割成微服務的方式。 例如，如果服務背後的 Pod 負責指定資源 (例如，客戶) 上的全部作業，服務可能會對應至一個 API。 如果資源上的作業會分割成多個微服務 (例如 GetOrder、PlaceOrder)，可能就會以邏輯方式將多個服務彙總成 APIM 中的單一 API (請見圖 1)。
對應也可以演進。 由於 APIM 會在微服務前面建立外觀，因此，可讓我們隨時間重構微服務並調整為最適大小。
在 AKS 前面部署 API 管理
在 AKS 叢集前面部署 API 管理有一些選項。
雖然 AKS 叢集一律部署在虛擬網路 (VNet) 中，但不需要在 VNet 中部署 APIM 執行個體。 若 APIM 不在叢集 VNet 內，AKS 叢集就必須發佈公用端點，APIM 才能連線。 在此情況下，必須保護 APIM 與 AKS 之間的連線。 換句話說，我們需要確保叢集只能透過 API 管理進行獨佔存取。 讓我們瀏覽這些選項。
選項 1：公開服務
AKS 叢集中的服務可以使用 NodePort、LoadBalancer 或 ExternalName 的服務類型公開。 在此情況下，服務可以直接從公用網際網路存取。 在叢集前面部署 API 管理之後，我們必須在微服務中套用驗證，以確保所有輸入流量都會通過 API 管理。 例如，API 管理可以在對叢集提出的每個要求中包含存取權杖。 每個微服務都會負責在處理要求之前驗證權杖。
這可能是在 AKS 前面部署 API 管理最簡單的選項，特別是當您已在微服務中實作驗證邏輯時。
優點：
- APIM 端的設定相當簡單，因為不需要插入到叢集 VNet
- 如果服務已公開且驗證邏輯已存在於微服務中，則 AKS 端不會有任何變更
缺點：
- 端點公開可見度所造成的潛在安全性風險
- 輸入叢集流量沒有單一進入點
- 由於重複驗證邏輯造成微服務的複雜度
選項 2：安裝輸入控制器
雖然選項 1 可能比較容易，但是有值得注意的上述缺點。 如果 APIM 執行個體不在叢集 VNet 中，則相互 TLS 驗證 (mTLS) 是一種強固的方式，可確保 APIM 執行個體與 AKS 叢集之間的雙向流量安全且受信任。
API 管理原生支援相互 TLS 驗證，而且可以安裝輸入控制器 (圖 3)，以在 Kubernetes 中啟用。 因此，驗證會在輸入控制器中執行，以簡化微服務。 此外，您可以透過輸入將 API 管理的 IP 位址新增至允許清單，以確保只有 API 管理才能存取叢集。
優點：
- APIM 端的設定相當簡單，因為不需要插入到叢集 VNet，且原生支援 mTLS
- 集中保護輸入控制器層的輸入叢集流量
- 藉由將公開可見的叢集端點降至最低，以降低安全性風險
缺點：
- 增加叢集設定的複雜度，因為需要額外安裝、設定和維護輸入控制器並管理用於 mTLS 的憑證
- 輸入控制器端點的公開可見度造成的安全性風險
當您透過 APIM 發佈 API 時，使用訂用帳戶金鑰安全地存取這些 API 是簡單且常見的方式。 需要使用已發佈 API 的開發人員在呼叫這些 API 時，必須在 HTTP 要求中包含有效的訂用帳戶金鑰。 否則，呼叫會立即遭到 APIM 閘道的拒絕。 這些呼叫並不會轉送到後端服務。
若要取得用於存取 API 的訂用帳戶金鑰，則需要訂用帳戶。 訂用帳戶基本上是一組訂用帳戶金鑰的具名容器。 需要取用已發行 API 的開發人員可以取得訂用帳戶。 而且不需要 API 發行者的核准。 API 發行者還可以為 API 取用者直接建立訂用帳戶。
選項 3：在叢集 VNet 內部署 APIM
在某些情況下，有法規限制或嚴格安全性需求的客戶可能會發現，選項 1 和 2 由於公開的端點而不是可行的解決方案。 此外，AKS 叢集和取用微服務的應用程式可能位於相同的 VNet 內，因此沒有理由公開地公開叢集，因為所有 API 流量都將保留於 VNet 內。 在這些案例中，您可以將 API 管理部署到叢集 VNet。 API 管理開發人員和進階層支援 VNet 部署。
將 API 管理部署至 VNet有兩種模式 – 外部和內部。
如果 API 取用者不在叢集 VNet 中，則應使用外部模式 (圖 4)。 在此模式中，API 管理閘道會插入叢集 VNet，但可透過外部負載平衡器從公用網際網路存取。 這有助於完全隱藏叢集，同時仍允許外部用戶端取用微服務。 此外，您可以使用 Azure 網路功能 (例如網路安全性群組 (NSG)) 來限制網路流量。
如果所有 API 取用者都位於叢集 VNet 內，則可以使用內部模式 (圖 5)。 在此模式中，API 管理閘道會插入叢集 VNET 中，而且只能透過內部負載平衡器從此 VNet 中存取。 無法從公用網際網路連接 APIM 閘道或 AKS 叢集。
在這兩種情況下，AKS 叢集都不會公開顯示。 相較於選項 2，輸入控制器可能不需要。 視您的案例和設定而定，API 管理與微服務之間仍可能需要驗證。 例如，如果採用服務網格，則一律需要相互 TLS 驗證。
優點：
- 最安全的選項，因為 AKS 叢集沒有公用端點
- 簡化叢集設定，因為其沒有公用端點
- 使用內部模式隱藏 VNet 內部 API 管理和 AKS 的能力
- 使用 Azure 網路功能來控制網路流量的能力，例如網路安全性群組 (NSG)
缺點：
- 增加部署和設定 API 管理在 VNet 內部運作的複雜度
下一步
- 深入了解 AKS 中應用程式的網路概念
- 深入了解如何將 API 管理與虛擬網路搭配使用