多區域叢集的 AKS 基準

Azure Kubernetes Service (AKS)
Azure Front Door
Azure 應用程式閘道
Azure Container Registry
Azure 防火牆

此參考架構詳細說明如何在作用中/主動和高可用性組態中跨多個區域執行Azure Kubernetes Service (AKS) 叢集的多個實例。

此架構是以 AKS 基準架構為基礎,Microsoft 建議的 AKS 基礎結構起點。 AKS 基準會詳細說明基礎結構功能,例如 Azure Active Directory (Azure AD) 工作負載身分識別、輸入和輸出限制、資源限制,以及其他安全的 AKS 基礎結構設定。 本檔未涵蓋這些基礎結構詳細資料。 建議您先熟悉 AKS 基準,再繼續進行多重區域內容。

架構

顯示多區域部署的架構圖。

下載這個架構的 Visio 檔案

GitHub 標誌 此架構的參考實作可在 GitHub上取得。

單元

多區域 AKS 參考架構會使用許多元件和 Azure 服務。 以下僅列出具有此多叢集架構唯一性的元件。 針對其餘專案,參考 AKS 基準架構

  • 多個叢集/多個區域 部署多個 AKS 叢集,每個叢集分別位於不同的 Azure 區域中。 在正常作業期間,網路流量會在所有區域之間路由傳送。 如果某個區域無法使用,流量會路由傳送至最接近發出要求之使用者的區域。
  • 每個區域的中樞輪輻網路 每個區域 AKS 實例都會部署區域中樞輪輻網路組。 Azure 防火牆管理員原則可用來管理所有區域的防火牆原則。
  • 區域金鑰存放區Azure 金鑰保存庫會布建在每個區域中,以儲存 AKS 實例專屬的敏感性值和金鑰,以及在該區域中找到的支援服務。
  • Azure Front DoorAzure Front door 可用來負載平衡流量,並將流量路由傳送至區域Azure 應用程式閘道實例,其位於每個 AKS 叢集前面。 Azure Front Door 允許第七層全域路由,這兩者都是此參考架構的必要專案。
  • Log Analytics 區域 Log Analytics 實例用於儲存區域網路計量和診斷記錄。 此外,共用 Log Analytics 實例可用來儲存所有 AKS 實例的計量和診斷記錄。
  • 容器登錄 工作負載的容器映射會儲存在受控容器登錄中。 在此架構中,單一Azure Container Registry會用於叢集中的所有 Kubernetes 實例。 Azure Container Registry異地複寫可讓映射複寫至選取的 Azure 區域,並提供映射的持續存取權,即使區域發生中斷也一樣。

設計模式

此參考架構使用兩種雲端設計模式。 地理節點 (地理位置) ,其中任何區域都可以服務任何要求,以及 部署戳記 ,其中應用程式或應用程式元件的多個獨立複本會從單一來源部署 (部署範本) 。

地理節點模式考慮

選取要部署每個 AKS 叢集的區域時,請考慮接近工作負載取用者或您的客戶的區域。 此外,請考慮使用 跨區域複寫。 跨區域複寫會以非同步方式複寫其他 Azure 區域內相同的應用程式和資料,以進行災害復原保護。 當您的叢集調整超過兩個區域時,請繼續規劃每個 AKS 叢集配對的跨區域複寫。

在每個區域內,AKS 節點集區中的節點會分散到多個可用性區域,以協助防止因區域性失敗而發生問題。 可用性區域在一組有限的區域中受到支援,這會影響區域叢集位置。 如需 AKS 和可用性區域的詳細資訊,包括支援的區域清單,請參閱 AKS 可用性區域

部署戳記考慮

管理多區域 AKS 叢集時,多個 AKS 實例會部署到多個區域。 這其中每一個實例都會被視為戳記。 如果發生區域失敗,或需要為您的叢集新增更多容量和/或區域存在,您可能需要建立新的戳記實例。 選取建立和管理部署戳記的程式時,請務必考慮下列事項:

  • 針對允許一般化組態的戳記定義選取適當的技術,例如基礎結構即程式碼
  • 使用部署輸入機制提供實例特定值,例如變數或參數檔案
  • 選取允許彈性、可重複且等冪部署的部署工具
  • 在作用中/主動戳記組態中,請考慮流量如何在每個戳記之間平衡
  • 新增和移除集合中的戳記時,請考慮容量和成本考慮
  • 請考慮如何以單一單位來取得戳記的可見度和/或監視集合。

