Samouczek: testuj odporność AKS na awarie stref za pomocą scenariusza

W tym samouczku scenariusza usługi Azure Chaos Studio użyj obszarów roboczych usługi Chaos Studio, aby przetestować odporność przykładowej aplikacji usługi Azure Kubernetes Service (AKS) na awarię strefy. Wdróż aplikację do testowego klastra nadmiarowego między strefami i uruchom Compute Zone Down na infrastrukturze jego węzłów. Pierwsze uruchomienie udostępnia interfejs użytkownika przypisany do jednej strefy. Popraw rozmieszczenie zasobników, ponownie uruchom Scenariusz i porównaj dostępność aplikacji oraz raporty Scenariusza.

Ten samouczek stanowi dobry pierwszy pokaz i używa przykładowej aplikacji przykładowej magazynu AKS z przewodników Szybki start usługi AKS, więc nie ma rejestru kontenerów ani kroku kompilacji. Przeznacz na to około godziny: utworzenie klastra oraz dwukrotne uruchomienie scenariusza, po około 5 minut każde.

W tym poradniku nauczysz się, jak:

Ten samouczek jest ukierunkowany na działające demo. W przypadku pojęć związanych z każdym krokiem zastrzeżenia dotyczące zakłócania infrastruktury zarządzanej przez usługę AKS oraz interpretowania wyników rzeczywistego obciążenia można znaleźć w temacie Testowanie odporności obciążeń w usłudze AKS przy użyciu Chaos Studio.

Wymagania wstępne

• Subskrypcja platformy Azure. Jeśli nie masz jeszcze konta platformy Azure, przed rozpoczęciem utwórz bezpłatne konto.
• Azure CLI, kubectl, kubelogini Python 3 (tylko standardowa biblioteka — brak pakietów do zainstalowania). Azure Cloud Shell ma wszystkie cztery wstępnie zainstalowane. Jeśli pracujesz lokalnie, zainstaluj kubectl, az aks install-cli i kubelogin oddzielnie.
• Microsoft.Chaos Dostawca zasobów zarejestrowany w ramach subskrypcji. Instrukcje dotyczące rejestrowania można znaleźć w sekcji Wymagania wstępne przewodnika Szybki start: Obszary robocze.

Tworzenie strefowo nadmiarowego klastra usługi AKS

Test awarii strefy dostępności ma sens tylko w przypadku klastra utworzonego tak, aby przetrwać taką awarię, więc utwórz klaster z trzema węzłami rozmieszczonymi w trzech strefach dostępności. W tym przykładzie użyto regionu East US 2; sprawdzi się dowolny region z strefami dostępności.

1. Utwórz grupę zasobów i klaster:

   az group create --name chaos-demo-rg --location eastus2
   
   az aks create \
     --resource-group chaos-demo-rg \
     --name chaos-demo-aks \
     --node-count 3 \
     --zones 1 2 3 \
     --generate-ssh-keys
   

   Tworzenie klastra trwa kilka minut.

2. W nowej sesji Cloud Shell kubectl nie jest jeszcze połączony z żadnym klastrem. Ustaw subskrypcję, pobierz poświadczenia i przekonwertuj narzędzie kubeconfig na potrzeby uwierzytelniania Microsoft Entra przed uruchomieniem dowolnego kubectl polecenia:

   az account set --subscription <SUBSCRIPTION_ID>
   az aks get-credentials --resource-group chaos-demo-rg --name chaos-demo-aks
   kubelogin convert-kubeconfig -l azurecli
   

   Podstaw identyfikator subskrypcji w miejsce <SUBSCRIPTION_ID>. Pomiń az account set, jeśli subskrypcja jest już Twoją aktywną subskrypcją. Krok kubelogin jest wymagany nawet w nowej sesji Cloud Shell — bez niego pierwsze kubectl polecenie względem klastra uwierzytelnionego w usłudze Entra kończy się niepowodzeniem z powodu błędu uwierzytelniania.

