Lernprogramm: Bereitstellen einer Beispielanwendung und Testen der Zonenresilienz mit Chaos Studio

In diesem Lernprogramm stellen Sie eine Beispielanwendung für den Einzelhandel in einem zonenredundanten Azure Kubernetes Service (AKS) Cluster bereit und verwenden dann einen Azure Chaos Studio Arbeitsbereich, um einen Ausfall der Verfügbarkeitszone zweimal zu simulieren. Beim ersten Durchlauf zeigt sich eine echte Lücke bei der Ausfallsicherheit: Das Frontend der Anwendung ist bewusst auf eine einzelne Zone festgelegt, sodass auch die Storefront ausfällt, wenn diese Zone ausfällt. Anschließend beheben Sie die Bereitstellung, führen dasselbe Szenario erneut aus, und beobachten Sie, wie die Anwendung den Fehler durchläuft. Dabei starten Sie eine browserbasierte Überwachungsansicht, die zeigt, wie Fehler und Behebung auftreten, und Sie erfahren, warum sich die Verfügbarkeit des Storefronts selbst und der Status der Cluster-Knoten nicht im selben Moment ändern.

Dieses Tutorial eignet sich gut als erste Demo und verwendet die AKS Store-Demo-Beispielanwendung aus den AKS-Schnellstarts, sodass weder eine Container-Registry noch ein Buildschritt erforderlich sind. Planen Sie etwa eine Stunde: Die Clustererstellung plus zwei Szenarioläufe von jeweils ca. 5 Minuten.

In diesem Tutorial erfahren Sie, wie:

Dieses Tutorial ist auf eine funktionsfähige Demo ausgerichtet. Informationen zu den Konzepten hinter jedem Schritt, zu den Vorbehalten bei Eingriffen in die von AKS für Sie verwaltete Infrastruktur und dazu, wie Ergebnisse bei einer realen Workload zu interpretieren sind, finden Sie unter Testen der Workload-Resilienz auf AKS mit Chaos Studio.

Voraussetzungen

• Ein Azure-Abonnement. Wenn Sie nicht über ein Azure-Konto verfügen, erstellen Sie ein kostenloses Konto , bevor Sie beginnen.
• Azure CLI, kubectl, und kubeloginPython 3 (nur Standardbibliothek - keine zu installierenden Pakete). Azure Cloud Shell hat alle vier vorinstalliert. Wenn Sie lokal arbeiten, installieren Sie kubectl mit az aks install-cli und kubelogin separat.
• Der in Ihrem Abonnement registrierte Ressourcenanbieter Microsoft.Chaos. Informationen zum erstmaligen Registrieren finden Sie unter Registrieren des Chaos Studio Ressourcenanbieters.

Erstellen eines zonenredundanten AKS-Clusters

Ein Zonenfehlertest ist nur für einen Cluster sinnvoll, der für das Überleben eines Clusters erstellt wurde. Erstellen Sie daher einen Cluster mit drei Knoten, die sich über drei Verfügbarkeitszonen erstrecken. In diesem Beispiel wird Ost-US 2 verwendet; jede Region mit Verfügbarkeitszonen funktioniert.

1. Erstellen Sie eine Ressourcengruppe und den Cluster:

   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
   

   Die Clustererstellung dauert einige Minuten.

2. In einer aktuellen Cloud Shell-Sitzung kubectl ist noch keine Verbindung mit einem Cluster hergestellt. Legen Sie Ihr Abonnement fest, rufen Sie Anmeldeinformationen ab, und konvertieren Sie die Kubeconfig für Microsoft Entra Authentifizierung, bevor Sie einen beliebigen kubectl Befehl ausführen:

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

   Ersetzen Sie Ihre Abonnement-ID für <SUBSCRIPTION_ID>. Überspringen Sie az account set, wenn das Abonnement bereits das aktive ist. Der Schritt kubelogin ist auch in einer frischen Cloud Shell-Sitzung erforderlich, da sonst der erste kubectl-Befehl bei einem Entra-authentifizierten Cluster mit einem Authentifizierungsfehler fehlschlägt.

