此參考架構詳細說明如何在主動/主動和高可用性設定中跨多個區域執行 Azure Kubernetes Service （AKS） 叢集的多個實例。
此架構是以 AKS 基準架構 為基礎，Microsoft 建議的 AKS 基礎結構起點。 AKS 基準會詳細說明基礎結構功能，例如Microsoft Entra 工作負載 ID、輸入和輸出限制、資源限制，以及其他安全的 AKS 基礎結構組態。 本檔未涵蓋這些基礎結構詳細資料。 建議您先熟悉 AKS 基準，再繼續進行多重區域內容。
架構
GitHub 提供 此架構的參考實作。
元件
多區域 AKS 參考架構中會使用許多元件和 Azure 服務。 以下僅列出具有此多重叢集架構唯一性的元件。 針對其餘專案，參考 AKS 基準架構 。
- 多個叢集/多個區域 會部署多個 AKS 叢集，每個叢集都位於個別的 Azure 區域中。 在正常作業期間，網路流量會在所有區域之間路由傳送。 如果某個區域變成無法使用，流量會路由傳送至最接近發出要求之使用者的區域。
- 每個區域的 中樞輪輻網路：每個區域 AKS 實例都會部署區域中樞輪輻網路組。 Azure 防火牆管理員原則可用來管理所有區域的防火牆原則。
- 區域金鑰存放區 Azure 金鑰保存庫會布建在每個區域中，以儲存 AKS 實例專屬的敏感性值和金鑰，以及該區域中找到的支援服務。
- Azure Front Door Azure Front door 可用來平衡流量，並將流量路由傳送至區域Azure 應用程式閘道實例，該實例位於每個 AKS 叢集前面。 Azure Front Door 允許第七層全域路由，這兩者都是此參考架構的必要專案。
- Log Analytics 區域 Log Analytics 實例可用來儲存區域網路計量和診斷記錄。 此外，共用 Log Analytics 實例可用來儲存所有 AKS 實例的計量和診斷記錄。
- 容器登錄 工作負載的容器映射會儲存在受控容器登錄中。 在此架構中，單一 Azure Container Registry 會用於叢集中的所有 Kubernetes 實例。 Azure Container Registry 的異地複寫可讓映射複寫至選取的 Azure 區域，並持續存取映射，即使區域發生中斷也一樣。
設計模式
此參考架構使用兩種雲端設計模式。 地理節點 （geodes），其中任何區域都可以服務任何要求，以及 部署戳記 ，其中會從單一來源 （部署範本） 部署應用程式或應用程式元件的多個獨立複本。
地理節點模式考慮
選取要部署每個 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 叢集 + 區域服務的另一個。 如果您使用基礎結構即程式碼，可以使用一般化組態來定義部署戳記，例如網路、授權和診斷。 部署參數檔案可以搭配區域特定值來提供。 透過此設定，單一範本可用來跨任何區域部署幾乎完全相同的戳記。
開發和維護基礎結構作為程式碼資產的成本可能很高。 在某些情況下，例如部署靜態/固定數目的 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 應用程式閘道實例。
使用者會將要求傳送至功能變數名稱（例如
https://contoso-web.azurefd.net），此名稱會解析為 Azure Front Door 實例。 此要求會以針對 Azure Front Door 的所有子域發出的萬用字元憑證 （*.azurefd.net） 加密。 Azure Front Door 實例會根據 WAF 原則驗證要求、選取最快的後端（根據健康情況和延遲），並使用公用 DNS 解析後端 IP 位址（Azure 應用程式閘道實例）。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 來提供容器映射服務（pull）。 在多區域叢集部署中使用 Azure Container Registry 時，請考慮下列專案。
各地區上市情況
將容器登錄放置在部署 AKS 叢集的每個區域中，可讓網路關閉作業、啟用快速、可靠的映射層傳輸。 有多個映射服務端點可在區域服務無法使用時提供可用性。 使用 Azure Container Registries 異地複寫功能可讓您管理複寫到多個區域的一個 Container Registry 實例。
AKS 多重區域參考實作會建立單一 Container Registry 實例，並將這個實例的複本複製到每個叢集區域。 如需 Azure Container Registry 複寫的詳細資訊，請參閱 Azure Container Registry 中的異地複寫。
顯示來自Azure 入口網站內多個 ACR 複本的影像。
叢集存取
每個 AKS 實例都需要從 Azure Container Registry 提取映射層的存取權。 有多種方式可用來建立 Azure Container Registry 的存取權;此參考架構會針對每個叢集使用 Azure 受控識別，然後授與 Container Registry 實例上的 AcrPull 角色。 如需使用受控識別進行 Container Registry 存取的詳細資訊和建議，請參閱 AKS 基準參考架構 。
此設定定義于叢集戳記 ARM 範本中，以便每次部署新的戳記時，就會授與新的 AKS 實例存取權。 因為 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 流量，您必須建立由憑證授權單位單位 （CA） 簽署的 TLS/SSL 憑證。 參考實作會使用 Certbot 來建立 Let's Encrypt Authority X3 憑證。 規劃生產叢集時，請使用您組織的慣用方法來購買 TLS 憑證。
如需 Front Door 支援的其他 CA 相關資訊，請參閱 允許的憑證授權單位單位在 Azure Front Door 上啟用自訂 HTTPS。
叢集存取和身分識別
如 AKS 基準參考架構 中所述 ，建議使用 Microsoft Entra ID 作為叢集的存取識別提供者。 接著可以使用 Microsoft Entra 群組來控制叢集資源的存取。
當您管理多個叢集時，您必須決定存取架構。 這些選項包括：
- 建立全域叢集範圍的存取群組，讓成員可以存取叢集中每個 Kubernetes 實例的所有物件。 此選項提供最少的管理需求;不過，它會將重要許可權授與任何群組成員。
- 為每個 Kubernetes 實例建立個別存取群組，用來授與個別叢集實例中物件的存取權。 使用此選項時，系統管理額外負荷會增加;不過，它也會提供更細微的叢集存取。
- 定義 Kubernetes 物件類型和命名空間的細微存取控制，並將結果與 Azure 目錄群組結構相互關聯。 使用此選項時，系統管理額外負荷會大幅增加;不過，它不僅提供每個叢集的細微存取，而且會提供每個叢集中找到的命名空間和 Kubernetes APIS。
透過包含的參考實作，會建立兩個 Microsoft Entra 群組以供系統管理員存取。 這些群組是在使用部署參數檔案的叢集戳記部署時間指定。 每個群組的成員都有對應叢集戳記的完整存取權。
如需使用 Microsoft Entra 識別碼管理 AKS 叢集存取的詳細資訊，請參閱 AKS Microsoft Entra 整合 。
資料、狀態和快取
使用 AKS 實例的全域分散式叢集時，請考慮應用程式、進程或其他可能跨叢集執行的工作負載架構。 當狀態型工作負載分散到叢集時，是否需要存取狀態存放區？ 如果因為失敗而重新建立叢集中其他地方的進程，工作負載或進程是否會繼續存取相依狀態存放區或快取解決方案？ 狀態可以透過許多方式達成：不過，在單一 Kubernetes 叢集中可能會很複雜。 在多個叢集 Kubernetes 實例中新增時，複雜度會增加。 由於區域存取和複雜度考慮，請考慮設計應用程式以使用全域分散式狀態存放區服務。
多重叢集參考實作不包含狀態考慮的示範或設定。 如果您跨叢集 AKS 實例執行應用程式，請考慮將工作負載架構為使用全域散發的資料服務，例如 Azure Cosmos DB。 Azure Cosmos DB 是全域分散式資料庫系統，可讓您從資料庫的本機複本讀取和寫入資料。 如需詳細資訊，請參閱 Azure Cosmos DB 。
如果您的工作負載使用快取解決方案，請確定其已建構，以便快取服務維持運作。 若要這樣做，請確定工作負載本身具有快取相關容錯移轉的復原能力，而且快取解決方案存在於所有區域 AKS 實例上。
成本最佳化
使用 Azure 定價計算機 來估計架構中使用的服務成本。 其他最佳做法請參閱 Microsoft Azure 架構良好架構中的成本優化 一節，以及優化成本 一文中的 特定成本優化組態選項。
請考慮針對 Kubernetes 特定建構的細微叢集基礎結構成本配置啟用 AKS 成本分析 。