3. Sprawdź, czy węzły obejmują trzy strefy:

   kubectl get nodes -L topology.kubernetes.io/zone
   

   Kolumna ZONE zawiera jeden węzeł w każdej strefie, na przykład eastus2-1, eastus2-2i eastus2-3. Numer strefy występujący po nazwie regionu to ten, do którego odwołujesz się później w konfiguracji scenariusza.

Wdrażanie przykładowej aplikacji

Demo sklepu AKS to niewielki sklep detaliczny z internetowym interfejsem użytkownika, usługą produktów, usługą zamówień i kolejką RabbitMQ. Jego obrazy kontenerów są publiczne, więc można je wdrożyć za pomocą jednego polecenia.

1. Wdróż aplikację:

   kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/2.2.0/aks-store-quickstart.yaml
   

   Manifest wdraża każdy komponent jako pojedynczą replikę. Klaster jest strefowo nadmiarowy, ale aplikacja nie jest. Ten samouczek pokazuje tę lukę w odporności, a następnie ją eliminuje.

2. Poczekaj, aż front-end otrzyma publiczny adres IP:

   kubectl get service store-front --watch
   

   EXTERNAL-IP Gdy wartość zmieni się z <pending> na publiczny adres IP, naciśnij klawisz Ctrl+C , aby zatrzymać zegarek.

3. Otwórz http://<EXTERNAL-IP> w przeglądarce i potwierdź załadowanie sklepu. Pozostaw tę kartę otwartą. Jest to pomocniczy widok kondycji aplikacji podczas testu — monitor uruchamiany później jest podstawowym.

Aby dowiedzieć się, jak sama aplikacja jest kompilowana i wdrażana, zobacz serię samouczków usługi AKS.

Przypnij frontend do jednej strefy, aby uzyskać powtarzalne demo

Bez jawnego przypięcia harmonogramista może umieścić pojedynczą replikę frontonu w dowolnej strefie, a zwykłe ponowne zaplanowanie może nastąpić na tyle szybko, że łatwo przeoczyć jego skutki. Przypięcie repliki do znanej strefy sprawia, że cel jest przewidywalny, a awaria widoczna za każdym razem, gdy uruchamiasz demonstrację.

1. Znajdź węzeł, na którym jest obecnie uruchomiony pod store-front, i odczytaj etykietę strefy tego węzła:

   STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
   PIN_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
   echo "$PIN_ZONE"
   

   PIN_ZONE to etykieta pełnej strefy, taka jak eastus2-1. Zachowaj tę sesję powłoki otwartą — ponownie użyjesz tej wartości w monitorze, a później w konfiguracji scenariusza (gdzie wymagany jest tylko numer, czyli część po ostatnim myślniku — na przykład 1 w ciągu eastus2-1).

2. Popraw wdrożenie store-front, aby wymagało planowania w tej strefie, i dodaj adnotację, która oznacza tę poprawkę jako wzorzec wyłącznie demonstracyjny:

   kubectl patch deployment store-front --patch "$(cat <<EOF
   {
     "metadata": {
       "annotations": {
         "chaos-demo.aks-zone-down-demo/deliberate-anti-pattern": "Pins the single front-end replica to zone ${PIN_ZONE} so run 1 is deterministic. Removed as part of the fix later in this tutorial - do not carry this pin into a real deployment."
       }
     },
     "spec": {
       "template": {
         "spec": {
           "affinity": {
             "nodeAffinity": {
               "requiredDuringSchedulingIgnoredDuringExecution": {
                 "nodeSelectorTerms": [
                   {
                     "matchExpressions": [
                       {"key": "topology.kubernetes.io/zone", "operator": "In", "values": ["${PIN_ZONE}"]}
                     ]
                   }
                 ]
               }
             }
           }
         }
       }
     }
   }
   EOF
   )"
   
   kubectl rollout restart deployment/store-front
   kubectl rollout status deployment/store-front --timeout=300s
   

