Azure Kubernetes Service 的區域復原建議 （AKS）

適用於: ✔️ AKS 自動化 ✔️ AKS 標準

區域復原是執行生產等級 Kubernetes 叢集的關鍵部分。 透過 Kubernetes 的核心可擴縮性，充分利用資料中心的獨立基礎結構，僅在需要時才佈建新的節點，不會產生額外的成本。

在本文中，您將學習AKS區域韌性的建議，包括如何：

• 讓 AKS 叢集組件具備區域韌性。
• 針對區域失效情境設計無狀態應用程式。
• 選擇儲存冗餘選項。
• 測試區域斷層期間的應用與平台行為。

AKS 叢集模式與區域韌性

AKS 支援兩種叢集模式：

• AKS Automatic，提供更多預先設定的平台預設值。
• AKS 標準，提供更廣泛的直接操作控制。

本文中的區域韌性原則適用於兩種叢集模式。 關鍵差異在於平台營運的所有權。

欲了解各模式的完整功能行為，請參閱 AKS 自動與 AKS 標準功能比較。

讓您的 AKS 叢集元件區域具有彈性

以下章節說明AKS區域韌性的關鍵決策點。 它們並非全面。 你也應該驗證資料儲存、身分識別系統和外部服務等相依性元件的區域復原能力。

建立區域備援叢集和節點集區

AKS 允許你在叢集和節點池建立時選擇多個 AZ。 在支援多個 AZ 的區域中，控制平面會自動分散在各區域之間。 節點池節點分布於所選區域。 此方法可確保控制平面和節點散佈到多個 AZ，以在 AZ 失敗時提供復原能力。

叢集模式指引：

• AKS 自動：許多平台預設是預先設定好的。 你仍應驗證業務關鍵工作負載是否刻意分散在不同區域，且故障行為符合要求。
• AKS 標準：明確設計節點池拓撲、縮放設定及故障域行為。

下列範例示範如何使用 Azure CLI，建立具有三個節點的叢集，並散佈到三個 AZ：

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3

建立叢集之後，您可以使用下列命令，從標籤擷取每個代理程式節點的區域和可用性區域：

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

下列範例輸出顯示每個代理程式節點的區域和可用性區域：

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

如需詳細資訊，請參閱在 Azure Kubernetes Service (AKS) 中使用可用性區域。

確定 Pod 散佈到 AZ

Pod 放置原則在 AKS 自動與 AKS 標準中都是工作負載層級考量。 平台預設不會取代工作負載層級的拓撲需求。

從 Kubernetes 版本 1.33 開始，AKS 中的預設 Kube-Scheduler 已設定為針對MaxSkew使用值為 1 的topology.kubernetes.io/zone ：

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

此配置僅針對區域間單一艙體差，降低區域失效導致部署中斷的風險。

如果您的部署有特定的拓撲需求，請在 Pod 規格中覆寫這些預設值。您可以根據zone和hostname標籤使用 Pod 拓撲分散限制，將 Pod 分散到區域內的不同 AZ，以及各 AZ 內的不同主機上。

例如，假設您有一個四個節點的叢集，其中三個標籤為 app: mypod-app 的 Pod 分別位於 node1、node2 和 node3 中。 如果想要盡可能將傳入部署裝載於不同的節點上，您可以使用類似下列範例的資訊清單：

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

如需設定 Pod 分佈及瞭解含意MaxSkew的詳細資訊，請參閱 Kubernetes Pod 拓撲文件。 例如，nodeTaintsPolicy: Honor 如何影響 Pod 分布。

設定 AZ 感知網路功能

如果您有提供網路流量的 Pod，則應該在多個 AZ 之間載入平衡流量，以確保您的應用程式具有高可用性且可復原失敗。 您可以使用 Azure Load Balancer 將連入流量散佈到 AKS 叢集中的節點。

Azure Load Balancer 同時支持內部和外部負載平衡，且您可以將其設定為使用標準 SKU 來進行區域備援負載平衡。 標準 SKU 是 AKS 中的預設 SKU，其支援可用性區域的區域復原能力，以確保應用程式不會受到區域失敗的影響。 發生區域失敗案例時，區域備援標準 SKU 負載平衡器不會受到失敗的影響，並可讓您的部署繼續為來自其餘區域的流量提供服務。 您可以使用全域負載平衡器，例如 Front Door 或 流量管理員，或使用區域 AKS 叢集前的跨區域負載平衡器，以確保應用程式不會受到區域失敗的影響。 若要在 AKS 中建立標準 SKU 負載平衡器，請參閱在 Azure Kubernetes Service (AKS) 中使用 Standard Load Balancer。