3. Überprüfen Sie, ob die Knoten drei Zonen umfassen:

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

   Die Spalte ZONE zeigt in jeder Zone einen Knoten, z. B. eastus2-1, eastus2-2 und eastus2-3. Die Zonennummer nach dem Regionsnamen ist das, was Sie später in der Szenariokonfiguration als Ziel festlegen.

Bereitstellen der Beispielanwendung

Die AKS Store-Demo ist ein kleiner Einzelhandel mit einem Web-Front-End, einem Produktservice, einem Bestellservice und einer RabbitMQ-Warteschlange. Die Containerimages sind öffentlich, sodass Sie sie mit einem einzigen Befehl bereitstellen können.

1. Bereitstellen der Anwendung:

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

   Das Manifest stellt jede Komponente mit einem einzelnen Replikat bereit. Der Cluster ist zonenredundant, aber die Anwendung ist nicht. Dieses Tutorial zeigt diese Resilienzlücke auf und behebt sie.

2. Warten Sie, bis das Front-End eine öffentliche IP-Adresse erhält:

   kubectl get service store-front --watch
   

   Wenn sich der Wert EXTERNAL-IP von <pending> zu einer öffentlichen IP-Adresse ändert, drücken Sie Ctrl+C, um die Überwachung zu beenden.

3. Öffnen Sie http://<EXTERNAL-IP> in einem Browser und vergewissern Sie sich, dass der Shop geladen wird. Lassen Sie diese Registerkarte geöffnet. Dies ist eine sekundäre Ansicht der Anwendungsintegrität während des Tests – der Monitor, den Sie später starten, ist der primäre.

Informationen dazu, wie die Anwendung selbst erstellt und bereitgestellt wird, finden Sie in der AKS-Lernprogrammreihe.

Frontend auf eine einzelne Zone festlegen für eine deterministische Demo

Ohne eine gezielte Fixierung kann der Scheduler die einzige Replik des Frontends in einer beliebigen Zone platzieren, und eine bloße Neuplanung kann schnell genug erfolgen, sodass die Auswirkungen leicht übersehen werden können. Durch das Anheften des Replikats an eine bekannte Zone wird das Ziel vorhersehbar und der Fehler bei jeder Ausführung der Demo feststellbar.

1. Suchen Sie den Knoten, auf dem der store-front-Pod aktuell ausgeführt wird, und lesen Sie das Zonen-Label dieses Knotens:

   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 ist die vollständige Zonenbezeichnung, zum Beispiel eastus2-1. Lassen Sie diese Shellsitzung offen – diesen Wert werden Sie für den Monitor und später für die Szenariokonfiguration verwenden (dort wird nur die Zahl abgefragt, also der Teil nach dem letzten Bindestrich – zum Beispiel 1 in eastus2-1).

2. Patchen Sie das store-front Deployment so, dass das Scheduling in dieser Zone erforderlich ist, und fügen Sie eine Annotation hinzu, die den Patch als Muster nur für Demozwecke kennzeichnet:

   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. Vergewissern Sie sich, dass die Anheftung bestehen bleibt – das Replikat sollte wieder auf einem Knoten in $PIN_ZONE sein:

   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)"
   

   Wenn die beiden Werte nicht übereinstimmen, wiederholen Sie den vorherigen Schritt – Ausführung 1 ist erst deterministisch, wenn sie übereinstimmen.

Herunterladen und Starten des Demomonitors

Eine reine Terminal-Überwachung kubectl ist zu langsam und während einer Live-Demo leicht zu übersehen. Das Signal der Storefront selbst bewegt sich nicht im Gleichschritt mit dem des Clusters. In diesem Lernprogramm wird ein kleines Python Skript aus dem Chaos Studio Beispiel-Repository als primäre Möglichkeit zum Überwachen der Ausführung verwendet.