3. Potwierdź, że przypięcie jest utrzymywane — replika powinna z powrotem znajdować się na węźle w $PIN_ZONE:

   STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
   STORE_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
   echo "Pod is in zone: $STORE_ZONE (expected $PIN_ZONE)"
   

   Jeśli te dwie wartości nie są zgodne, powtórz poprzedni krok — uruchomienie 1 nie będzie deterministyczne, dopóki nie będą zgodne.

Pobieranie i uruchamianie monitora pokazowego

Monitorowanie kubectl wyłącznie w terminalu jest zbyt wolne i łatwo je przeoczyć podczas demo na żywo. Własny sygnał witryny nie zmienia się synchronicznie z sygnałem klastra. W tym samouczku jako główny sposób śledzenia przebiegu użyto małego skryptu monitorującego w Pythonie z repozytorium przykładów Chaos Studio.

1. Pobierz monitor i skrypt weryfikacji poprawek:

   curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/monitor.py
   curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/verify-fix.sh
   chmod +x verify-fix.sh
   

   Te linki są przypięte do konkretnego komitu, dzięki czemu działają niezależnie od późniejszych zmian w przykładzie. Po scaleniu tego pull requestu kolejne wersje tego samouczka mogą zamiast tego odwoływać się do wydania oznaczonego tagiem.

2. Uruchom monitor, wskazując go na zewnętrzny adres IP witryny sklepu i strefę przypiętą w poprzedniej sekcji:

   python3 monitor.py --storefront-url http://<EXTERNAL-IP> --target-zone "$PIN_ZONE"
   

   Monitor używa tylko biblioteki standardowej Python, więc nie ma nic innego do zainstalowania. Domyślnie sprawdza co 5 sekund — można to skonfigurować za pomocą --interval lub zmiennej środowiskowej MONITOR_INTERVAL_SECONDS. To ustawienie domyślne występuje na tyle często, aby umożliwić ustalenie kolejności sygnałów bez zbyt agresywnego odpytywania interfejsu API Kubernetes ani witryny sklepu.

3. W Cloud Shell wybierz pozycję Podgląd sieci Web i ustaw port na 8787, aby otworzyć monitor na karcie przeglądarki. Jeśli korzystasz lokalnie, otwórz http://localhost:8787 zamiast tego.

   Strona monitora jest teraz podstawowym widokiem dla obu przebiegów. Pokazuje cztery sygnały:

   • Stan HTTP witryny sklepu — buforowane żądanie względem witryny sklepu, dzięki czemu zobaczysz stan dostępny na żywo/nieosiągalny zamiast buforowanego powodzenia.
   • Stan węzła strefy docelowej — czy węzeł w strefie docelowej to Ready , czy NotReady.
   • Rozmieszczenie zasobników frontendu — które store-front zasobniki są uruchomione i w której strefie znajduje się każdy z nich.
   • Historia zmian stanów — bieżąca oś czasu wszystkich powyższych zmian stanu ze znacznikami czasu, dzięki czemu można przejrzeć ich sekwencję po zakończeniu działania, zamiast polegać na obserwacjach na żywo.

   Jeśli sprawdzenie dla kubectl lub wywołanie interfejsu API Kubernetes zakończy się niepowodzeniem — na przykład gdy serwer API jest chwilowo niedostępny albo plik kubeconfig stanie się nieaktualny — monitor wyświetli widoczny czerwony baner z nazwą błędu, zamiast pozostawiać sygnał, którego dotyczy problem, zablokowany na placeholderze „sprawdzanie”. Pozostała część panelu nadal wyświetla ostatni znany prawidłowy stan i historię, gdy baner jest widoczny. Traktuj ten baner jako samodzielny sygnał: oznacza on, że mechanizm monitorowania utracił widoczność, a nie że monitorowany obiekt działa prawidłowo.

Utwórz obszar roboczy w zakresie grupy zasobów infrastruktury

Usługa AKS umieszcza zestawy skalowania maszyn wirtualnych węzłów klastra w oddzielnej grupie zasobów infrastruktury (której nazwa domyślnie zaczyna się od MC_), a nie w grupie zasobów zawierającej zasób klastra. Ogranicz obszar roboczy do grupy zasobów infrastrukturalnych, aby wykrywał węzły. Informacje ogólne zawiera temat Dlaczego obszar roboczy ograniczony do klastra AKS nie znajduje żadnych celów obliczeniowych.