為了確保應用程式的網路流量能夠復原失敗，您應該為 AKS 工作負載設定 AZ 感知網路功能。 Azure 提供各種支援 AZ 的網路服務：

• Azure VPN 閘道：您可以在 Azure AZ 中部署 VPN 和 ExpressRoute 閘道，以提升虛擬網路閘道的復原能力、延展性和可用性。 如需詳細資訊，請參閱在可用性區域中建立區域備援虛擬網路閘道。
• Azure 應用程式閘道 v2：Azure 應用程式閘道提供區域 L7 負載平衡器，並提供可用性區域支援。 如需詳細資訊，請參閱使用 Azure 應用程式閘道引導網路流量。
• Azure Front Door：Azure Front Door 提供全域 L7 負載平衡器，並運用存在點 (POP) 或 Azure 內容傳遞網路 (CDN)。 如需詳細資訊，請參閱 Azure Front Door 位置。

設定區域備援、異地複寫的容器登錄

若要確保您的容器映像具有高可用性且可復原失敗，您應該設定區域備援容器登錄。 Azure Container Registry (ACR) Premium SKU 支援異地複寫和選擇性區域備援。 這些功能提供可用性並減少區域作業的延遲。

確保金鑰和秘密的可用性和備援性

Azure Key Vault 提供多層備援功能，以確保您的金鑰和密碼會保持可供應用程式使用，甚至在服務的個別元件失敗時，或者如果 Azure 區域或 AZ 無法使用時也是如此。 如需詳細資訊，請參閱 Azure Key Vault 可用性與備援。

使用自動縮放功能

您可以使用自動調整功能來改善 AKS 中的應用程式可用性和復原能力，以協助您達成下列目標：

• 根據 Pod 的 CPU 和記憶體使用量來相應增加或減少，以最佳化資源使用率和成本效益。
• 在發生區域失敗時新增更多節點或 Pod，以增強容錯和復原。

您可以使用水平 Pod 自動調整程式 (HPA) 和叢集自動調整程式，在 AKS 中實作自動調整。 HPA 會根據觀察到的 CPU 使用率、記憶體使用率、自訂計量和其他服務的計量，自動調整部署中的 Pod 數目。 叢集自動縮放器會根據待處理的 pod 及待處理 pod 上的資源要求，自動調整節點集區中的節點數量。

叢集模式指引：

• AKS 自動化：著重於工作負載的資源要求與限制、Pod 分布原則及中斷控制，讓預先設定的平台擴縮機制能在可用區承受壓力時恢復服務。
• AKS 標準：明確設計節點池邊界、縮放策略及自動縮放器設定，以符合區域感知排程限制。

AKS Karpenter 提供者功能可在您的 AKS 叢集上使用 Karpenter 自動配置節點。 如需詳細資訊，請參閱 AKS Karpenter 提供者功能概觀。

AKS 的 Kubernetes 事件驅動自動調整 (KEDA) 附加元件會套用事件驅動自動調整，以根據外部服務的計量調整應用程式以符合需求。 如需詳細資訊，請參閱在 Azure Kubernetes Service (AKS) 中安裝 KEDA 附加元件。

AKS 叢集模式的區域縮放策略

針對可感知區域的擴增行為，請讓節點集區模型與排程器限制條件及叢集模式保持一致。

AKS 標準

使用帶有可用性區域的叢集自動擴展器時，常見的最佳做法是每個區域設置一個節點池。 你可以設定 --balance-similar-node-groups 為 ， True 以維持擴展時節點間的平衡分布。

為什麼這很重要：

• 叢集自動縮放器是以節點集區為單位模擬排程，而非依特定區域放置位置進行模擬。
• 在多區域節點池中，擴容可能會將新節點部署到仍會違反嚴格拓撲分散限制的區域，導致 pod 處於 Pending 狀態。
• 虛擬機器擴展集採用盡力而為的區域平衡。 在區域容量限制或區域降級事件中，配置可能失敗，導致節點池進入退換狀態。
• 每個區域使用一個節點池，能改善區域專屬縮放行為的控制。

叢集自動縮放器並不具備區域感知能力，區域分配是由底層的 虛擬機器擴展集 處理，而非由 AKS 處理。 當對單一多區域節點池使用基於區域的 pod 拓撲擴散約束 時，這項最佳實務更為重要，因為限制性限制可能導致 pod 處於待處理狀態，尤其是在容量受限區域或區域降級情境下。

AKS 自動化系统

AKS 自動系統使用預先設定的管理節點行為及節點自動配置預設值。 你不能假設關鍵工作負載在沒有工作負載層級政策的情況下具備區域韌性。

