此架構構詳細介紹如何在主動/主動和高可用性設定中，跨多區域執行 Azure Kubernetes Service (AKS) 叢集的多執行個體。
此架構是以 AKS 基準架構為基礎，即 Microsoft 建議的 AKS 基礎結構起點。 AKS 基準詳細介紹了基礎結構功能，例如 Microsoft Entra 工作負載識別碼、入口和出口限制、資源限制以及其他安全性 AKS 基礎結構設定。 本文件未涵蓋這些基礎設施細節。 建議您先熟悉 AKS 基準，然後再繼續學習多區域內容。
架構
下載此架構的 Visio 檔案。
元件
此多區域 AKS 體系架構中使用了許多元件和 Azure 服務。 此處僅列出對於此多叢集架構唯一性的元件。 如需其餘元件，請參閱 AKS 基準架構。
- 區域 AKS 叢集：部署多個 AKS 叢集，每個叢集都位於單獨的 Azure 區域中。 在正常作業期間，網路流量在所有區域之間路由。 如果某個區域不可用，流量將路由到距離發出請求的使用者最近的區域。
- 區域中心輻射型網路：為每個區域 AKS 執行個體部署區域中心輻射網路對。 Azure 防火牆管理員策略可用於管理所有區域的防火牆原則。
- 區域金鑰保存庫：Azure Key Vault 已在每個區域中佈建。 金鑰保管庫用於儲存特定於 AKS 叢集的敏感值和金鑰以及該區域中的支援服務。
- 多個記錄工作區：區域記錄分析工作區用於儲存區域網路指標和診斷日誌。 此外，共用記錄分析執行個體用於儲存所有 AKS 執行個體的指標和診斷。
- 全球 Azure Front Door 設定檔：Azure Front Door 用於負載平衡並將流量路由至位於每個 AKS 叢集前面的區域 Azure 應用程式閘道執行個體。 Azure Front Door 允許第 7 層全域路由，這兩者都是該體系架構所必需。
- 全域容器登錄：工作負載的容器映像儲存在託管容器登錄中。 在此架構中，單一 Azure 容器登錄用於叢集中的所有 Kubernetes 執行個體。 Azure 容器登錄的異地複寫可以將映像複製到選定的 Azure 區域，並提供對映像的持續訪問，即使某個區域中斷也是如此。
設計模式
該架構使用兩種雲端設計模式：
- Geodes (地理節點)，其中所有區域都可以服務任何要求。
- 部署戳記，其中應用程式或應用程式元件的多個獨立副本是從單一來源 (例如部署範本) 部署的。
地理節點模式注意事項
選擇部署各 AKS 叢集的區域時，請考慮靠近工作負載使用者或客戶的區域。 此外，請考慮使用跨區域複寫。 跨區域複寫會以非同步方式複寫其他 Azure 區域內相同的應用程式和資料，以進行災害復原保護。 當叢集擴展到兩個區域之外時，請繼續為每對 AKS 叢集規劃跨區域複製。
在每個區域內，AKS 節點池中的節點分佈在多個可用性區域中，以協助防止因區域故障而導致的問題。 一組有限的區域支援可用性區域，這會影響區域叢集的放置。 關於 AKS 和可用性區域的詳細資訊 (包括支援的區域清單)，請參閱 AKS 可用性區域。
部署戳記注意事項
管理多區域 AKS 解決方案時，您可以跨多個區域部署多個 AKS 叢集。 這些叢集中的每一個都會被視為戳記。 如果出現區域故障，或需要為叢集新增更多容量或區域存在，則可能需要建立新的戳記執行個體。 選擇建立和管理部署戳記的流程時，考慮以下事項非常重要：
- 針對允許通用設定的戳記定義選取適當的技術。 例如，您可以使用 Bicep 將基礎結構定義為程式碼。
- 使用部署輸入機制 (例如變數或參數檔) 提供執行個體的特定值。
- 選擇允許靈活、可重複和等冪部署的部署工具。
- 在主動/主動戳記設定中，請考慮如何在每個戳記之間平衡流量。 此體系架構使用 Azure Front Door 進行全域負載平衡。
- 在收藏中新增和刪除戳記時，請考慮容量和成本問題。
- 考慮如何將戳記集合視為一個整體，進行視覺化和監控。
以下各節詳細介紹了其中的每一項並提供具體指導。
車隊管理
此解決方案代表了多叢集和多區域拓撲，不包含高階協調器來將所有叢集視為統一佇列的一部分。 當叢集數量增加時，請考慮在 Azure Kubernetes 機群管理員中註冊成員，以便更好地大規模管理參與的叢集。 這裡介紹的基礎設施架構並沒有隨著機群管理員的註冊而發生根本性的變化，但是第二天的作業和類似活動受益於可以同時針對多個叢集的控制平面。
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。
叢集部署和啟動程序
在高可用性和異地分散式設定中部署多個 Kubernetes 叢集時，必須將每個 Kubernetes 叢集的總和視為一個耦合單元。 您可能希望開發程式碼驅動的策略來進行自動化部署和設定，以確保每個 Kubernetes 執行個體盡可能相同。 考慮橫向放大和縮小的策略，包括新增或刪除其他 Kubernetes 叢集。 您的設計、部署和設定計畫應考慮可用性區域中斷、區域故障和其他常見情況。
叢集定義
您有多種部署 Azure Kubernetes 服務叢集的選項。 Azure 入口網站、Azure CLI 和 Azure PowerShell 模組都是部署單一或非耦合 AKS 叢集的不錯選擇。 然而，在使用許多緊密耦合的 AKS 叢集時，這些方法可能會帶來挑戰。 例如，使用 Azure 入口網站可能會因錯過步驟或不可用的設定選項而導致設定錯誤。 使用入口網站部署和設定許多叢集是一個耗時的過程，需要一名或多名工程師的關注。 如果使用 Azure CLI 或 Azure PowerShell，則可以使用命令列工具建立可重複的自動化流程。 但是，等冪、部署失敗控制和故障復原的責任在於您和您建置的指令碼。
使用多個 AKS 執行個體時，我們建議考慮基礎結構即程式碼解決方案，例如 Bicep、Azure 資源管理員範本或 Terraform。 基礎結構即程式碼解決方案提供了自動化、可擴展和等冪部署解決方案。 例如，您可以將一個 Bicep 檔案用於解決方案的共用服務，並將另一個檔案用於 AKS 叢集和其他區域服務。 如果您使用基礎結構即程式碼，則可以使用網路、授權和診斷等通用設定來定義部署戳記。 可以為部署參數檔案提供特定於區域的值。 透過此設定，可以使用單一範本在任何區域部署幾乎相同的戳記。
開發和維護基礎設施作為程式碼資產的成本可能會很高。 在某些情況下，將基礎結構定義為程式碼的開銷可能會超過好處，例如當您擁有非常小的 (例如 2 或 3 個) 且數量不變的 AKS 執行個體時。 對於這些情況，可以使用更命令式的方法，例如使用命令列工具，甚至使用 Azure 入口網站的手動方法。
叢集部署
定義叢集戳記後，您可以使用多種選項來部署單一或多個戳記執行個體。 我們的建議是使用現代持續整合技術，例如 GitHub Actions 或 Azure Pipelines。 持續整合式部署解決方案的好處包括：
- 程式碼型部署，允許使用程式碼新增和刪除戳記
- 整合式測試功能
- 整合式環境與暫存功能
- 整合式秘密管理解決方案
- 與原始碼控制整合，適用於應用程式程式碼以及部署程式碼和範本
- 部署歷程記錄和記錄
- 存取控制和稽核功能，控制誰可以進行變更，以及在什麼條件下進行變更
當在全域叢集中新增或刪除新的戳記時，需要更新部署管線以保持一致。 一種方法是將每個區域的資源部署為 GitHub Actions 工作流程中的單獨步驟。 此設定很簡單，因為每個叢集執行個體都在部署管線中明確定義。 此設定包括在部署中新增和刪除叢集時的一些管理開銷。
另一種選擇是建立商務邏輯，以基於所需位置或其他指示資料點的清單來建立叢集。 例如，部署管線可以包含所需區域的清單；然後，管線中的一個步驟可以循環遍歷該列表，將叢集部署到列表中找到的每個區域。 此設定的缺點是部署泛化的複雜性，且每個叢集戳記在部署管線中沒有明確詳細說明。 好處是從管線中新增或刪除叢集戳記變成了所需區域清單的簡單更新。
此外，從部署管線中刪除叢集戳記並不一定會停用戳記的資源。 根據你的部署解決方案和設定，你可能需要額外的步驟來停用 AKS 執行個體和其他 Azure 資源。 考慮使用部署堆疊來啟用 Azure 資源的完整生命週期管理，包括在不再需要它們時進行清理。
叢集啟動程序
部署每個 Kubernetes 執行個體或戳記後，需要部署和設定入口控制器、身分解決方案和工作負載元件等叢集元件。 您也需要在整個叢集中考慮應用安全性、存取和治理原則。
與部署類似，跨多個 Kubernetes 執行個體手動管理這些設定可能會變得困難。 相反，請考慮以下大規模設定和策略選項。
GitOps
建議使用自動化方法將設定套用到 Kubernetes 叢群，而不是手動設定 Kubernetes 元件，因為這些設定已簽入來源儲存庫。 這個過程通常被稱為 GitOps，流行的 Kubernetes GitOps 解決方案包括 Flux 和 Argo CD。 例如，AKS 的 Flux 擴充支援在部署叢集後立即自動引導叢集。
AKS 基線參考架構中更深入地詳細介紹了 GitOps。 透過使用基於 GitOps 的設定方法，您可以確保每個 Kubernetes 執行個體的設定都是類似的，而無需自訂工作。 隨著機群規模的擴大，簡化的設定程序變得更加重要。
Azure 原則
隨著多個 Kubernetes 執行個體的添加，策略驅動的治理、合規性和設定的優勢也會增加。 利用原則 (特別是 Azure 原則) 為叢集控制提供集中且可擴展的方法。 AKS 基線參考架構中詳細介紹了 AKS 策略的優點。
建立 AKS 叢集時應啟用 Azure 原則。 應在稽核模式下分配計劃，以了解不合規情況。 您還可以設定更多不屬於任何內建計劃的策略。 這些原則是在拒絕模式下設定的。 例如，制定了一項策略來確保只有經過核准的容器映像才能在叢集中運作。 考慮建立您自己的自訂計劃。 將適用於您的工作負載的策略合併到單一分配中。
原則範圍是指各項原則的目標和原則措施。 您可以使用 Bicep 將原則指派到部署每個 AKS 叢集的資源群組。 隨著全球叢集足跡的成長，會導致許多重複的原則。 您也可以將策略範圍限定為 Azure 訂閱或 Azure 管理群組。 此方法使你能夠將一組策略應用於訂閱範圍內的所有 AKS 叢集或管理群組下找到的所有訂閱。
為多個 AKS 叢集設計原則時，請考慮以下事項：
- 將全域應用於所有 AKS 執行個體的策略套用到管理群組或訂閱。
- 將每個區域叢集放入自己的資源組中，這樣可以將特定於區域的策略應用於資源組。
請參閱雲端採用框架資源組織，以了解可協助您建立策略管理策略的材料。
工作負載部署
除了 AKS 執行個體設定之外，還要考慮部署到每個區域執行個體或戳記的工作負載。 部署解決方案或管線需要設定以適應每個區域戳記。 隨著更多的戳記加入全域叢集中，部署過程需要擴展，或者需要足夠靈活以適應新的區域執行個體。
規劃工作負載部署時請考慮以下事項。
- 通用化部署 (例如使用 Helm 圖表)，以確保單一部署設定可以跨多個叢集戳記使用。
- 使用設定為跨所有叢集戳記部署工作負載的單一持續部署管線。
- 提供特定於戳記的執行個體詳細資訊作為部署參數。
- 考慮如何設定應用程式診斷記錄和分散式追蹤以實現應用程式範圍的可觀察性。
可用性和容錯移轉
選擇多區域 Kubernetes 架構的一個重要動機是服務可用性。 也就是說，如果某個服務或服務元件在一個區域變得不可用，則流量應路由到該服務的另一個執行個體仍然可用的區域。 多區域架構包含許多不同的失敗點。 在本節中，將討論每個潛在的故障點。
應用程式 Pod 故障
Kubernetes Deployment 物件用於建立 ReplicaSet，它管理 pod 的多個副本。 如果一個 Pod 不可用，流量將在其餘 Pod 之間路由。 Kubernetes ReplicaSet 會嘗試使指定數目的複本正常執行。 如果一個執行個體發生故障，應自動建立一個新執行個體。 活躍度探查可用於檢查 Pod 中執行的應用程式或程序的狀態。 如果服務無回應，活躍度探查會刪除 pod，這會強制 ReplicaSet 建立一個新執行個體。
如需詳細資訊，請參閱 Kubernetes ReplicaSet。
資料中心硬體故障
當地語系化失敗偶爾會發生。 例如，單一 Azure 伺服器機架可能無法供電。 為了防止 AKS 節點成為單點故障，請使用 Azure 可用性區域。 透過使用可用性區域，可以確保一個可用區域中的 AKS 節點與另一可用區域中定義的節點物理隔離。
關於詳細資訊，請參閱 AKS 和 Azure 可用性區域。
Azure 區域故障
若整個區域變得無法使用，叢集中的 Pod 將無法為要求提供服務。 在這種情況下，Azure Front Door 將所有流量路由到剩餘的健康區域。 健康區域中的 Kubernetes 叢集和 Pod 繼續服務請求。
在這種情況下要小心，以補償剩餘叢集的增加的請求和流量。 請考慮下列幾點：
- 確保網路和運算資源的大小合適，以吸收因區域故障轉移而導致的流量突然增加。 例如，使用 Azure CNI 時，請確保您擁有足夠大的子網，能夠在流量激增時支援所有 Pod IP 位址。
- 使用水平 Pod 自動調整程式來增加複本計數，以針對增加的區域需求進行補償。
- 使用 AKS 叢集自動調整程式來增加 Kubernetes 執行個體節點計數，以針對增加的區域需求進行補償。
關於詳細資訊，請參閱水平 Pod 自動縮放器和 AKS 叢集自動縮放器。
網路拓撲
與 AKS 基準參考架構類似，此架構使用中心輻射型網路拓撲。 除了 AKS 基準參考體系架構中指定的注意事項之外，請考慮以下最佳做法：
- 為每個區域 AKS 執行個體實施一組中心輻射型虛擬網路。 在每個區域內，每個分支都與中心虛擬網路對等。
- 透過每個區域中心網路中的 Azure 防火牆執行個體路由所有出站流量。 利用 Azure 防火牆管理員策略來管理所有區域的防火牆原則。
- 遵循 AKS 基準參考架構中的 IP 大小調整，並允許為節點和 Pod 規模操作提供更多 IP 位址，以防您在另一個區域遇到區域故障並且剩餘區域的流量大幅增加。
流量管理
使用 AKS 基準參考架構，工作負載流量將直接路由到 Azure 應用程式閘道執行個體，然後轉送至後端負載平衡器和 AKS 入口資源。 使用多個叢集時，用戶端請求將透過 Azure Front Door 執行個體路由，該執行個體會路由至 Azure 應用程式閘道執行個體。
下載此圖表的 Visio 檔案。
使用者向網域名稱 (例如
https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net) 發送請求，該請求將解析為 Azure Front Door 設定檔。 此請求使用為 Azure Front Door 的所有子網域所頒發的萬用字元憑證 (*.azurefd.net) 進行加密。 Azure Front Door 會根據 Web 應用程式防火牆原則驗證要求，選擇最快的來源 (基於運作狀況和延遲)，並使用公用 DNS 解析來源 IP 位址 (Azure 應用程式閘道執行個體)。Azure Front Door 將請求轉送至選定的適當應用程式閘道執行個體，該執行個體會充當區域戳記的入口點。 流量透過網路流動。 Azure Front Door 可確保來源的流量已加密。
考慮一種方法來確保應用程式閘道僅接受來自 Front Door 執行個體的流量。 一種方法是在包含應用程式閘道的子網路上使用網路安全群組。 這些規則可以根據來源、連接埠、目標等屬性過濾入站 (或出站) 流量。 透過資源屬性，可以設定指示 Azure 資源的 IP 位址的內建服務標籤。 這種抽象使得設定和維護規則以及追蹤 IP 位址變得更加容易。 此外，請考慮利用 Azure Front Door 在將請求傳送到來源之前新增至請求中的
X-Azure-FDID標頭，以確保應用程式閘道執行個體僅接受來自 Front Door 執行個體的流量。 關於 Front Door 標頭的更多資訊，請參閱 Azure Front Door 中 HTTP 標頭的通訊協定支援。
共享資源注意事項
雖然此場景的重點是讓多個 Kubernetes 執行個體分佈在多個 Azure 區域，但跨所有區域共用一些資源確實有意義。 一種方法是使用單一 Bicep 檔案來部署所有共用資源，然後使用另一種方法來部署每個區域戳記。 本部分詳細介紹了這些共享資源以及在多個 AKS 執行個體中使用每個共享資源的注意事項。
Container Registry
在該架構中使用 Azure 容器登錄提供容器鏡像服務。 叢集從登錄中提取容器鏡像。 在多區域叢集部署中使用 Azure 容器登錄時，請考慮下列事項。
各地區上市情況
在部署 AKS 叢集的每個區域中放置一個容器登錄。 這種方法可實現低延遲網路操作，從而實現快速、可靠的影像層傳輸。 這也表示您可以擁有多個影像服務端點，以便在區域服務不可用時提供可用性。 使用 Azure 容器登錄的異地複寫功能，你可以管理一個自動複製到多個區域的容器登錄。
請考慮建立單一登錄，將複本複製到包含叢集的每個 Azure 區域。 有關 Azure 容器登錄複製的詳細資訊，請參閱 Azure 容器登錄中的異地複寫。
此影像顯示了 Azure 入口網站中的多個 Azure 容器登錄副本。
叢集存取
每個 AKS 叢集都需要存取容器登錄，以便可以提取容器映像層。 有多種方式可用來建立 Azure 容器登錄的存取權。 在此架構中，為每個叢集建立一個託管身份，然後授予該 AcrPull 身份在容器登錄上的角色。 如需使用託管識別碼進行 Azure 容器登錄存取的詳細資訊和建議，請參閱 AKS 基準參考體系架構。
此設定是在叢集戳記 Bicep 檔案中定義的，以便每次部署新戳記時，新的 AKS 執行個體都會被授予存取權限。 因為容器登錄是共用資源，因此請確定您的部署包含容器登錄的資源標識碼做為參數。
Azure 監視器
Azure監視器容器深入解析功能是建議的工具，用於監視和了解叢集和容器工作負載的效能和運作狀況。 容器深入解析利用記錄分析工作區來儲存記錄資料，並利用 Azure 監視器指標來儲存數位時間序列資料。 Prometheus 指標也可以透過 Container Insights 收集，並且資料可以傳送到 Prometheus 的 Azure 監視器適用於 Prometheus 的受管理服務或 Azure Monitor 記錄。 如需詳細資訊，請參閱AKS 基準參考架構。
也可以設定 AKS 叢集診斷設定，以收集和分析來自 AKS 控制平面元件的資源記錄，並將其轉送到記錄分析工作區。
當您為多區域架構設計監控解決方案時，考慮每個戳記之間的耦合非常重要。 您可以部署一個由每個 Kubernetes 叢集共用的記錄分析工作區。 與其他共享資源一樣，定義區域戳記以使用有關單一全域共享記錄分析工作區的資訊，並將每個區域叢集連接到該共享工作區。 當每個區域叢集向單一記錄分析工作區發送診斷記錄時，你可以使用這些資料以及資源指標來更輕鬆地建立報表和儀表板，幫助你了解整個多區域解決方案的運作情況。
Azure Front Door
Azure Front Door 用於負載平衡並將流量路由到每個 AKS 叢集。 Azure Front Door 也支援第 7 層全域路由。 此場景需要這些功能。
叢集組態
在新增每個區域 AKS 執行個體時，與 Kubernetes 叢集一起部署的應用程式閘道需要在 Azure Front Door 中註冊為來源，這使其可用於路由。 此操作需要更新您的基礎設施作為程式碼資產。 或者，可以將此操作與部署設定分離，並使用 Azure CLI 等工具進行管理。
憑證
Azure Front Door 不支援使用自簽名憑證的來源，即使在開發或測試環境中也是如此。 若要啟用 HTTPS 流量，您需要建立由憑證授權單位 (CA) 簽署的 TLS/SSL 憑證。 有關 Front Door 支援的其他 CA 的信息，請參閱允許的憑證授權單位在 Azure Front Door 上啟用自訂 HTTPS。
對於測試或非生產集群，您可以考慮使用 Certbot 為每個應用程式閘道建立 Let's Encrypt Authority X3 憑證。
規劃生產叢集時，請使用組織的首選方法來取得 TLS 憑證。
叢集存取和身份識別
如 AKS 基準參考架構中所述，我們建議您使用 Microsoft Entra ID 作為叢集的身分提供者。 然後，Microsoft Entra 群組可用於控制對叢集資源的存取。
當您管理多個叢集時，您需要決定存取架構。 這些選項包括：
- 建立一個全域叢集範圍的存取群組，其中成員可以存取叢集中每個 Kubernetes 執行個體的所有物件。 此選項提供最低限度的管理需求；然而，它賦予任何組成員顯著的特權。
- 為每個 Kubernetes 執行個體建立單獨的存取群組，用於授予對單獨叢集執行個體中的物件的存取權限。 使用此選項，管理開銷確實會增加；但是，它還提供更細粒度的叢集存取。
- 定義 Kubernetes 物件類型和命名空間的精細存取控制，並將結果與 Microsoft Entra 群組架構相關聯。 使用此選項，管理開銷會大幅增加；然而，這不僅提供對每個叢集的精細存取，還提供對每個叢集內的命名空間和 Kubernetes API 的精細存取。
對於管理存取權限，請考慮為每個區域建立 Microsoft Entra 群組。 授予每個群組對該區域中相應集群戳記的完全存取權限。 然後，每個群組的成員都具有對相應叢集的管理存取權。
有關使用 Microsoft Entra ID 管理 AKS 叢集存取的詳細信息，請參閱 AKS Microsoft Entra 整合。
資料、狀態和快取
使用一組全球分散式 AKS 叢集時，請考慮可能跨叢集執行的應用程式、進程或其他工作負載的體系架構。 如果基於狀態的工作負載分佈在叢集中，它們是否需要存取狀態儲存？ 如果由於故障而在叢集中的其他位置重新建立程序，則工作負載或進程是否可以繼續存取依賴的狀態儲存或快取解決方案？ 狀態可以透過多種方式存儲，但即使在單一 Kubernetes 叢集中管理起來也很複雜。 新增多個 Kubernetes 叢集時，複雜度會增加。 由於區域存取和複雜性問題，請考慮將應用程式設計為使用全球分散式狀態儲存服務。
此架構的設計不包括狀態問題的設定。 如果跨多個 AKS 叢集執行單一邏輯應用程序，請考慮將工作負載架構為使用全球分散式資料服務，例如 Azure Cosmos DB。 Azure Cosmos DB 是一個全球分散式資料庫系統，可讓你從資料庫的本機副本讀取和寫入資料，而 Cosmos DB 服務為你管理異地複寫。 如需詳細資訊，請參閱 Azure Cosmos DB。
如果您的工作負載使用快取解決方案，請確保建置快取服務，以便它們即使在故障轉移事件期間也能保持正常運作。 確保工作負載本身能夠適應與快取相關的故障轉移，並且所有區域 AKS 執行個體上都存在快取解決方案。
成本最佳化
使用 Azure 定價計算器來估算體系架構中所使用的服務的成本。 Microsoft Azure 架構完善的框架中的成本最佳化部分介紹了其他最佳做法，最佳化成本一文中介紹了具體的成本最佳化設定選項。
考慮透過 Kubernetes 特定的構造啟用 AKS 成本分析，以進行粒度叢集基礎設施成本分配。