1. Laden Sie den Monitor und das Korrekturüberprüfungsskript herunter:

   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
   

   Diese Links werden an einen bestimmten Commit angeheftet, sodass sie unabhängig von späteren Änderungen am Beispiel weiterhin funktionieren. Sobald der zugehörige Pull Request gemergt wurde, können spätere Überarbeitungen dieses Tutorials stattdessen auf ein getaggtes Release umgestellt werden.

2. Starten Sie den Monitor und richten Sie ihn auf die externe IP-Adresse der Storefront und die Zone aus, die Sie im vorherigen Abschnitt festgelegt haben:

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

   Der Monitor verwendet nur die Python Standardbibliothek, daher gibt es nichts anderes zu installieren. Standardmäßig wird alle 5 Sekunden abgefragt – konfigurierbar mit --interval oder über die Umgebungsvariable MONITOR_INTERVAL_SECONDS. Dieser Standardwert ist häufig genug, um die Reihenfolge der Signale aufzulösen, ohne die Kubernetes-API oder die Storefront zu aggressiv abzufragen.

3. Wählen Sie in Cloud Shell Web Preview aus und legen Sie den Port auf 8787 fest, um den Monitor in einem Browser-Tab zu öffnen. Wenn Sie die Anwendung lokal ausführen, öffnen Sie stattdessen http://localhost:8787.

   Die Monitorseite ist jetzt Ihre primäre Ansicht für beide Ausführungen. Es zeigt vier Signale:

   • HTTP-Status der Storefront – eine Anfrage an die Storefront unter Umgehung des Caches, sodass der aktuelle Status „erreichbar/nicht erreichbar“ anstelle eines zwischengespeicherten Erfolgs angezeigt wird.
   • Status des Knotens in Ihrer Zielzone – ob der Knoten in Ihrer Zielzone Ready oder NotReady ist.
   • Platzierung von Frontend-Pods – welche store-front Pods laufen und in welcher Zone sich jeder befindet.
   • Übergangsverlauf – eine laufende Zeitachse aller oben angezeigten Zustandsänderungen mit Zeitstempeln, sodass Sie die Sequenz überprüfen können, nachdem die Ausführung beendet wurde, anstatt sich darauf zu verlassen, was Sie live bemerkt haben.

   Wenn eine Abfrage gegen kubectl oder die Kubernetes-API fehlschlägt – z. B. ist der API-Server kurz nicht erreichbar, oder die Kubeconfig wird veraltet – der Monitor zeigt ein sichtbares rotes Banner an, das den Fehler benennt, anstatt das betroffene Signal auf einem Platzhalter "Überprüfen" hängen zu lassen. Der Rest des Dashboards zeigt weiterhin den letzten bekannten fehlerfreien Zustand und den Verlauf an, solange das Banner angezeigt wird. Behandeln Sie das Banner selbst als Signal: Es bedeutet, dass der Monitor die Sichtbarkeit verloren hat, und nicht, dass das, was es beobachtet, gesund ist.

Einen Arbeitsbereich für die Infrastrukturressourcengruppe erstellen

AKS platziert die Skalierungssätze des Knotencomputers des Clusters in einer separaten Infrastrukturressourcengruppe (die standardmäßig mit dem Namen beginnt MC_ ), nicht in der Ressourcengruppe, die die Clusterressource enthält. Legen Sie den Umfang des Arbeitsbereichs auf die Infrastrukturressourcengruppe fest, damit die Knoten erkannt werden. Informationen zum Hintergrund finden Sie unter Warum ein auf Ihren AKS-Cluster ausgerichteter Arbeitsbereich keine Computeziele findet.

1. Suchen Sie den Namen der Infrastrukturressourcengruppe:

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

2. Suchen Sie im Azure-Portal nach Chaos Studio, wählen Sie "Arbeitsbereiche" und dann "Erstellen" aus.

3. Wählen Sie auf der Registerkarte " Grundlagen " die chaos-demo-rg Ressourcengruppe aus, nennen Sie den Arbeitsbereich chaos-demo-workspace, und wählen Sie einen unterstützten Bereich aus. Der Arbeitsbereichsbereich muss nicht mit dem Clusterbereich übereinstimmen.