這些專案會詳述此參考架構的下列各節中的特定指引。

車隊管理

此解決方案代表多叢集和多重區域拓撲,而不需要包含進階協調器,即可將所有叢集視為統一車隊的一部分。 當叢集計數增加時,請考慮在 Azure Kubernetes Fleet Manager 中註冊成員,以便更大規模地管理參與的叢集。 此處提供的基礎結構架構基本上不會隨著註冊變更為 Fleet Manager,但第 2 天作業和類似的活動受益于可同時以多個叢集為目標的控制平面。

考量

這些考慮會實作 Azure Well-Architected Framework 的要素,這是一組可用來改善工作負載品質的指引原則。 如需詳細資訊,請參閱 Microsoft Azure Well-Architected Framework

叢集部署和啟動載入

在高可用性和地理位置分散式組態中部署多個 Kubernetes 叢集時,請務必將每個 Kubernetes 叢集的總和視為結合單位。 您可能想要開發自動化部署和設定的程式碼驅動策略,以確保每個 Kubernetes 實例盡可能相同。 您想要藉由新增或移除其他 Kubernetes 實例,來考慮相應放大和縮小的策略。 您會想要設計及部署和設定計劃,以考慮區域失敗或其他常見案例。

叢集定義

您有許多部署Azure Kubernetes Service叢集的選項。 Azure 入口網站、Azure CLI 和 Azure PowerShell 模組都是部署個別或非結合 AKS 叢集的不錯選項。 不過,這些方法在處理許多緊密結合的 AKS 叢集時,可能會面臨挑戰。 例如,使用 Azure 入口網站會因為遺漏步驟或無法使用的組態選項而開啟遺漏設定的機會。 此外,使用入口網站部署和設定許多叢集也是需要一或多個工程師專注的及時程式。 您可以使用命令列工具來建構可重複且自動化的程式。 不過,等冪性、部署失敗控制和失敗復原的責任是您和您所建置的腳本。

使用許多 AKS 實例時,建議您考慮基礎結構即程式碼解決方案,例如和 Azure Resource Manager範本、Bicep 範本或 Terraform 設定。 基礎結構即程式碼解決方案提供自動化、可調整和等冪部署解決方案。 此參考架構包含解決方案共用服務的 ARM 範本,以及 AKS 叢集 + 區域服務的 ARM 範本。 如果您使用基礎結構即程式碼,則可以使用一般化組態來定義部署戳記,例如網路、授權和診斷。 部署參數檔案可以搭配區域特定值提供。 透過此設定,單一範本可用來跨任何區域部署幾乎完全相同的戳記。

開發和維護基礎結構作為程式碼資產的成本可能很高。 在某些情況下,例如部署靜態/固定數目的 AKS 實例時,基礎結構的額外負荷可能會超過優點。 在這些情況下,使用更命令式的方法,例如使用命令列工具,甚至是手動方法都沒問題。

叢集部署

定義叢集戳記定義之後,您有許多選項可用來部署個別或多個戳記實例。 我們建議使用新式持續整合技術,例如 GitHub Actions 或 Azure Pipelines。 持續整合式部署解決方案的優點包括:

  • 允許使用程式碼新增和移除戳記的程式碼型部署
  • 整合式測試功能
  • 整合式環境和預備功能
  • 整合式秘密管理解決方案
  • 與程式碼/部署原始檔控制整合
  • 部署歷程記錄和記錄

隨著新增或移除全域叢集的新戳記,部署管線必須更新,才能保持一致。 在參考實作中,每個區域都會部署為 GitHub Action 工作流程中的個別步驟 , (範例) 。 此設定很簡單,在於每個叢集實例在部署管線中明確定義。 此設定確實包含從部署新增和移除叢集的一些系統管理額外負荷。

