此參考架構詳細說明如何在主動/主動和高可用性設定中跨多個區域執行 Azure Kubernetes Service （AKS） 叢集的多個實例。
此架構是以 AKS 基準架構為基礎，Microsoft AKS 基礎結構的建議起點。 AKS 基準會詳細說明基礎結構功能，例如 Microsoft Entra 工作負載 ID、輸入和輸出限制、資源限制，以及其他安全的 AKS 基礎結構組態。 本檔未涵蓋這些基礎結構詳細數據。 建議您先熟悉 AKS 基準，再繼續進行多重區域內容。
架構
GitHub 提供此架構的參考實作。
元件
多區域 AKS 參考架構中會使用許多元件和 Azure 服務。 這裡只會列出具有此多重叢集架構唯一性的元件。 如需其餘專案，請參閱 AKS 基準架構。
- 區域 AKS 叢集： 部署多個 AKS 叢集，每個叢集都位於個別的 Azure 區域中。 在正常作業期間，網路流量會在所有區域之間路由傳送。 如果某個區域變成無法使用，流量會路由傳送至最接近發出要求之用戶的區域。
- 區域中樞輪輻網路： 會為每個區域 AKS 實例部署區域中樞輪輻網路組。 Azure 防火牆 管理員原則可用來管理所有區域的防火牆原則。
- 區域金鑰保存庫：Azure 金鑰保存庫 會在每個區域中佈建。 密鑰保存庫可用來儲存 AKS 叢集專屬的敏感性值和密鑰，以及該區域中的支持服務。
- 多個記錄工作區： 區域Log Analytics工作區用於儲存區域網路計量和診斷記錄。 此外，共用Log Analytics實例可用來儲存所有AKS實例的計量和診斷記錄。
- 全域 Azure Front Door 配置檔：Azure Front Door 可用來平衡流量，並將流量路由傳送至位於每個 AKS 叢集前的區域 Azure 應用程式閘道 實例。 Azure Front Door 允許第 7 層全域路由，這兩者都是此參考架構的必要專案。
- 全域容器登錄： 工作負載的容器映像會儲存在受控容器登錄中。 在此架構中，單一 Azure Container Registry 會用於叢集中的所有 Kubernetes 實例。 Azure Container Registry 的異地複寫可讓映像複寫至選取的 Azure 區域，並持續存取映像，即使區域發生中斷也一樣。
設計模式
此參考架構使用兩種雲端設計模式：
- 地理區域（地理節點），其中任何區域都可以服務任何要求。
- 部署戳記，其中會從單一來源部署應用程式或應用程式元件的多個獨立複本，例如部署範本。
地理模式考慮
選取要部署每個 AKS 叢集的區域時，請考慮靠近工作負載取用者或您的客戶的區域。 此外，請考慮使用 跨區域複寫。 跨區域複寫會以非同步方式複寫其他 Azure 區域內相同的應用程式和資料，以進行災害復原保護。 當您的叢集調整超過兩個區域時，請繼續規劃每個 AKS 叢集配對的跨區域複寫。
在每個區域內，AKS 節點集區中的節點會分散到多個可用性區域，以協助防止因為區域性失敗而發生問題。 一組有限的區域支援可用性區域，這會影響區域叢集放置。 如需 AKS 和可用性區域的詳細資訊，包括支援的區域清單，請參閱 AKS 可用性區域。
部署戳記考慮
當您管理多區域 AKS 解決方案時，您會跨多個區域部署多個 AKS 叢集。 這些叢集的每一個 都會被視為戳記。 如果區域失敗，或您需要為叢集新增更多容量或區域存在，您可能需要建立新的戳記實例。 選取建立和管理部署戳記的程式時，請務必考慮下列事項：
- 針對允許一般化設定的戳記定義選取適當的技術。 參考實作會使用 Bicep 來定義基礎結構即程序代碼。
- 使用部署輸入機制提供實例特定值，例如變數或參數檔案。
- 選取允許彈性、可重複和等冪部署的部署工具。
- 在作用中/主動戳記組態中，請考慮流量如何在每個戳記之間平衡。 參考實作會使用 Azure Front Door 進行全域負載平衡。
- 隨著戳記從集合中新增和移除，請考慮容量和成本考慮。
- 請考慮如何取得戳記集合的可見度並監視為單一單位。
這些項目會詳述此參考架構的下列各節中的特定指引。
車隊管理
此解決方案代表多叢集和多重區域拓撲，而不需要包含進階協調器，即可將所有叢集視為統一車隊的一部分。 當叢集計數增加時，請考慮在 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 入口網站 會因為遺漏步驟或無法使用設定選項而開啟設定錯誤的機會。 使用入口網站部署和設定許多叢集是一個耗時的程式，需要一或多個工程師的焦點。 如果您使用 Azure CLI 或 Azure PowerShell，您可以使用命令行工具來建構可重複且自動化的程式。 不過，等冪性、部署失敗控制和失敗復原的責任在於您和您所建置的腳本。
使用多個 AKS 實例時，建議您考慮基礎結構即程式代碼解決方案，例如 Bicep、Azure Resource Manager 範本或 Terraform。 基礎結構即程式代碼解決方案提供自動化、可調整和等冪部署解決方案。 此參考架構包含解決方案共用服務的 Bicep 實作，以及 AKS 叢集和其他區域服務的 Bicep 實作。 如果您使用基礎結構即程序代碼，可以使用一般化組態來定義部署戳記，例如網路、授權和診斷。 部署參數檔案可以搭配區域特定值來提供。 透過此設定，單一範本可用來跨任何區域部署幾乎完全相同的戳記。
開發和維護基礎結構作為程式代碼資產的成本可能很高。 在某些情況下，將基礎結構定義為程式代碼的額外負荷可能會超過優點，例如，當您有非常小（例如，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 擴充功能，在部署叢集之後，自動且立即啟用啟動載入叢集。
GitOps 會在 AKS 基準參考架構中更深入地詳細說明。 藉由使用以 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 無法使用，則會在其餘的之間路由傳送流量。 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 應用程式閘道 實例。
使用者會將要求傳送至功能變數名稱（例如
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 實例的流量。 其中一種方法是在包含 應用程式閘道 的子網上使用網路安全組。 規則可以根據來源、埠、目的地等屬性來篩選輸入（或輸出）流量。 Source 屬性可讓您設定內建服務標籤，指出 Azure 資源的 IP 位址。 此抽象概念可讓您更輕鬆地設定和維護規則，並追蹤IP位址。 此外，請考慮使用
X-Azure-FDIDAzure Front Door 在將要求傳送至來源之前新增至要求的標頭，以確保 應用程式閘道 實例只接受來自 Front Door 實例的流量。 如需 Front Door 標頭的詳細資訊，請參閱 Azure Front Door 中 HTTP 標頭的通訊協議支援。
共用資源考慮
雖然此參考架構的重點在於讓多個 Kubernetes 實例分散到多個 Azure 區域，但跨所有區域共用某些資源確實有意義。 AKS 多重區域參考實作會使用單一 Bicep 檔案來部署所有共用資源，然後再使用另一個來部署每個區域戳記。 本節詳細說明每個共享資源，以及跨多個 AKS 實例使用每個資源的考慮。
Container Registry
此參考架構會使用 Azure Container Registry 來提供容器映像服務。 叢集會從登錄提取容器映像。 在多區域叢集部署中使用 Azure Container Registry 時，請考慮下列專案。
各地區上市情況
將容器登錄放在部署 AKS 叢集的每個區域中。 這種方法允許低延遲的網路作業，啟用快速、可靠的映射層傳輸。 這也表示您有多個映像服務端點，可在區域服務無法使用時提供可用性。 使用 Azure Container Registry 的異地復寫功能，可讓您管理自動復寫到多個區域的一個容器登錄。
AKS 多重區域參考實作會將單一登錄和複本建立至用於叢集的每個區域。 如需 Azure Container Registry 複寫的詳細資訊，請參閱 Azure Container Registry 中的異地複寫。
顯示來自 Azure 入口網站 內多個 Azure Container Registry 複本的影像。
叢集存取
每個 AKS 叢集都需要存取容器登錄，才能提取容器映射層。 有多種方式可用來建立 Azure Container Registry 的存取權。 此參考架構會針對每個叢集使用受控識別，然後授與 AcrPull 容器登錄上的角色。 如需使用 Azure Container Registry 存取受控識別的詳細資訊和建議，請參閱 AKS 基準參考架構。
此組態定義於叢集戳記 Bicep 檔案中，如此一來，每次部署新的戳記時，就會將新的 AKS 實例授與存取權。 因為容器登錄是共用資源，因此請確定您的部署包含容器登錄的資源標識碼做為參數。
Azure 監視器
Azure 監視器容器深入解析功能是建議的工具，可用來監視和瞭解叢集和容器工作負載的效能和健康情況。 容器深入解析 會利用Log Analytics工作區來儲存記錄數據，以及 Azure 監視器計量 來儲存數值時間序列數據。 Container Insights 也可以收集 Prometheus 計量，並將數據傳送至 Prometheus 或 Azure 監視器記錄的 Azure 監視器受控服務。 如需詳細資訊，請參閱 AKS 基準參考架構。
您也可以設定 AKS 叢集診斷設定 ，從 AKS 控制平面元件收集及分析資源記錄，並將其轉送至 Log Analytics 工作區。
當您設計多區域架構的監視解決方案時，請務必考慮每個戳記之間的結合。 多重區域 AKS 參考實作會利用每個 Kubernetes 叢集共用的單一 Log Analytics 工作區。 如同其他共用資源，請定義您的區域戳記，以取用單一全域共用Log Analytics工作區的相關信息，並將每個區域叢集連線到該共用工作區。 當每個區域叢集向該單一 Log Analytics 工作區發出診斷記錄時，您可以使用資料以及資源計量，更輕鬆地建置報告和儀錶板，以協助您了解整個多區域解決方案的執行方式。
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 憑證。 憑證產生程式需要部署一些暫時的 Azure 資源。 如需參考實作如何建立 TLS 憑證的詳細資訊，請參閱 使用 DNS 前置 詞範例產生 Azure 公用 IP 的憑證。
規劃生產叢集時，請使用您組織的慣用方法來購買 TLS 憑證。
叢集存取和身分識別
如 AKS 基準參考架構中所述，建議您使用 Microsoft Entra ID 作為叢集的識別提供者。 然後可以使用Microsoft Entra 群組來控制叢集資源的存取。
當您管理多個叢集時，您必須決定存取架構。 這些選項包括：
- 建立全域叢集範圍的存取群組，讓成員可以存取叢集中每個 Kubernetes 實例的所有物件。 此選項提供最少的管理需求;不過，它會將重要許可權授與任何群組成員。
- 為每個 Kubernetes 實例建立個別存取群組，用來授與個別叢集實例中物件的存取權。 使用此選項時，系統管理額外負荷會增加;不過，它也會提供更細微的叢集存取。
- 定義 Kubernetes 物件類型和命名空間的細微訪問控制，並將結果與Microsoft Entra 群組結構相互關聯。 使用此選項時，系統管理額外負荷會大幅增加;不過，它不僅提供每個叢集的細微存取，而且會提供每個叢集中找到的命名空間和 Kubernetes API。
透過包含的參考實作，會建立兩個Microsoft Entra 群組以進行系統管理存取。 這些群組是在使用部署參數檔案的叢集戳記部署時間指定。 每個群組的成員都有對應叢集戳記的完整存取權。
如需使用 Microsoft Entra 識別符管理 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 成本分析 。