4. Wählen Sie auf der Registerkarte " Bereich " die Option "Ressource" als Bereichstyp aus, und wählen Sie dann die Infrastrukturressourcengruppe aus Schritt 1 aus.

5. Wählen Sie auf der Registerkarte " Identität " die Option "System zugewiesen" aus.

6. Wählen Sie "Überprüfen" und "Erstellen>" aus, und wechseln Sie dann zur Ressource.

   Nach Abschluss der Ermittlung wird die VM-Knotenskalierungsgruppe des Clusters (mit einem Namen im folgenden Format: aks-nodepool1-12345678-vmss) als ermittelte Ressource angezeigt.

7. Wenn im Portal ein Banner angezeigt wird, das besagt, dass der Identität Leseberechtigungen für den Bereich des Arbeitsbereichs fehlen, wählen Sie Weisen Sie die Rolle „Leser“ für den Bereich des Arbeitsbereichs zu aus. Zum Erstellen von Rollenzuweisungen benötigen Sie Die Rechte "Besitzer" oder "Benutzerzugriffsadministrator" in der Ressourcengruppe der Infrastruktur.

Im nächsten Abschnitt weisen Sie der Identität die Rollen zu, die das Szenario selbst benötigt; dort zeigt Ihnen die Validierung genau, was fehlt. Eine vollständige exemplarische Vorgehensweise für jeden Arbeitsbereichserstellungsschritt finden Sie in der Arbeitsbereichsschnellstartanleitung.

Führen Sie das Szenario aus, und beobachten Sie, dass die App fehlschlägt.

In dem Szenario Ausfall der Compute-Zone wird der Ausfall einer Verfügbarkeitszone simuliert. Dabei werden die VM-Skalierungsgruppeninstanzen in einer Zielzone für die konfigurierte Dauer heruntergefahren. Die Instanzen werden neu gestartet, wenn die Dauer der Aktion endet.

1. Wählen Sie im Arbeitsbereich "Szenarien" und dann " Compute Zone Down " aus der Szenariobibliothek aus.

2. Konfigurieren Sie das Szenario. Geben Sie für die Verfügbarkeitszone die Nummer aus $PIN_ZONE ein (den Teil nach dem letzten Bindestrich, z. B. 1 in eastus2-1). Legen Sie die Dauer auf 5 Minuten fest – lang genug, damit sich die Signale von Storefront, Knoten und Pod stabilisieren können, ohne unnötig lange warten zu müssen. Der Wert von 5 Minuten ist für diese spezielle Demo bemessen; andere Szenariotypen haben je nach dem, was sie testen, eigene Empfehlungen zur Dauer. Beispielsweise erfordert ein Szenario, das auf dem DNS-Caching-Verhalten basiert, eine ausreichend lange Dauer, um die Cache-TTL des Eintrags zu überschreiten, die viel länger als 5 Minuten sein kann. Wählen Sie Konfiguration speichern aus.

3. Bei der Überprüfung wird überprüft, ob die verwaltete Identität des Arbeitsbereichs jede Aktion ausführen kann, die das Szenario für die Zielressourcen benötigt. Wenn bei der Validierung fehlende Berechtigungen gemeldet werden, wählen Sie auf der Seite für die Szenariokonfiguration Berechtigungen korrigieren aus, um der Identität die empfohlenen integrierten Rollen zuzuweisen. Für dieses Szenario ist das die Rolle „Mitwirkender für virtuelle Computer“ für die VM-Skalierungsgruppe des Knotens. Informationen zum Zuweisen der Rollen selbst oder zum Verwenden von benutzerdefinierten Rollen mit geringsten Rechten anstelle integrierter Rollen finden Sie unter "Berechtigungen und Identität" in Chaos Studio Arbeitsbereichen und verwenden benutzerdefinierte Rollen mit den geringsten Berechtigungen mit Chaos Studio Arbeitsbereichen.

   Wenn zur Laufzeit noch eine erforderliche Rolle fehlt, wird die Ausführung trotzdem gestartet, aber die Herunterfahren-Aktionen schlagen mit einem Berechtigungsfehler im Szenariobericht fehl.