1. Znajdź nazwę grupy zasobów infrastruktury:

   az aks show --resource-group chaos-demo-rg --name chaos-demo-aks --query nodeResourceGroup -o tsv
   

2. W portalu Azure wyszukaj Chaos Studio, wybierz pozycję Obszary robocze, a następnie wybierz pozycję Utwórz.

3. Na karcie Podstawy wybierz grupę zasobów, nazwij chaos-demo-rg obszar roboczy chaos-demo-workspacei wybierz obsługiwany region. Region obszaru roboczego nie musi być zgodny z regionem klastra.

4. Na karcie Zakres wybierz pozycję Grupa zasobów jako typ zakresu, a następnie wybierz grupę zasobów infrastruktury z kroku 1.

5. Na karcie Tożsamość wybierz pozycję Przypisane przez system.

6. Wybierz pozycję Przejrzyj i utwórz>Utwórz, a następnie Przejdź do zasobu.

   Po zakończeniu odnajdywania zestaw skalowania maszyn wirtualnych węzła klastra (nazwany jak aks-nodepool1-12345678-vmss) jest wyświetlany jako odnaleziony zasób.

7. Jeśli w portalu wyświetla się baner z komunikatem, że tożsamość nie ma uprawnień do odczytu w zakresie obszaru roboczego, wybierz opcję Przypisz rolę Czytelnik w zakresie obszaru roboczego. Aby utworzyć przypisania ról, musisz mieć uprawnienia właściciela lub administratora dostępu użytkowników w grupie zasobów infrastruktury.

W następnej sekcji przypiszesz tej tożsamości role, których wymaga sam scenariusz, a walidacja dokładnie wskaże, czego brakuje. Aby zapoznać się ze szczegółowym omówieniem każdego etapu tworzenia obszaru roboczego, zobacz przewodnik Szybki start dla obszarów roboczych.

Uruchamianie scenariusza i obserwowanie niepowodzenia aplikacji

Scenariusz Compute Zone Down symuluje awarię strefy dostępności przez wyłączanie wystąpień zestawu skalowania maszyn wirtualnych w strefie docelowej na skonfigurowany czas. Instancje uruchamiają się ponownie, gdy kończy się czas trwania akcji.

1. W obszarze roboczym wybierz pozycję Scenariusze, a następnie wybierz pozycję Strefa obliczeniowa w dół z biblioteki scenariuszy.

2. Skonfiguruj scenariusz. Dla strefy dostępności wprowadź liczbę z $PIN_ZONE (część po ostatnim myślniku, na przykład 1 w eastus2-1). Ustaw czas na 5 minut — wystarczająco długo, aby sygnały witryny, węzła i poda się ustabilizowały, ale nie na tyle długo, by trzeba było zbyt długo czekać. Ta wartość 5 minut jest przewidziana dla tej konkretnej demonstracji; inne typy scenariuszy mają własne zalecenia dotyczące czasu trwania w zależności od tego, co jest w nich testowane. Na przykład scenariusz oparty na mechanizmie buforowania DNS musi trwać wystarczająco długo, aby przekroczyć wartość TTL rekordu, która może być znacznie dłuższa niż 5 minut. Wybierz pozycję Zapisz konfigurację.

3. Walidacja sprawdza, czy tożsamość zarządzana obszaru roboczego może wykonywać wszystkie działania wymagane przez scenariusz na zasobach docelowych. Jeśli walidacja zgłasza brakujące uprawnienia, wybierz Napraw uprawnienia na stronie konfiguracji scenariusza, aby przypisać tożsamości zalecane role wbudowane. W tym scenariuszu jest to rola Virtual Machine Contributor dla zestawu skalowania maszyn wirtualnych węzła. Aby przypisać role samodzielnie lub użyć ról niestandardowych z najmniejszymi uprawnieniami zamiast ról wbudowanych, zobacz Uprawnienia i tożsamość w obszarach roboczych Chaos Studio i Używanie ról niestandardowych z najniższymi uprawnieniami w obszarach roboczych Chaos Studio.

   Jeśli w czasie działania nadal brakuje wymaganej roli, uruchomienie i tak się rozpoczyna, ale działania zamykania kończą się błędem uprawnień w raporcie scenariusza.