另一個選項是利用邏輯,根據所需位置的清單或其他指出資料點來建立叢集。 例如,部署管線可能包含所需區域的清單;管線內的步驟接著可以迴圈查看此清單,將叢集部署到清單中找到的每個區域。 此設定的缺點是部署一般化的複雜度,而且部署管線中未明確詳細說明每個叢集戳記。 正面優點是,從管線新增或移除叢集戳記會成為所需區域的簡單更新。

此外,從部署管線移除叢集戳記不一定會確保它也會解除委任。 根據您的部署解決方案和組態,您可能需要額外的步驟,以確保 AKS 實例已適當地解除委任。

叢集啟動載入

部署每個 Kubernetes 實例或戳記之後,必須部署和設定輸入控制器、身分識別解決方案和工作負載元件等叢集元件。 您也必須考慮跨叢集套用安全性、存取和治理原則。

與部署類似,這些設定可能會變得難以手動管理數個 Kubernetes 實例。 相反地,請考慮大規模設定和原則的下列選項。

GitOps

請考慮使用自動化方法來將組態套用至 Kubernetes 叢集,而不是手動設定 Kubernetes 元件,因為這些設定會簽入來源存放庫。 此程式通常稱為 GitOps,而 Kubernetes 的熱門 GitOps 解決方案包括 Flux 和 Argo CD。 此實作會使用 AKS 的 Flux 延伸模組來自動啟動叢集,並在部署叢集之後立即啟用啟動。

GitOps 在 AKS 基準參考架構中更深入地詳細說明。 這裡的重點是使用 GitOps 型方法來設定有助於確保每個 Kubernetes 實例都以類似的方式設定,而不需要投入心力。 隨著車隊的大小成長,這更重要。

Azure 原則

隨著新增多個 Kubernetes 實例,原則驅動治理、合規性和設定的優點會增加。 具體來說,利用原則Azure 原則提供集中式且可調整的方法來進行叢集控制。 AKS 原則的優點詳述于 AKS 基準參考架構中。

建立 AKS 叢集並在稽核模式中指派限制性計畫,以取得不符合規範的可見度時,就會在此參考實作中啟用Azure 原則。 實作也會設定不屬於任何內建計畫的更多原則。 這些原則是在拒絕模式中設定。 例如,有一個原則可確保只有已核准的容器映射會在叢集中執行。 請考慮建立您自己的自訂計畫。 將適用于您工作負載的原則合併成單一指派。

原則範圍是指每個原則和原則計畫的目標。 與此架構相關聯的參考實作會使用 ARM 範本,將原則指派給部署每個 AKS 叢集的資源群組。 隨著全域叢集的使用量成長,會產生許多重複的原則。 您也可以將原則的範圍設定為 Azure 訂用帳戶或 Azure 管理群組。 此方法可讓您將單一原則集套用至訂用帳戶範圍內的所有 AKS 叢集,以及/或管理群組下找到的所有訂用帳戶。

設計多個 AKS 叢集的原則時,請考慮下列專案:

  • 應該全域套用至所有 AKS 實例的原則可以套用至管理群組或訂用帳戶
  • 將每個區域叢集放在自己的資源群組中,允許套用至資源群組的區域特定原則

如需可協助您建立原則管理原則的資料,請參閱雲端採用架構資源組織

工作負載部署

除了 AKS 實例組態之外,請考慮部署至每個區域實例或戳記的工作負載。 部署解決方案或管線需要設定以容納每個區域戳記。 隨著將更多戳記新增至全域叢集,部署程式必須擴充或彈性足以容納新的區域實例。

規劃工作負載部署時,請考慮下列專案。

  • 將部署一般化,例如使用 Helm 圖表,以確保單一部署組態可以跨多個叢集戳記使用。
  • 使用設定為跨所有叢集戳記部署工作負載的單一持續部署管線。
  • 提供戳記特定的實例詳細資料作為部署參數。
  • 請考慮應用程式診斷記錄和分散式追蹤如何針對整個應用程式的可觀察性進行設定。

可用性和容錯移轉

選擇多區域 Kubernetes 架構的重要動機是服務可用性。 也就是說,如果服務或服務元件在一個區域中無法使用,則流量應該路由傳送至該服務可用的區域。 多區域架構包含許多不同的失敗點。 在本節中,會討論這些可能的失敗點。