4. Wählen Sie "Ausführen" und "Bestätigen" aus.

Nach dem Start des Durchlaufs kann es einige Minuten dauern, bis das Herunterfahren wirksam wird. Seien Sie also nicht beunruhigt, wenn sich auf dem Monitor nicht sofort etwas ändert. Sehen Sie sich dann die Monitorseite an:

• Das Storefront-HTTP-Signal und der Status des Zielknotens ändern sich derzeit nicht. Das Signal auf Anwendungsebene ist das, was Ihre Nutzer tatsächlich erleben, und es ist das Signal, das vorrangig behandelt werden sollte; die Knoten- und Pod-Signale sind clusterinterne Verrechnungsgrößen, die erst nachträglich nachziehen. Rechnen Sie damit, dass die Storefront deutlich früher als nicht erreichbar angezeigt wird, bevor der Knoten NotReady anzeigt – diese Verzögerung ist normal, sie ist auf die asynchrone Signalweitergabe zurückzuführen und kein Problem mit der Demo.
• Der Status des Zielknotens ändert sich zu NotReady.
• Da das Front-End an diese Zone gebunden ist, kann seine einzige Replik nirgendwo anders ausgeführt werden. Die Storefront bleibt unerreichbar, bis Kubernetes den Pod neu einplanen kann – was, solange die Anheftung besteht, nur dann geschieht, wenn der Zielknoten wieder verfügbar ist oder Sie die Platzierungsbeschränkung ändern. Verlassen Sie sich hier nicht auf einen festen Ausfallzeitwert; prüfen Sie stattdessen den Übergangsverlauf des Monitors, um festzustellen, was bei Ihrem Durchlauf tatsächlich passiert ist.

Dieses Ergebnis ist der Befund. Der Cluster war zonenredundant, aber die Platzierungsauswahl der Anwendung verwandelte einen Zonenfehler in einen Ausfall ohne definiertes Ende, während die Einschränkung beibehalten wurde. Der Verlauf der Statusänderungen des Monitors ist die Aufzeichnung darüber, wann genau die Storefront ausfiel und wann sie später wieder verfügbar war.

Problembehandlung: Die Auswirkungen sind nicht sichtbar.

Wenn der Monitor anzeigt, dass die Storefront während der gesamten Ausführung 1 erreichbar bleibt, überprüfen Sie diese Elemente, bevor Sie davon ausgehen, dass das Szenario nicht funktioniert hat:

• Bestätigen Sie, dass der Pin wirksam wurde. Führen Sie kubectl get pods -l app=store-front -o wide aus und überprüfen Sie, dass sich der Knoten des Pods in $PIN_ZONE befindet. Wenn der Patch nicht angewendet wurde, hat der Scheduler das Replikat möglicherweise an anderer Stelle platziert. Eine einfache Neuterminierung während der Störung kann so schnell erfolgen, dass sie Ihnen ohne Anheften entgeht.
• Vergewissern Sie sich, dass der Monitor die richtige Zone und URL überwacht. Starten Sie --target-zone mit dem genauen monitor.py Wert und der Storefront-URL aus Ihrem Cluster neu. Ein veralteter oder falsch eingegebener Wert zeigt den irreführenden Status „Fehlerfrei“ an.
• Überprüfen Sie den Szenariobericht auf Skipped Aktionen. Wenn die Herunterfahraktionen Succeeded statt Skipped anzeigen, hat der Lauf keine übereinstimmenden Ziele in der Zielzone gefunden. Siehe "Interpretieren der Ergebnisse".
• Geben Sie es ein paar Sekunden mehr. Die Aktion zum Herunterfahren selbst dauert kurze Zeit, um nach dem Start der Ausführung wirksam zu werden. Der Übergangsverlauf des Monitors zeigt die genauen Zeitstempel an, sobald diese eintreten.

Beheben Sie das Bereitstellungsproblem, und überprüfen Sie es.