4. Wybierz pozycję Uruchom i potwierdź.

Po rozpoczęciu uruchomienia może minąć kilka minut, zanim zamknięcie zacznie działać, więc nie należy się niepokoić, jeśli na ekranie od razu nic się nie zmieni. Następnie przejdź do strony monitorowania:

• Sygnał HTTP witryny sklepu i stan węzła docelowego nie zmieniają się w tym samym momencie. Sygnał na poziomie aplikacji jest tym, co użytkownicy faktycznie doświadczają, i jest to sygnał, który należy traktować jako podstawowy; sygnały węzła i zasobnika to wewnętrzne księgowanie klastra, które nadrabiają zaległości później. Należy się spodziewać, że sklep będzie wyglądał na nieosiągalny na długo przed tym, jak węzeł wyświetli NotReady — to opóźnienie jest normalnym skutkiem asynchronicznej propagacji sygnału, a nie problemem z demo.
• Stan węzła docelowego zmienia się na NotReady.
• Ponieważ warstwa front-endowa jest przypisana do tej strefy, jej jedyna replika nie ma żadnego innego miejsca, w którym mogłaby działać. Witryna sklepu pozostaje niedostępna, dopóki Kubernetes nie będzie mógł ponownie przydzielić poda — co przy aktywnym przypięciu nastąpi dopiero po powrocie węzła docelowego lub zmianie ograniczenia rozmieszczenia. Nie polegaj tutaj na stałej wartości przestoju; sprawdź historię zmian stanów monitora, aby zobaczyć, co faktycznie wydarzyło się podczas tego uruchomienia.

Ten wynik jest wynikiem wyszukiwania. Klaster był odporny na awarię strefy, ale wybrany sposób rozmieszczenia aplikacji sprawił, że awaria strefy przerodziła się w niedostępność o nieokreślonym czasie trwania, dopóki to ograniczenie obowiązywało. Historia zmian stanu monitora to zapis dokładnie tego, kiedy witryna sklepu przestała działać, a później kiedy ponownie zaczęła działać.

Rozwiązywanie problemów: wpływ nie jest widoczny

Jeśli monitor pokazuje, że sklep pozostaje dostępny podczas całego przebiegu 1, sprawdź następujące kwestie, zanim uznasz, że scenariusz nie zadziałał:

• Potwierdź, że przypięcie zostało zastosowane. Uruchom polecenie kubectl get pods -l app=store-front -o wide i sprawdź, czy węzeł poda znajduje się w $PIN_ZONE. Jeśli poprawka nie została zastosowana, harmonogram mógł umieścić replikę w innym miejscu. Zwykłe przełożenie terminu w czasie awarii może nastąpić tak szybko, że bez przypięcia możesz je przeoczyć.
• Upewnij się, że monitor obserwuje właściwą strefę i adres URL. Uruchom ponownie monitor.py, używając dokładnie tej samej wartości --target-zone i adresu URL sklepu ze swojego klastra. Nieaktualna lub błędnie wpisana wartość wyświetla mylący stan „zdrowy”.
• Sprawdź raport dotyczący scenariusza dla Skipped działań. Jeśli działania wyłączania wyświetlają Skipped zamiast Succeeded, uruchomienie nie znalazło pasujących celów w strefie docelowej. Zobacz Interpretowanie wyników.
• Daj mu jeszcze kilka sekund. Samo zamknięcie zaczyna obowiązywać po krótkiej chwili od rozpoczęcia przebiegu. Historia zmian stanu monitora pokazuje dokładne znaczniki czasu po wystąpieniu tych zmian.