應用程式 Pod (區域)

Kubernetes 部署物件可用來建立 Pod (ReplicaSet) 的多個複本。 如果無法使用流量,則會在其餘流量之間路由傳送。 Kubernetes ReplicaSet 會嘗試讓指定的複本數目保持啟動並執行。 如果一個實例關閉,應該重新建立新的實例。 最後,即時探查可用來檢查 Pod 中執行的應用程式或進程狀態。 如果服務沒有回應,即時探查將會移除 Pod,這會強制 ReplicaSet 建立新的實例。

如需詳細資訊,請參閱 Kubernetes ReplicaSet

應用程式 Pod (全域)

當整個區域變成無法使用時,叢集中的 Pod 將無法再提供要求。 在此情況下,Azure Front Door 實例會將所有流量路由傳送至其餘狀況良好的區域。 這些區域中的 Kubernetes 叢集和 Pod 將繼續提供要求。

在此情況下請小心,以補償剩餘叢集增加的流量/要求。 要考慮的一些事項:

  • 確定網路和計算資源的大小正確,以因區域容錯移轉而突然增加流量。 例如,使用 Azure CNI 時,請確定您有一個子網可支援具有尖峰流量負載的所有 Pod IP。
  • 利用水準 Pod 自動調整程式來增加 Pod 複本計數,以補償增加的區域需求。
  • 利用 AKS 叢集自動調整程式來增加 Kubernetes 實例節點計數,以補償增加的區域需求。

如需詳細資訊,請參閱 水準 Pod 自動調整程式和AKS 叢集自動調整程式

Kubernetes 節點集區 (區域)

例如,如果單一 Azure 伺服器機架無法使用電源,有時可能會發生當地語系化的失敗。 若要保護您的 AKS 節點免于成為單一點區域失敗,請使用 Azure 可用性區域。 使用可用性區域可確保指定可用性區域中的 AKS 節點實際上與另一個可用性區域中定義的節點分開。

如需詳細資訊,請參閱 AKS 和 Azure 可用性區域

(全域) 的 Kubernetes 節點集區

在完整的區域失敗中,Azure Front Door 會將流量路由傳送至其餘且狀況良好的區域。 同樣地,在此情況下請小心,以補償剩餘叢集的流量/要求增加。

如需詳細資訊,請參閱 Azure Front Door

網路拓撲

類似于 AKS 基準參考架構,此架構會使用中樞輪輻網路拓撲。 除了 AKS 基準參考架構中指定的考慮之外,請考慮下列最佳做法:

  • 為每個區域 AKS 實例實作中樞輪輻,其中中樞輪輻虛擬網路會對等互連。
  • 透過每個區域中樞網路中找到Azure 防火牆實例來路由傳送所有輸出流量。 利用Azure 防火牆管理員原則來管理所有區域的防火牆原則。
  • 遵循 AKS 基準參考架構中找到的 IP 大小調整,如果您遇到區域失敗,請針對節點和 Pod 調整作業允許更多 IP 位址。

流量管理

使用 AKS 基準參考架構時,工作負載流量會直接路由傳送至Azure 應用程式閘道實例,然後轉送到後端負載平衡器 /AKS 輸入資源。 當您使用多個叢集時,用戶端要求會透過 Azure Front Door 實例路由傳送,而該實例會路由至Azure 應用程式閘道實例。

顯示多區域部署中工作負載流量的架構圖表。