Ersetzen Sie nun den absichtlichen Einzelzonen-Pin durch eine echte, clusterweite Lösung: drei Replikas, streng auf jeweils eine pro Zone festgelegt.

1. Entfernen Sie den Zonennadel, den Sie zuvor hinzugefügt haben:

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

2. Skalieren Sie das Front-End auf drei Replikate, und fügen Sie eine Topologie-Spreadeinschränkung hinzu, die ein Replikat pro Zone erfordert , anstatt es einfach zu bevorzugen:

   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 macht die Verteilung mit einer Replik pro Zone zur zwingenden Anforderung. Ein Replikat, das diese Anforderung nicht erfüllen kann, bleibt Pending, anstatt in einer Zone zu landen, die bereits eines hat. Das ist eine bewusste Abwägung – sie garantiert die Zonenabdeckung, von der dieser Test abhängt, hat jedoch den Nachteil, dass ein Replikat möglicherweise nicht eingeplant bleibt, wenn eine Zone vorübergehend keine Kapazität hat. ScheduleAnyway würde den Scheduler die Einschränkung unter Druck überspringen lassen, was genau der Fehlermodus ist, den dieser Fix schließt.

3. Überprüfen Sie die Korrektur, bevor Sie sich darauf verlassen. Führen Sie das Überprüfungsskript aus. Es wartet den Rollout ab, sodass veraltete Pods aus der alten Revision mit nur einem Replikat nicht gezählt werden, und prüft dann, dass jede Zone mindestens einen Readystore-front Pod hat:

   ./verify-fix.sh
   

   Ein kubectl Aufruf, eine API-Anforderung oder der zurückgegebene JSON-Code können vorübergehend fehlschlagen – ein kurzes Timeout, eine verworfene Verbindung – ohne dass der Fix selbst fehlgeschlagen ist. Das Skript versucht es bei diesen vorübergehenden Fehlern erneut, bis sein eigenes Timeout erreicht ist, anstatt beim ersten solchen Fehler abzubrechen. Erst nach Ablauf dieses Timeouts beendet es sich mit einem Status ungleich null und einer diagnostischen Meldung, die angibt, in welcher Zone noch ein bereites Replikat fehlt. Fahren Sie mit Durchlauf 2 erst fort, wenn dieser erfolgreich ist. Ein positives Ergebnis bestätigt, dass „ein Replikat pro Zone“ eine verifizierte Tatsache ist und nicht nur eine Annahme, die aus dem Patch-Befehl übernommen wurde.

Führen Sie das Szenario erneut aus, und vergleichen Sie es.

1. Führen Sie im Arbeitsbereich das Szenario "Compute Zone Down " erneut mit derselben Zielzone und der gleichen 5-Minuten-Dauer aus.

2. Überwachen Sie den Monitor. Der Zielknoten fällt weiterhin NotReady aus und reißt sein store-front Replikat mit sich, aber die Storefront bleibt weiterhin erreichbar, da sie von den Replikaten in den verbleibenden Zonen bedient wird. Die geprüfte Aussage ist anhaltende Verfügbarkeit trotz des Zonenausfalls, belegt durch die lückenlose Historie des Monitors – nicht, dass keine Anfragen verworfen wurden, und auch nicht, dass der Monitor durchgehend einen fehlerfreien Zustand anzeigt. Eine kurze Unterbrechung ist weiterhin möglich, während die Azure Load Balancer auf die verbleibenden fehlerfreien Replikate konvergiert. Bei einem Übergabelauf wird ein kurzer Konvergenz-Blip angezeigt, kein Ausfall, der die Länge der Unterbrechung dauert. Wie lange die Konvergenz dauert, variiert je nach Umgebung. Verlassen Sie sich also nicht auf eine feste Zeit, und verwenden Sie den Übergangsverlauf des Monitors, um einen vorübergehenden Ausbruch von einem anhaltenden Ausfall zu unterscheiden.