Napraw wdrożenie i zweryfikuj je

Teraz zastąp celowe przypięcie do jednej strefy rzeczywistym rozwiązaniem na skalę klastra: trzema replikami, ściśle ograniczonymi do jednej na strefę.

1. Usuń dodany wcześniej numer PIN strefy:

   kubectl patch deployment store-front --type=merge --patch '{"spec":{"template":{"spec":{"affinity":null}}}}'
   

2. Przeskaluj frontend do trzech replik i dodaj ograniczenie rozłożenia topologicznego, które wymaga jednej repliki na strefę, zamiast jedynie to preferować:

   kubectl patch deployment store-front --patch '{"spec":{"replicas":3,"template":{"spec":{"topologySpreadConstraints":[{"maxSkew":1,"topologyKey":"topology.kubernetes.io/zone","whenUnsatisfiable":"DoNotSchedule","labelSelector":{"matchLabels":{"app":"store-front"}}}]}}}}'
   

   whenUnsatisfiable: DoNotSchedule sprawia, że rozmieszczenie: jedna replika na strefę staje się bezwzględnym wymogiem. Replika, która nie może spełnić tego warunku, pozostaje Pending zamiast trafić do strefy, w której już znajduje się taka replika. To celowy kompromis — gwarantuje pokrycie stref wymagane przez ten test, kosztem tego, że replika może pozostać nieprzydzielona, jeśli w danej strefie chwilowo zabraknie miejsca. ScheduleAnyway pozwoliłoby planiście pominąć to ograniczenie w sytuacji przeciążenia, czyli dokładnie w scenariuszu awarii, który ta poprawka eliminuje.

3. Przed zaufaniem sprawdź poprawkę. Uruchom skrypt weryfikacyjny. Czeka na zakończenie wdrażania, aby nie zliczać nieaktualnych podów ze starej wersji z jedną repliką, a następnie potwierdza, że każda strefa ma co najmniej jeden pod Readystore-front:

   ./verify-fix.sh
   

   Wywołanie kubectl, żądanie API lub zwracany obiekt JSON mogą tymczasowo zakończyć się niepowodzeniem — na przykład z powodu krótkotrwałego przekroczenia limitu czasu lub przerwania połączenia — co nie oznacza, że sama poprawka się nie powiodła. Skrypt ponawia próby po takich przejściowych błędach aż do upływu własnego limitu czasu, zamiast kończyć działanie po pierwszym takim błędzie. Dopiero po upływie tego limitu czasu kończy działanie z niezerowym kodem zakończenia i wyświetla komunikat diagnostyczny wskazujący, której strefie nadal brakuje gotowej repliki. Nie uruchamiaj 2, dopóki nie przejdzie. Pozytywny wynik sprawia, że „one replica per zone” jest potwierdzonym faktem, a nie założeniem wynikającym z polecenia patch.

Uruchom ponownie scenariusz i porównaj

1. W obszarze roboczym ponownie uruchom scenariusz Awaria strefy obliczeniowej z tą samą strefą docelową i tym samym czasem trwania wynoszącym 5 minut.

2. Obejrzyj monitor. Docelowy węzeł nadal ulega awarii NotReady i powoduje też awarię swojej repliki store-front, ale sklep internetowy nadal odpowiada dzięki replikom w strefach, które przetrwały. Weryfikowana teza to ciągła dostępność mimo awarii strefy, potwierdzona ciągłą historią monitora — a nie brak odrzuconych żądań ani to, że monitor przez cały czas pokazuje nieprzerwany zdrowy stan. Krótkotrwałe zakłócenie jest nadal możliwe, gdy Azure Load Balancer przełącza ruch na pozostałe zdrowe repliki; pojedyncze uruchomienie pokazuje krótki skok związany ze zbieżnością, a nie awarię trwającą przez cały czas zakłócenia. To, ile czasu zajmuje osiągnięcie tej zbieżności, zależy od środowiska, więc nie polegaj na sztywnym limicie czasowym — użyj historii zmian stanu monitora, aby odróżnić chwilowy incydent od długotrwałej awarii.

