將 Azure API 管理與 Azure Kubernetes 服務(wù)中部署的微服務(wù)配合使用

來源： Microsoft Azure

作者：Microsoft Azure

時間：2020-11-19

微服務(wù)非常適合用于生成Api。使用Azure Kubernetes Service(AKS)，你可以在云中快速部署和運行基于微服務(wù)的體系結(jié)構(gòu)。然后，你可以利用AZURE Api管理(api管理)將微服務(wù)作為api發(fā)布到內(nèi)部和外部使用。本文介紹了通過AKS部署API管理的選項。它假定Kubernetes、API管理和Azure網(wǎng)絡(luò)的基本知識。

背景

將微服務(wù)發(fā)布為用于使用的Api時，管理微服務(wù)和使用它們的客戶端之間的通信可能會很困難。需要考慮多種跨切削問題，例如身份驗證、授權(quán)、限制、緩存、轉(zhuǎn)換和監(jiān)視。不管是否向內(nèi)部或外部客戶端公開微服務(wù)，這些問題都是有效的。

API網(wǎng)關(guān)模式解決了這些問題。API網(wǎng)關(guān)充當微服務(wù)的前端，將客戶端與微服務(wù)分離，增加額外的安全層，并通過消除處理交叉切削問題的負擔，降低微服務(wù)的復(fù)雜性。

AZURE Api管理是一種全包式解決方案，用于解決API網(wǎng)關(guān)需求?？梢詾槲⒎?wù)快速創(chuàng)建一致的新式網(wǎng)關(guān)，并將其發(fā)布為Api。它還提供了其他功能，包括用于API發(fā)現(xiàn)、API生命周期管理和API分析的自助服務(wù)開發(fā)人員門戶。

結(jié)合使用時，AKS和API管理提供了一個平臺，用于部署、發(fā)布、保護、監(jiān)視和管理基于微服務(wù)的Api。在本文中，我們將逐步介紹幾個與API管理一起部署AKS的選項。

Kubernetes服務(wù)和Api

在Kubernetes群集中，容器部署在pod中，并具有生命周期。輔助角色節(jié)點停止運行時，節(jié)點上運行的盒將丟失。因此，Pod的IP地址可隨時更改。我們不能依靠它來與pod通信。

為了解決此問題，Kubernetes引入了服務(wù)的概念。Kubernetes服務(wù)是一種抽象層，它定義了pod的邏輯組，并為這些pod啟用了外部流量泄露、負載平衡和服務(wù)發(fā)現(xiàn)。

當我們準備通過API管理將微服務(wù)發(fā)布為Api時，我們需要考慮如何將Kubernetes中的服務(wù)映射到API管理中的Api。沒有設(shè)置規(guī)則。這取決于你在一開始就將業(yè)務(wù)功能或域劃分到微服務(wù)中的方式。例如，如果服務(wù)背后的pod負責給定資源的所有操作(例如，客戶)，則該服務(wù)可能會映射到一個API。如果對資源的操作分區(qū)為多個微服務(wù)(例如，GetOrder、PlaceOrder)，則可在API管理中將多個服務(wù)邏輯聚合為一個API(請參閱圖1)。

映射也可以發(fā)展。由于API管理在微服務(wù)的前面創(chuàng)建了一個外觀，因此，我們可以在一段時間內(nèi)重構(gòu)微服務(wù)并調(diào)整其大小。

將服務(wù)映射到Api

在AKS之前部署API管理

有幾個選項可用于在AKS群集前面部署API管理。

盡管AKS群集始終部署在虛擬網(wǎng)絡(luò)中(VNet)，但不需要在VNet中部署API管理實例。如果API管理不在群集VNet中，AKS群集必須發(fā)布公共終結(jié)點，以便API管理連接到。在這種情況下，需要保護API管理和AKS之間的連接。換句話說，我們需要確保群集只能通過API管理以獨占方式訪問。我們來看一下這些選項。

選項1：公開公開服務(wù)