Bei Komponenten mit nur einer Replik kann es weiterhin zu einer kurzen Unterbrechung kommen. Befindet sich der Knoten der RabbitMQ-Warteschlange in der Zielzone, ist die Auftragsübermittlung beeinträchtigt, während der zugehörige Pod wiederhergestellt wird. Die nächstschwächere Komponente zu finden und zu entscheiden, ob ihre Behebung den Aufwand lohnt, ist genau der iterative Prozess, den Chaos-Testing vorantreiben soll.

Vergleichen der Szenarioberichte

1. Wählen Sie im Arbeitsbereich Ausführungsverlauf aus. Sie haben jetzt zwei abgeschlossene Ausführungen desselben Szenarios.

2. Wählen Sie jede Ausführung aus, und wählen Sie dann " Bericht generieren" aus. Vergewissern Sie sich, dass bei beiden AKtionen zum Herunterfahren der Status Erfolgreich angezeigt wird; das bedeutet, dass jede Ausführung Instanzen in der Zielzone gefunden und unterbrochen hat. Wenn Aktionen als Skipped angezeigt werden, hat die Ausführung keine übereinstimmenden Ziele gefunden. Die üblichen Ursachen sind ein Bereich, der nicht die Infrastrukturressourcengruppe oder eine Zielzone ohne Knoten enthält. Weitere Informationen finden Sie unter Testen der Arbeitslastresilienz auf AKS mit Chaos Studio.

3. Beachten Sie, dass beide Berichte gleich aussehen, obwohl die Anwendungsergebnisse gegensätzlich waren. Erfolgreich bedeutet, dass die Unterbrechung ausgeführt wurde – es bedeutet nicht, dass die Anwendung funktionsfähig blieb. Der Bericht beweist, welche Unterbrechungen aufgetreten sind und wann; Der Übergangsverlauf des Monitors beweist das Verhalten der Anwendung als Reaktion. Durch das Zusammenspiel beider wird aus einem Durchlauf ein Nachweis: Der Bericht versieht den Fehler mit einem Zeitstempel, und die Überwachung zeigt den Unterschied vor und nach der Behebung, den die Korrektur bewirkt hat.

Sie können beide Berichte als Vor- und Nachher-Nachweise für Resilienzüberprüfungen herunterladen. Ausführliche Informationen finden Sie unter "Szenarioberichte".

Bereinigen von Ressourcen

Löschen Sie die Ressourcengruppe, um den Cluster, die Beispielanwendung und den Arbeitsbereich zu entfernen. Durch das Löschen des Clusters wird auch die Infrastrukturressourcengruppe gelöscht.

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

Melden von Problemen und Anfordern von Features

Azure Chaos Studio wird im Offenen entwickelt. Um einen Fehler zu melden, ein Feature anzufordern oder eine Frage zu Arbeitsbereichen, Szenarien oder der Azure CLI Erweiterung zu stellen, öffnen Sie ein Problem im Chaos Studio Repository auf GitHub. Durch die Einreichung eines Problems können Sie den Fortschritt nachverfolgen und Anfragen von anderen Kunden anzeigen.

Nächste Schritte

• Workloadresilienz auf AKS mit Chaos Studio testen behandelt die Einschränkungen und Auslegungshinweise für die Ausführung dieses Tests mit einer realen Workload.
• Für Ziele für das Bestehen oder Nichtbestehen bei einer realen Workload kombinieren Sie Szenarioausführungen mit Application Insights-Verfügbarkeitstests und Ihren eigenen Servicelevelindikatoren anstelle einer Browserregisterkarte.
• Im Tutorial: Failover-Szenario eines PostgreSQL-Zonenausfalls ausführen wird das Ausfallmuster durch das Failover einer Datenebene ergänzt.
• Szenarien in Azure Chaos Studio beschreibt die vollständige Szenariobibliothek.
• Das Chaos Studio GitHub Repository verfügt über Bereitstellungsskripts für dieses Beispiel (einschließlich der in diesem Lernprogramm verwendeten Überwachungs- und Überprüfungsskripts), gemeinsam nutzbaren benutzerdefinierten Szenarien und einem Copilot CLI-Plug-In zum Steuern von GitHub Copilot Chaos Studio.