Komponenty z pojedynczą repliką nadal mogą doświadczać krótkiego zakłócenia. Jeśli węzeł kolejki RabbitMQ znajduje się w strefie docelowej, składanie zamówień spowalnia, gdy jego pod wraca do działania. Właśnie do wymuszania takiego cyklu — znajdowania kolejnego najsłabszego elementu i decydowania, czy warto go naprawić — zaprojektowano testy chaosu.

Porównaj raporty scenariuszy

1. W obszarze roboczym wybierz pozycję Historia uruchomień. Masz teraz dwa zakończone przebiegi tego samego scenariusza.

2. Wybierz każde uruchomienie, a następnie wybierz pozycję Generuj raport. Upewnij się, że akcje zamykania mają w obu przypadkach status Succeeded, co oznacza, że każde uruchomienie odnalazło i zakłóciło instancje w strefie docelowej. Jeśli akcje wyświetlają Pominięte, przebieg nie znalazł pasujących celów. Typowe przyczyny to zakres, który nie obejmuje grupy zasobów infrastruktury ani strefy docelowej bez węzłów. Aby uzyskać więcej informacji, zobacz Testowanie odporności obciążeń w usłudze AKS przy użyciu Chaos Studio.

3. Zwróć uwagę, że oba raporty wyglądają tak samo, mimo że wyniki aplikacji były odwrotne. Powodzenie oznacza, że zakłócenie zostało dostarczone — nie oznacza to, że aplikacja pozostała w dobrej kondycji. W sprawozdaniu przedstawiono, jakie zakłócenia wystąpiły i kiedy; historia przejścia monitora potwierdza zachowanie aplikacji w odpowiedzi. Połączenie obu pozwala zamienić uruchomienie w materiał dowodowy: raport wskazuje czas wystąpienia błędu, a monitor pokazuje różnicę przed i po wprowadzeniu poprawki.

Możesz pobrać oba raporty jako dokumentację stanu przed i po na potrzeby przeglądów odporności. Aby uzyskać szczegółowe informacje, zobacz Raporty scenariuszy.

Uprzątnij zasoby

Usuń grupę zasobów, aby usunąć klaster, przykładową aplikację i obszar roboczy. Usunięcie klastra powoduje również usunięcie grupy zasobów infrastruktury.

az group delete --name chaos-demo-rg --yes --no-wait

Zgłaszaj problemy i proponuj funkcje

Azure Chaos Studio jest rozwijane publicznie. Aby zgłosić usterkę, zażądać funkcji lub zadać pytanie dotyczące obszarów roboczych, scenariuszy lub rozszerzenia Azure CLI, otwórz problem w repozytorium Chaos Studio w GitHub. Zgłaszając problem, możesz śledzić jego postęp i wyświetlać żądania od innych klientów.

Następne kroki

• Testowanie odporności obciążenia w usłudze AKS za pomocą Chaos Studio omawia zastrzeżenia i wskazówki dotyczące interpretacji podczas uruchamiania tego testu na rzeczywistym obciążeniu.
• Aby obiektywnie ocenić wynik pozytywny lub negatywny w przypadku rzeczywistego obciążenia, połącz uruchomienia scenariuszy z testami dostępności usługi Application Insights i własnymi wskaźnikami poziomu usługi, zamiast polegać na karcie przeglądarki.
• Samouczek: uruchamianie scenariusza trybu failover w strefie PostgreSQL powoduje dodanie trybu failover warstwy danych do tego samego wzorca awarii.
• Scenariusze w Azure Chaos Studio opisują pełną bibliotekę scenariuszy.
• W repozytorium GitHub projektu Chaos Studio są dostępne skrypty wdrożeniowe dla tego przykładu (w tym skrypty monitorowania i weryfikacji używane w tym samouczku), niestandardowe scenariusze, które można udostępniać, oraz wtyczka Copilot CLI umożliwiająca obsługę Chaos Studio z poziomu GitHub Copilot.