可以使用NodePort、LoadBalancer或ExternalName服務(wù)類型公開公開AKS群集中的服務(wù)。在這種情況下，可以直接從公共internet訪問服務(wù)。將API管理部署到群集之前，我們需要確保所有入站流量通過API管理，方法是在微服務(wù)中應(yīng)用身份驗證。例如，API管理可以在對群集發(fā)出的每個請求中包含一個訪問令牌。每個微服務(wù)負責在處理請求之前驗證令牌。

這可能是在AKS之前部署API管理的最簡單選項，尤其是在微服務(wù)中實現(xiàn)了身份驗證邏輯時。

直接發(fā)布服務(wù)

優(yōu)點：

API管理端上的輕松配置，因為無需注入群集VNet

如果服務(wù)已公開公開并且微服務(wù)中已存在身份驗證邏輯，則無AKS端的更改。

缺點：

服務(wù)終結(jié)點的公共可見性導(dǎo)致的潛在安全風險

沒有入站群集流量的單一入口點

利用重復(fù)的身份驗證邏輯使微服務(wù)復(fù)雜化

選項2：安裝入口控制器

盡管選項1可能更簡單，但它具有上面提到的顯著缺點。如果API管理實例不在群集VNet中，則相互TLS身份驗證(mTLS)是一種可靠的方式，可確保在API管理實例和AKS群集之間的兩個方向上都安全且信任流量。

API管理以本機方式支持相互TLS身份驗證，并且可在Kubernetes中通過安裝入口控制器(圖3)啟用。因此，將在入口控制器中執(zhí)行身份驗證，這將簡化微服務(wù)。此外，可以通過入口將API管理的IP地址添加到允許列表，以確保只有API管理可以訪問群集。

通過入口控制器發(fā)布

優(yōu)點：

API管理端上的輕松配置，因為無需注入群集VNet，而mTLS是本機支持的

為入口控制器層上的入站群集流量集中保護

通過最大程度減少公開可見的群集終結(jié)點來降低安全風險

缺點：

增加群集配置的復(fù)雜性，原因是安裝、配置和維護入口控制器并管理用于mTLS的證書

由于入口控制器終結(jié)點的公開可見性(s的安全風險)

通過API管理發(fā)布API時，使用訂閱密鑰保護對這些API的訪問容易且常見。需要使用已發(fā)布API的開發(fā)人員在調(diào)用這些API時必須在HTTP請求中包括一個有效的訂閱密鑰。否則，API管理網(wǎng)關(guān)會立即拒絕調(diào)用。不會將它們轉(zhuǎn)發(fā)到后端服務(wù)。

若要獲取訪問API所需的訂閱密鑰，必須擁有訂閱。訂閱實質(zhì)上是一個已命名的容器，該容器包含一對訂閱密鑰。需要使用已發(fā)布API的開發(fā)人員可以獲取訂閱。不需要API發(fā)布者批準。API發(fā)布者也可以直接為API使用者創(chuàng)建訂閱。

選項3：在群集VNet內(nèi)部署APIM

在某些情況下，由于公開的終結(jié)點，具有法規(guī)約束或嚴格安全要求的客戶可能會找到選項1和2不可行的解決方案。在其他情況下，AKS群集和使用微服務(wù)的應(yīng)用程序可能駐留在同一VNet中，因此沒有理由公開群集，因為所有API流量將保留在VNet中。在這些情況下，你可以將API管理部署到群集VNet中。API管理高級層支持VNet部署。

將API管理部署到VNet中的模式有兩種：外部和內(nèi)部。

如果API使用者不在群集VNet中，則應(yīng)使用外部模式(圖4)。在此模式下，API管理網(wǎng)關(guān)注入群集VNet，但可通過外部負載均衡器從公共internet訪問。它有助于完全隱藏群集，同時仍允許外部客戶端使用微服務(wù)。此外，還可以使用Azure網(wǎng)絡(luò)功能，例如網(wǎng)絡(luò)安全組(NSG)來限制網(wǎng)絡(luò)流量。