使用 Chaos Studio Workspaces 進行 Azure Kubernetes Service （AKS） 韌性測試，方法是在叢集基礎設施資源群組中執行 Compute Zone Down Scenario，針對節點規模集進行測試。 此測試會關閉同一可用區域內的節點虛擬機，以便觀察工作負載恢復。 它測試的是節點基礎設施，而非叢集內的 pod 故障。
Important
Chaos Studio 的工作空間與場景目前已公開預覽。 Microsoft 提供此預覽版「現況」與「可用狀態」，不受服務等級協議或有限保固保護。 Microsoft 以盡力而為的方式提供預覽版的客戶支援。 這個預覽並非為製作用途設計。 欲了解更多資訊，請參閱以下文章：
Limitations
在公開預覽期間，工作空間中對 AKS 特定情境的支援有限：
- 目前還沒有一流的 AKS 區域關閉情境可以理解整個叢集。 計算區域停機情境直接以虛擬機器和虛擬機器擴展集為目標。
- 若要測試 AKS 節點韌性，您必須刻意將工作區的範圍限定在叢集的 基礎結構 資源群組（預設名稱開頭為
MC_），而不是包含叢集資源的資源群組。 如需背景資訊，請參閱 為何以您的 AKS 叢集為範圍的工作區找不到計算目標。 - 此方法針對節點集區的虛擬機器擴展集。 它不適用於由節點自動配置（NAP）建立的節點池。
欲了解完整的預覽限制清單，請參閱 Chaos Studio 工作區的限制與已知問題。
開始之前：先驗證你的叢集拓撲結構
這項測試會模擬區域故障，因此只有針對設計成可承受單一區域故障的叢集進行時才有意義。 在 Azure 入口網站中，打開你的 AKS 叢集，選擇設定>節點池，然後驗證：
- 可用性區域：你想測試的每個節點池跨越多個區域（例如「1、2、3」）。 如果您的節點集區未具備跨可用區備援，請先解決這個問題。 請參閱 AKS中的可用區域。
- 節點數量：節點數量足夠進行有意義的測試——理想狀況是每個區域有兩個或以上。 如果一個池節點少於三個，測試前先擴大規模。
- 容量餘裕：其餘區域可以承接你停用的區域所負載的工作。 如果無法，則 pod 在測試期間將保持待處理狀態 - 這本身就是一項韌性發現，但請確保您已做好因應此結果的準備。
- 選擇一個目標區域內有節點。 劇本的行動會依區域篩選;如果你鎖定一個沒有實例的區域，什麼事都不會發生，動作也會跳過。
尋找基礎設施資源群組與節點尺度集
找到叢集的基礎設施資源群組。 在 Azure 入口網站中，打開你的 AKS 叢集並選擇設定>屬性。 選擇基礎設施 資源群組 連結。 要用 Azure CLI 找到資源群組：
az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv在基礎設施資源群組中，找到屬於 虛擬機擴展集類型的資源。 通常每個節點集區會有一個，名稱如
aks-agentpool-12345678-vmss。 請記下您想要測試的節點集區對應的項目。要驗證節點在不同區域的分布情況，請回到你的 AKS 叢集並選擇 設定>節點池。 選擇節點池名稱並勾選 可用性區域。
可選擇性地在測試前部署一個範例應用程式到叢集，這樣你就能觀察應用程式層級的影響——例如當節點關閉時應用程式是否仍可存取。 若想從全新叢集和範例應用程式開始，請參考教學：部署範例應用程式並用 Chaos Studio 測試其區域韌性。
執行計算區關閉情境
Warning
此方法直接作用於 AKS 為你管理的基礎架構。 AKS 對帳功能和叢集自動調整器可能會在執行期間或之後重建或重新平衡實例。 這個動作會影響干擾度和你的測量結果。 先在預製叢集中執行此測試，並於了解相關限制後才選擇加入。
建立工作區，並將其範圍設為叢集的基礎結構資源群組，然後將所需角色指派給工作區的受控識別。 探索完成後，節點虛擬機器擴展集會顯示為已探索到的資源。
設定 Compute Zone Down 情境，選取您先前驗證過的可用性區域。 此情境中的操作會在已設定的持續時間內，關閉目標區域中的虛擬機器和虛擬機器擴展集執行個體。 當動作持續時間結束時，實例會重新開始。
開始跑步前，先安排好一些觀看的節目。 在 AKS 叢集的 監視>計量 頁面中，將每個節點的計量繪製成圖表，例如依節點分割的 CPU 使用率，並在執行期間讓該分頁維持開啟狀態。 或者從群組內部觀看：
# Watch nodes go down and recover kubectl get nodes -w # Check pod distribution across zones kubectl get pods -o wide --all-namespaces執行此案例並觀察結果。 運行開始後可能需要幾分鐘才會讓關機生效並出現在指標上，所以如果沒有立即改變也不必擔心。 當目標區域中的節點下線時，預期節點數量會減少，Pod 會重新排程到其餘區域（如果你測試的是線上應用程式，期間可能會有短暫的服務中斷），而其餘節點上的負載則會穩定在較高水準。 當執行個體在執行結束時重新啟動，節點會重新加入叢集，Pod 在接下來的幾分鐘內重新平衡。
解譯結果
在情境報告中，關機操作顯示「已成功」狀態，表示執行已在目標區域找到節點執行個體並中斷它們。 如果關機行動顯示 跳過，代表該執行沒有找到匹配的目標——通常範圍不包含基礎設施資源群組，或是目標區域沒有實例。 請參閱 一次執行不會造成任何影響（所有動作皆已略過）。
這次執行本身成功，並不代表你的叢集通過了測試。 值得調查的韌性差距跡象：
- 您的應用程式在 Pod 重新排程後仍然無法恢復服務 - 檢查複本數、Pod 中斷預算，以及是否因資源限制而導致無法排程。
- 在執行期間，Pod 一直處於待處理狀態 - 其餘區域沒有足夠的容量來承接失去區域後的負載。
- 在該區域的執行個體恢復運作後，復原所花費的時間超過您的復原時間目標。
將情境報告與你自己的叢集和應用程式監控結合，以判斷復原行為的端對端——AKS 可能在執行過程中就開始重建或重新平衡實例。
為什麼範圍限定於 AKS 叢集的工作區找不到計算目標
當你建立 AKS 叢集時，AKS 會建立一個管理 基礎設施 資源群組（預設名稱以 為 MC_ 開頭），其中包含叢集的節點虛擬機擴展集、負載平衡器及相關基礎設施資源。 叢集資源本身存在於你選擇的資源群組中;節點則沒有。
由於工作區探索的範圍受 scope 限制，因此，若工作區的範圍限定為包含 AKS 叢集資源 的資源群組，便無法探索到節點集區。 節點池存在於基礎設施資源群組中。 結果是工作區似乎包含了您的叢集，但沒有顯示任何可操作的計算目標，並且區域關閉執行的所有操作都顯示為已跳過狀態。
Alternatives
對於叢集內的故障注入，例如 Pod 故障、網路故障或叢集內的壓力測試，請使用 AKS Chaos Mesh faults with Experiments (classic)。