對於關鍵服務，請驗證：

• Pod 拓撲會在不同區域間分散行為。
• 區域壓力下的恢復行為。
• 在使用嚴格約束時的排程結果。
• 當某區域無法使用時的應用行為。

設計無狀態應用程式

當應用程式無狀態時，應用程式邏輯和資料會分離，而 Pod 不會在其本機磁碟上儲存任何持續性或工作階段資料。 此設計可讓應用程式輕鬆地相應增加或減少，而不必擔心資料遺失。 無狀態應用程式對於失敗更具復原性，因為當節點失敗時，可以在不同的節點上輕鬆取代或重新排程這些應用程式。

在設計使用 AKS 的無狀態應用程式時，應該使用受管型 Azure 服務，例如 Azure Databases、 Azure Managed Redis 或 Azure 儲存體 來儲存應用程式資料。 使用這些服務可確保您的流量可以跨節點和區域移動，而不會造成資料遺失或影響使用者體驗的風險。 您可以使用 Kubernetes 部署 (英文)、服務 (英文) 和健康情況探查 (英文) 來管理無狀態 Pod，並甚至確保跨區域散發。

做出儲存體磁碟決策

根據應用程式需求選擇正確的磁碟類型

Azure 針對永續性儲存體提供兩種類型的磁碟：本地備援儲存體 (LRS) 和區域備援儲存體 (ZRS)。 LRS 會在單一 AZ 內複寫您的資料。 ZRS 會將您的資料複寫到區域內的多個 AZ。 從 AKS 1.29 版開始，預設儲存類別會使用 ZRS 磁碟進行永續性儲存體。 如需詳細資訊，請參閱 AKS 內建儲存體類別。

應用程式複寫資料的方式可能會影響您選擇的磁碟。 如果您的應用程式位於多個區域，並從應用程式內複寫資料，則您可以使用每個 AZ 中的 LRS 磁碟來達到復原能力，因為如果有一個 AZ 關機，其他 AZ 會有最新資料供其使用。 如果您的應用程式層未處理這類複寫，則 ZRS 磁碟是較佳的選擇，因為 Azure 會處理儲存體層中的複寫。

下表概述每個磁碟類型的優缺點：

如需 LRS 和 ZRS 磁碟類型的詳細資訊，請參閱 Azure 儲存體備援。 若要在 AKS 中佈建儲存體磁碟，請參閱在 Azure Kubernetes Service (AKS) 中佈建 Azure 磁碟儲存體。

監視磁碟效能

若要確保 AKS 中儲存體磁碟的最佳效能和可用性，您應該監視關鍵計量，例如 IOPS、輸送量和延遲。 這些計量可協助您找出可能影響應用程式效能的任何問題或瓶頸。 如果您發現任何一致的效能問題可能需要重新考量儲存體磁碟類型或大小。 您可以使用 Azure 監視器來收集及視覺化這些計量，並設定警示來通知您任何效能問題。

如需詳細資訊，請參閱使用 Azure 監視器監視 Azure Kubernetes Service (AKS)。

針對 AZ 復原能力的測試

方法 1：單一 AZ 中的 Cordon 和清空節點

測試 AKS 叢集以進行 AZ 復原能力的其中一種方式，是清空某個區域中的節點，並查看其如何影響流量，直到容錯移轉至另一個區域為止。 這個方法會模擬一個真實世界的案例，因為災害或中斷而無法使用整個區域。 若要測試此案例，您可以使用 kubectl drain 命令，從節點正常收回所有 Pod，並將其標示為無法排程。 接著，您可以使用 Azure 監視器或 Prometheus 等工具來監視叢集流量和效能。

下表概述此方法的優缺點：

方法 2：使用 Azure Chaos Studio 模擬 AZ 失敗

另一種測試 AKS 叢集 AZ 韌性的方法，是使用 Azure Chaos Studio Workspaces 模擬區域斷線。 在範圍限定於叢集基礎結構資源群組的工作區中執行 MC_ 案例（依預設，其名稱以 開頭）。 此情境會關閉某一可用性區域中的節點虛擬機擴展集執行個體，讓您可以觀察 Pod 重新排程到其餘可用性區域，並使用計量與記錄來衡量應用程式的可用性、延遲及錯誤率。 欲獲得逐步指引，請參閱「使用 Chaos Studio Workspaces 測試 AKS 韌性」。

下表概述此方法的優缺點：

如需詳細資訊，請參閱什麼是 Azure Chaos Studio？。

相關內容

• 什麼是 AKS Automatic？
• 區域冗餘 AKS 叢集與儲存指南