下載此圖表的 Visio 檔案

  1. 使用者會將要求傳送至功能變數名稱 (,例如 https://contoso-web.azurefd.net 解析為 Azure Front Door 實例的) 。 此要求會使用針對 Azure Front Door 所有子域發出的萬用字元憑證 (*.azurefd.net) 進行加密。 Azure Front Door 實例會針對 WAF 原則驗證要求、根據健康情況和延遲) 選取最快的後端 (,並使用公用 DNS 解析後端 IP 位址 (Azure 應用程式閘道實例) 。

  2. Front Door 會將要求轉送到選取的適當應用程式閘道實例,做為區域戳記的進入點。 流量會透過網際網路流動,並由 Azure Front Door 加密。 請考慮方法,以確保應用程式閘道實例只接受來自 Front Door 實例的流量。 其中一種方法是在包含應用程式閘道的子網上使用網路安全性群組。 這些規則可以根據來源、埠、目的地等屬性篩選輸入 (或輸出) 流量。 Source 屬性可讓您設定內建服務標籤,指出 Azure 資源的 IP 位址。 這個抽象概念可讓您更輕鬆地設定和維護規則,並追蹤 IP 位址。 此外,請考慮使用 Front Door 到後端 X-Azure-FDID 標頭,以確保應用程式閘道實例只接受來自 Front Door 實例的流量。 如需 Front Door 標頭的詳細資訊,請參閱 Azure Front Door 中的 HTTP 標頭通訊協定支援

共用資源考慮

雖然此參考架構的重點在於讓多個 Kubernetes 實例分散到多個 Azure 區域,但對於在所有實例上都有一些共用資源是有意義的。 AKS 多重區域參考實作使用單一 ARM 範本來部署所有共用資源,然後再部署另一個來部署每個區域戳記。 本節詳述每個共用資源,以及跨多個 AKS 實例使用每個資源的考慮。

Container Registry

Azure Container Registry用於此參考架構,以提供容器映射服務 (提取) 。 在多區域叢集部署中使用Azure Container Registry時,請考慮下列專案。

各地區上市情況

將容器登錄放在部署 AKS 叢集的每個區域中,允許網路關閉作業,啟用快速、可靠的映射層傳輸。 有多個映射服務端點,可在區域服務無法使用時提供可用性。 使用 Azure Container Registry 異地複寫功能可讓您管理複寫至多個區域的一個 Container Registry 實例。

AKS 多重區域參考實作建立了單一 Container Registry 實例,並將這個實例的複本建立到每個叢集區域。 如需Azure Container Registry複寫的詳細資訊,請參閱Azure Container Registry中的異地複寫。

顯示Azure 入口網站內多個 ACR 複本的影像。

顯示Azure 入口網站內多個 ACR 複本的影像。

叢集存取

每個 AKS 實例都需要從Azure Container Registry提取影像層的存取權。 有多種方式可用來建立Azure Container Registry的存取權;此參考架構會針對每個叢集使用 Azure 受控識別,然後授與 Container Registry 實例上的 AcrPull 角色。 如需使用受控識別進行容器登錄存取的詳細資訊和建議,請參閱 AKS 基準參考架構

此組態定義于叢集戳記 ARM 範本中,以便每次部署新的戳記時,就會授與新的 AKS 實例存取權。 由於 Container Registry 是共用資源,因此請確定您的部署戳記範本可以取用並使用必要的詳細資料,在此案例中為 Container Registry 的資源識別碼。

Azure 監視器

Azure 監視器容器深入解析功能是監視和瞭解叢集和容器工作負載效能和健康情況的建議工具。 容器深入解析 會利用 Log Analytics 工作區來儲存記錄資料,以及 Azure 監視器計量 來儲存數值時間序列資料。 Container Insights 也可以收集 Prometheus 計量,並將資料傳送至 適用于 Prometheus 或 Azure 監視器記錄的 Azure 監視器受控服務。

您也可以設定 AKS 叢集診斷設定 ,以從 AKS 控制平面元件收集和分析資源記錄,並轉送到 Log Analytics 工作區。

AKS 如需詳細資訊,請參閱 AKS 基準參考架構

考慮監視跨區域實作,例如此參考架構時,請務必考慮每個戳記之間的結合。 在此情況下,請考慮每個戳記單一單位的元件, (區域叢集) 。 多區域 AKS 參考實作會利用每個 Kubernetes 叢集共用的單一 Log Analytics 工作區。 如同其他共用資源,請定義您的區域戳記以取用單一 Log Analytics 工作區的相關資訊,並將每個叢集連線至該工作區。

現在,每個區域叢集都會將診斷記錄發出至單一 Log Analytics 工作區,因此,此資料以及資源計量可用來更輕鬆地建置代表全域叢集整體的報告和儀表板。

Azure Front Door

Azure Front door 可用來平衡流量,並將流量路由傳送至每個 AKS 叢集。 Azure Front Door 允許第七層全域路由,這兩者都是此參考架構的必要專案。

叢集組態

新增區域 AKS 實例時,與 Kubernetes 叢集一起部署的應用程式閘道必須註冊為 Front Door 後端,才能進行適當的路由。 此作業需要更新基礎結構作為程式碼資產。 或者,此作業可以與部署組態分離,並使用 Azure CLI 之類的工具進行管理。 包含的參考實作部署管線會針對這項作業使用不同的 Azure CLI 步驟。

憑證

Front Door 即使在開發/測試環境中也不支援自我簽署憑證。 若要啟用 HTTPS 流量,您必須建立憑證授權單位單位簽署的 TLS/SSL 憑證, (CA) 。 參考實作會使用 Certbot 來建立 Let's Encrypt Authority X3 憑證。 規劃生產叢集時,請使用您組織的慣用方法來購買 TLS 憑證。

如需 Front Door 支援的其他 CA 相關資訊,請參閱 允許的憑證授權單位單位在 Azure Front Door 上啟用自訂 HTTPS

叢集存取和身分識別

AKS 基準參考架構中所述,建議使用 Azure Active Directory 作為叢集的存取識別提供者。 然後,可以使用 Azure Active Directory 群組來控制叢集資源的存取。

當您管理多個叢集時,您必須決定存取架構。 這些選項包括:

  • 建立全域叢集全叢集存取群組,成員可以在叢集中的每個 Kubernetes 實例上存取所有物件。 此選項提供最少的系統管理需求;不過,它會將重大許可權授與任何群組成員。
  • 為每個 Kubernetes 實例建立個別存取群組,以用來授與個別叢集實例中物件的存取權。 使用此選項時,系統管理額外負荷會增加;不過,它也會提供更細微的叢集存取。
  • 定義 Kubernetes 物件類型和命名空間的細微存取控制,並將結果與 Azure 目錄群組結構相互關聯。 使用此選項時,系統管理額外負荷會大幅增加;不過,它不僅提供每個叢集的細微存取權,還會提供每個叢集中找到的命名空間和 Kubernetes APIS。

透過包含的參考實作,系統會建立兩個 Azure Active Directory 群組以供系統管理員存取。 這些群組是使用部署參數檔案在叢集戳記部署時間指定。 每個群組的成員都有對應叢集戳記的完整存取權。

如需使用 Azure Active Directory 管理 AKS 叢集存取的詳細資訊,請參閱 AKS Azure AD 整合

資料、狀態和快取

使用 AKS 實例的全域分散式叢集時,請考慮應用程式、進程或其他可能跨叢集執行的工作負載架構。 當狀態型工作負載分散到叢集時,是否需要存取狀態存放區? 如果因失敗而重新建立叢集中其他位置的進程,工作負載或進程是否會繼續存取相依狀態存放區或快取解決方案? 狀態可以透過許多方式達成;不過,在單一 Kubernetes 叢集中可能會很複雜。 在多個叢集 Kubernetes 實例中新增時,複雜性會增加。 由於區域存取和複雜度考慮,請考慮設計您的應用程式以使用全域分散式狀態存放區服務。

多重叢集參考實作不包含狀態考慮的示範或設定。 如果您跨叢集 AKS 實例執行應用程式,請考慮將您的工作負載架構為使用全域散發的資料服務,例如 Azure Cosmos DB。 Azure Cosmos DB 是全域散發的資料庫系統,可讓您從資料庫的本機複本中讀取和寫入資料。 如需詳細資訊,請參閱 Azure Cosmos DB

如果您的工作負載使用快取解決方案,請確定其架構為架構,以便快取服務保持運作。 若要這樣做,請確定工作負載本身能夠復原快取相關的容錯移轉,而且快取解決方案存在於所有區域 AKS 實例上。

成本最佳化

使用 Azure 定價計算機 來估計架構中使用的服務成本。 Microsoft Azure Well-Architected架構中的成本 優化 一節說明其他最佳做法,以及 優化成本 一文中的特定成本優化組態選項。

下一步