Zelfstudie: Een voorbeeldtoepassing implementeren en de zonetolerantie testen met Chaos Studio

In deze zelfstudie implementeert u een voorbeeld van een retailtoepassing in een zone-redundant Azure Kubernetes Service (AKS)-cluster en gebruikt u vervolgens een Azure Chaos Studio werkruimte om een fout in de beschikbaarheidszone twee keer te simuleren. De eerste test brengt een reëel tekort in de veerkracht aan het licht: de front-end van de applicatie is bewust vastgezet op één zone, waardoor de webwinkel uitvalt als die zone uitvalt. Vervolgens lost u de implementatie op, voert u hetzelfde scenario opnieuw uit en bekijkt u hoe de toepassing door de fout loopt. Onderweg start u een browsermonitor die de fout en de oplossing laat zien terwijl deze zich voordoen, en leert u waarom de eigen beschikbaarheid van de winkel en de knooppuntstatus van het cluster op hetzelfde moment niet veranderen.

Deze zelfstudie is een goede eerste demo en hergebruikt de voorbeeldtoepassing AKS store demo uit de AKS-quickstarts, waardoor er geen containerregister of buildstap nodig is. Plan ongeveer een uur: het maken van clusters plus twee scenario's van ongeveer 5 minuten.

In deze handleiding leer je hoe je:

Deze handleiding is gericht op een werkende demo. Zie De tolerantie van workloads op AKS testen met Chaos Studio voor de concepten achter elke stap, de kanttekeningen bij het verstoren van infrastructuur die AKS voor u beheert en hoe u resultaten bij een echte workload interpreteert.

Prerequisites

• Een Azure-abonnement. Als u geen Azure-account hebt, maak dan een gratis account aan voordat u begint.
• Azure CLI, kubectl, kubeloginen Python 3 (standaardbibliotheek alleen - geen pakketten te installeren). Azure Cloud Shell is alle vier vooraf geïnstalleerd. Als u lokaal werkt, installeer kubectl dan afzonderlijk met az aks install-cli en kubelogin.
• De resourceprovider Microsoft.Chaos die in uw abonnement is geregistreerd. Als u de resourceprovider van Chaos Studio voor de eerste keer wilt registreren, raadpleegt u De resourceprovider van Chaos Studio registreren.

Een zone-redundant AKS-cluster maken

Een zonefouttest is alleen zinvol voor een cluster dat is gebouwd om er een te overleven, dus maak een cluster met drie knooppunten verspreid over drie beschikbaarheidszones. In dit voorbeeld wordt VS - oost 2 gebruikt; elke regio met beschikbaarheidszones werkt.

1. Maak een resourcegroep en het 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
   

   Het maken van een cluster duurt enkele minuten.

2. In een nieuwe Cloud Shell-sessie is kubectl nog niet verbonden met een cluster. Stel uw abonnement in, haal referenties op en converteer de kubeconfig voor Microsoft Entra verificatie voordat u een kubectl opdracht uitvoert:

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

   Vervang uw abonnements-id door <SUBSCRIPTION_ID>. Sla az account set over als dit abonnement al uw actieve abonnement is. De stap kubelogin is zelfs in een nieuwe Cloud Shell-sessie vereist; zonder die stap mislukt de eerste opdracht kubectl bij een met Entra geverifieerd cluster met een authenticatiefout.

3. Controleer of de knooppunten drie zones omvatten:

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

   De ZONE kolom toont één knooppunt in elke zone, zoals eastus2-1, eastus2-2en eastus2-3. Het zonenummer na de naam van de regio is het nummer waarop u zich later in de configuratie van het scenario richt.

De voorbeeldtoepassing implementeren

De demo van de AKS-winkel is een kleine winkel met een webfront-end, een productservice, een orderservice en een RabbitMQ-wachtrij. De containerinstallatiekopieën zijn openbaar, zodat u deze met één opdracht kunt implementeren.

1. De toepassing implementeren:

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

   Het manifest implementeert elk onderdeel met één replica. Het cluster is zone-redundant, maar de toepassing is dat niet. Deze tutorial brengt deze kloof in de veerkracht aan het licht en verhelpt die vervolgens.

2. Wacht tot de front-end een openbaar IP-adres heeft:

   kubectl get service store-front --watch
   

   Wanneer de waarde van EXTERNAL-IP verandert van <pending> naar een openbaar IP-adres, druk op Ctrl+C om het watchproces te stoppen.

3. Open http://<EXTERNAL-IP> in een browser en bevestig dat de store wordt geladen. Houd dit tabblad geopend. Het is een secundaire weergave van de toepassingsstatus tijdens de test. De monitor die u later start, is de primaire.

Zie de reeks AKS-zelfstudies voor meer informatie over hoe de toepassing zelf is gebouwd en geïmplementeerd.

De front-end vastmaken aan één zone voor een deterministische demo

Zonder een opzettelijke pin kan de scheduler de enkele replica van de front-end in een zone plaatsen en kan een eenvoudige herplanning snel genoeg gebeuren dat de impact gemakkelijk te missen is. Als u de replica vastmaakt aan een bekende zone, is het doel voorspelbaar en kan de fout worden waargenomen telkens wanneer u de demo uitvoert.

1. Zoek het knooppunt waarop de store-front pod momenteel wordt uitgevoerd en lees het zonelabel van dat knooppunt:

   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 is het volledige zonelabel, zoals eastus2-1. Houd deze shellsessie open. U gebruikt deze waarde opnieuw voor de monitor en later voor de scenarioconfiguratie (waarin alleen het getal wordt gevraagd, het deel na het laatste afbreekstreepje, bijvoorbeeld 1 in eastus2-1).

2. Pas de store-front-deployment aan om inplanning in die zone te vereisen en voeg een annotatie toe die de patch markeert als een patroon dat alleen voor demo's is bedoeld:

   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. Bevestig dat de pin is behouden - de replica moet weer op een knooppunt in $PIN_ZONE staan:

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

   Als de twee waarden niet overeenkomen, herhaal dan de vorige stap - run 1 zal niet deterministisch zijn totdat ze wel overeenkomen.

De demomonitor downloaden en starten

Een kubectl watch alleen in de terminal is te langzaam en tijdens een live demo makkelijk te missen. Het eigen signaal van de storefront beweegt niet gelijk op met dat van het cluster. In deze zelfstudie wordt een klein Python monitorscript uit de opslagplaats met Chaos Studio voorbeelden gebruikt als primaire manier om de uitvoering te bekijken.

1. Download de monitor en het fix-verification-script:

   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
   

   Deze links zijn vastgezet op een specifieke commit, zodat ze blijven werken, ongeacht latere wijzigingen in het voorbeeld. Zodra de bijbehorende pull request is samengevoegd, kunnen latere revisies van deze tutorial in plaats daarvan worden omgezet naar een getagde release.

2. Start de monitor en wijs deze aan op het externe IP-adres van de winkel en de zone die u in de vorige sectie hebt vastgemaakt:

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

   De monitor gebruikt alleen de Python standaardbibliotheek, dus er is niets anders om te installeren. Standaard wordt elke 5 seconden gepeild: configureerbaar met --interval of de MONITOR_INTERVAL_SECONDS omgevingsvariabele. Deze standaardwaarde is vaak genoeg om de volgorde van de signalen op te lossen zonder de Kubernetes-API of de winkel te agressief te peilen.

3. Selecteer in Cloud Shell Web Preview en stel de poort in op 8787 om de monitor in een browsertabblad te openen. Als u lokaal werkt, opent u in plaats daarvan http://localhost:8787.

   De monitorpagina is nu uw primaire weergave voor beide uitvoeringen. Er worden vier signalen weergegeven:

   • HTTP-status van de webshop - een cache-omzeilend verzoek naar de webshop, zodat u de actuele status bereikbaar/niet bereikbaar ziet in plaats van een gecachte succesvolle status.
   • Status van doelzoneknooppunt : of het knooppunt in uw doelzone is Ready of NotReady.
   • Plaatsing van front-endpods - welke store-front pods actief zijn en in welke zone elke pod zich bevindt.
   • Overgangsgeschiedenis : een actieve tijdlijn van elke statuswijziging hierboven, met tijdstempels, zodat u de volgorde kunt controleren nadat de uitvoering is beëindigd in plaats van te vertrouwen op wat u live hebt opgemerkt.

   Als een controle van kubectl of de Kubernetes-API mislukt, bijvoorbeeld omdat de API-server kort niet bereikbaar is of de kubeconfig verouderd is, toont de monitor een zichtbare rode banner met de foutmelding, in plaats van het getroffen signaal op de placeholder 'controleren' te laten staan. De overige delen van het dashboard blijven de laatst bekende correcte status en geschiedenis tonen zolang de banner zichtbaar is. Behandel de banner als een signaal op zichzelf: het betekent dat de monitor geen zicht meer heeft op datgene wat wordt bewaakt, niet dat het naar behoren functioneert.

Een werkruimte maken die is gericht op de infrastructuurresourcegroep

AKS plaatst de virtuele-machineschaalsets van het cluster in een afzonderlijke infrastructuurresourcegroep (die standaard begint metMC_), niet in de resourcegroep die de clusterresource bevat. Stel het bereik van de werkruimte in op de infrastructuurresourcegroep, zodat deze de knooppunten kan detecteren. Zie Waarom een werkruimte die is afgestemd op uw AKS-cluster geen rekendoelen vindt voor achtergrondinformatie.

1. Zoek de naam van de infrastructuurresourcegroep:

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

2. Zoek in de Azure-portal naar Chaos Studio, selecteer Werkruimten en selecteer vervolgens Maken.

3. Selecteer op het tabblad Basisinformatie de chaos-demo-rg resourcegroep, geef de werkruimte chaos-demo-workspaceeen naam en kies een ondersteunde regio. De werkruimteregio hoeft niet overeen te komen met de clusterregio.

4. Selecteer op het tabblad Bereikde resourcegroep als het bereiktype en selecteer vervolgens de infrastructuurresourcegroep in stap 1.

5. Kies op het tabblad Identiteitde optie Systeem toegewezen.

6. Selecteer Beoordelen en maken> en ga vervolgens naar de resource.

   Nadat de detectie is voltooid, wordt de virtuele-machineschaalset van het cluster (benoemd als aks-nodepool1-12345678-vmss) weergegeven als een gedetecteerde resource.

7. Als in het portaal een banner wordt weergegeven waarin staat dat de identiteit geen leesmachtigingen heeft voor het bereik van de werkruimte, selecteert u de rol Lezer toewijzen voor het bereik van de werkruimte. Als u roltoewijzingen wilt maken, hebt u eigenaars- of gebruikerstoegangsbeheerdersrechten voor de infrastructuurresourcegroep nodig.

U kent aan de identiteit de rollen toe die het scenario zelf nodig heeft in de volgende sectie, waar validatie precies aangeeft wat er ontbreekt. Zie de quickstart voor werkruimten voor een volledige uitleg van elke stap bij het maken van een werkruimte.

Voer het scenario uit en bekijk of de app mislukt

In het scenario Compute Zone Down wordt een uitval van een beschikbaarheidszone gesimuleerd door de instanties van de virtuele-machineschaalset in een doelzone uit te schakelen gedurende de geconfigureerde duur. De instanties herstarten zodra de duur van de actie is verstreken.

1. Selecteer in de werkruimte Scenario’s en selecteer vervolgens Compute Zone Down uit de scenariobibliotheek.

2. Configureer het scenario. Voer voor de beschikbaarheidszone het nummer uit $PIN_ZONE in (het deel na het laatste koppelteken, bijvoorbeeld 1 in eastus2-1). Stel de duur in op 5 minuten - lang genoeg om de storefront-, node- en podsignalen te laten stabiliseren, zonder onnodig lang te hoeven wachten. Dit cijfer van 5 minuten is afgestemd op deze specifieke demo; andere scenariotypen hebben hun eigen richtlijnen voor de duur, afhankelijk van wat ze testen. Een scenario dat is gebouwd rond dns-cachinggedrag, heeft bijvoorbeeld een duur nodig die lang genoeg is om de TTL voor de cache van de record te overschrijden, wat veel langer kan zijn dan 5 minuten. Selecteer Configuratie opslaan.

3. Validatie controleert of de beheerde identiteit van de werkruimte elke actie kan uitvoeren die het scenario nodig heeft voor de doelbronnen. Als validatie rapporteert dat er machtigingen ontbreken, selecteert u Machtigingen herstellen op de configuratiepagina van het scenario om de identiteit de aanbevolen ingebouwde rollen te verlenen. Voor dit scenario is dat: Virtual Machine Contributor op de virtuele-machineschaalset van het knooppunt. Als u de rollen zelf wilt toewijzen of aangepaste rollen met minimale bevoegdheden wilt gebruiken in plaats van ingebouwde rollen, raadpleegt u Machtigingen en identiteit in Chaos Studio Werkruimten en aangepaste rollen met minimale bevoegdheden gebruiken met Chaos Studio Werkruimten.

   Als een vereiste rol nog steeds ontbreekt tijdens de uitvoering, wordt de uitvoering toch gestart, maar mislukken de afsluitacties met een machtigingsfout in het scenariorapport.

4. Selecteer Uitvoeren en bevestigen.

Het kan enkele minuten duren nadat de run is gestart voordat de uitschakeling effect heeft, dus schrik niet als er niet meteen iets verandert op het beeldscherm. Bekijk vervolgens de monitorpagina:

• Het HTTP-signaal van de winkel en de status van het doelknooppunt worden niet op hetzelfde moment gewijzigd. Het signaal op applicatieniveau is wat uw gebruikers daadwerkelijk ervaren, en dat moet als het primaire signaal worden beschouwd; de knooppunt- en podsignalen zijn interne clusteradministratie die pas daarna volgt. Verwacht dat de storefront merkbaar eerder als onbereikbaar wordt weergegeven dan dat het knooppunt NotReady toont - dat verschil in timing is normaal, door asynchrone signaalpropagatie, en geen probleem met de demo.
• De status van het doelknooppunt wordt gewijzigd in NotReady.
• Omdat de front-end is vastgezet op die zone, kan zijn enige replica daardoor nergens anders draaien. De webshop blijft onbereikbaar totdat Kubernetes de pod opnieuw kan inplannen — wat, zolang de pin van kracht is, alleen gebeurt zodra het doelknooppunt terugkeert of u de plaatsingsbeperking wijzigt. Vertrouw hier niet op een vast getal voor de downtime; bekijk de overgangsgeschiedenis van de monitor om te zien wat er tijdens uw uitvoering daadwerkelijk is gebeurd.

Dit resultaat is de uitkomst. Het cluster was zone-redundant, maar de plaatsingskeuze van de toepassing heeft een zonefout omgezet in een storing zonder gedefinieerd einde terwijl de beperking aanwezig bleef. De statusgeschiedenis van de monitor is het overzicht van precies wanneer de webwinkel offline ging en later weer online kwam.

Problemen oplossen: de impact is niet zichtbaar

Als in de monitor wordt weergegeven dat de winkel bereikbaar blijft gedurende uitvoering 1, controleert u deze items voordat u ervan uitgaat dat het scenario niet werkt:

• Bevestig dat de pincode van kracht is. Voer uit kubectl get pods -l app=store-front -o wide en controleer of het knooppunt van de pod zich in $PIN_ZONEbevindt. Als de patch niet is toegepast, heeft de planner de replica mogelijk ergens anders geplaatst. Het opnieuw plannen tijdens de storing kan zo snel gaan dat je het zonder de vastzetpin niet opmerkt.
• Controleer of de monitor de juiste zone en URL bekijkt. Start monitor.py opnieuw op met de exacte waarde van --target-zone en de storefront-URL van uw cluster. Een verouderde of verkeerd getypte waarde geeft misleidende 'gezonde' status weer.
• Controleer het scenariorapport op Skipped acties. Als de afsluitacties worden weergegeven Skipped in plaats van Succeeded, heeft de uitvoering geen overeenkomende doelen gevonden in de doelzone. Zie De resultaten interpreteren.
• Geef het nog een paar seconden. De afsluitactie zelf duurt even voordat deze van kracht wordt nadat de uitvoering is gestart. De overgangsgeschiedenis van de monitor toont de exacte tijdstempels zodra deze zich voordoen.

De implementatie herstellen en controleren

Vervang nu de opzettelijke single-zone-vastzetting door een echte oplossing op clusterschaal: drie replica's, strikt beperkt tot één per zone.

1. Verwijder de zonepin die u eerder hebt toegevoegd:

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

2. Schaal de front-end naar drie replica's en voeg een spreidingsbeperking voor topologie toe waarvoor één replica per zone is vereist in plaats van dat u er alleen de voorkeur aan geeft:

   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 maakt de spreiding van één replica per zone tot een harde vereiste. Een replica die daar niet aan kan voldoen, blijft Pending in plaats van terecht te komen in een zone waar er al een aanwezig is. Dat is een bewuste afweging: het garandeert de zonedekking waar deze test van afhankelijk is, ten koste van het risico dat een replica mogelijk niet wordt ingepland als een zone tijdelijk geen ruimte heeft. ScheduleAnyway zou de scheduler de beperking onder druk laten overslaan, wat precies de foutmodus is die deze oplossing sluit.

3. Controleer de oplossing voordat u deze vertrouwt. Voer het verificatiescript uit. Er wordt gewacht op de implementatie, zodat verouderde pods uit de oude revisie van één replica niet worden geteld en wordt bevestigd dat elke zone ten minste één Readystore-front pod heeft:

   ./verify-fix.sh
   

   Een kubectl aanroep, een API-aanvraag of de JSON die deze retourneert, kan tijdelijk mislukken, een korte time-out, een verbroken verbinding, zonder dat de fix zelf is mislukt. Het script probeert deze tijdelijke fouten opnieuw uit te voeren totdat er een eigen time-out optreedt in plaats van af te sluiten op de eerste. Pas na het verstrijken van die time-out wordt het proces beëindigd met een niet-nulstatus en een diagnostisch bericht waarin wordt aangegeven in welke zone nog steeds een replica ontbreekt die gereed is. Ga niet verder met run 2 totdat deze succesvol is. Een geslaagde uitkomst zorgt ervoor dat "één replica per zone" een geverifieerd feit is in plaats van een aanname die is overgenomen van de patchopdracht.

Voer het scenario opnieuw uit en vergelijk

1. Voer in de werkruimte het scenario Compute Zone Down opnieuw uit met dezelfde doelzone en dezelfde duur van 5 minuten.

2. Kijk naar de monitor. Het doelknooppunt gaat NotReady nog steeds verder en neemt de store-front replica er mee naar beneden, maar de winkel reageert steeds, geleverd door de replica's in de overlevende zones. De bewering die wordt getest is aanhoudende beschikbaarheid tijdens een zone-uitval, aangetoond door de doorlopende geschiedenis van de monitor - niet dat er nul mislukte verzoeken waren, en ook niet dat de monitor gedurende de hele periode onafgebroken een gezonde status laat zien. Een korte onderbreking is nog steeds mogelijk terwijl de Azure Load Balancer overschakelt op de resterende gezonde replica's; een geslaagde testuitvoering laat een korte hapering tijdens de convergentie zien, geen uitval die even lang duurt als de verstoring. Hoe lang deze convergentie duurt, verschilt per omgeving, dus vertrouw niet op een vaste tijdsgrens. Gebruik de overgangsgeschiedenis van de monitor om een tijdelijke blip te vertellen, afgezien van een aanhoudende storing.

Componenten met één replica kunnen nog steeds een korte verstoring ondervinden. Als het knooppunt waarop de RabbitMQ-wachtrij draait zich in de doelzone bevindt, verloopt het indienen van bestellingen trager terwijl de pod herstelt. Het vinden van het volgende zwakste onderdeel en het bepalen of het de moeite waard is om het te verhelpen, is precies de cyclus die chaostesten bedoeld is op gang te brengen.

De scenariorapporten vergelijken

1. Selecteer in de werkruimte Uitvoeringsgeschiedenis. U hebt nu twee voltooide uitvoeringen van hetzelfde scenario.

2. Selecteer elke uitvoering en selecteer vervolgens Rapport genereren. Controleer of de afsluitacties in beide gevallen de status Geslaagd weergeven. Dit betekent dat elke uitvoering instanties in de doelzone heeft gevonden en verstoord. Als acties als Overgeslagen staan, heeft de uitvoering geen overeenkomende doelitems gevonden. De gebruikelijke oorzaken zijn een scope die de resourcegroep voor de infrastructuur niet omvat, of een doelzone zonder knooppunten. Zie Workloadtolerantie testen op AKS met Chaos Studio voor meer informatie.

3. U ziet dat beide rapporten er hetzelfde uitzien, ook al waren de resultaten van de toepassing tegenovergestelde. Gelukt betekent dat de verstoring is uitgevoerd - het betekent niet dat de applicatie gezond bleef. Uit het rapport blijkt welke onderbrekingen er zijn opgetreden en wanneer; de overgangsgeschiedenis van de monitor bewijst het gedrag van de toepassing als reactie. Door beide te combineren, maakt u van een uitvoering bewijs: het rapport legt het tijdstip van de fout vast en de monitor toont het verschil van vóór en na de oplossing.

U kunt zowel rapporten als vóór en na bewijs voor tolerantiebeoordelingen downloaden. Zie Scenariorapporten voor meer informatie.

De hulpbronnen opschonen

Verwijder de resourcegroep om het cluster, de voorbeeldtoepassing en de werkruimte te verwijderen. Als u het cluster verwijdert, wordt ook de bijbehorende resourcegroep voor de infrastructuur verwijderd.

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

Problemen melden en functies aanvragen

Azure Chaos Studio is ontwikkeld in het open. Als u een fout wilt melden, een functie wilt aanvragen of een vraag wilt stellen over werkruimten, scenario's of de Azure CLI-extensie, opent u een probleem in de Chaos Studio opslagplaats op GitHub. Door een probleem in te dienen, kunt u de voortgang bijhouden en aanvragen van andere klanten bekijken.

Volgende stappen 

• De veerkracht van workloads op AKS testen met Chaos Studio behandelt de aandachtspunten en richtlijnen voor de interpretatie van het uitvoeren van deze test op een echte workload.
• Om slagen of falen objectief te maken bij een echte workload, combineert u scenario-uitvoeringen met Application Insights-beschikbaarheidstests en uw eigen service-levelindicatoren in plaats van met een browsertabblad.
• Zelfstudie: Een PostgreSQL-failoverscenario met zone-down uitvoeren voegt een failover van een gegevenslaag toe aan hetzelfde storingspatroon.
• In scenario's in Azure Chaos Studio wordt de volledige scenariobibliotheek beschreven.
• De Chaos Studio GitHub opslagplaats bevat implementatiescripts voor dit voorbeeld (inclusief de scripts voor bewaking en verificatie die in deze zelfstudie worden gebruikt), deelbare aangepaste scenario's en een Copilot CLI-invoegtoepassing voor het stimuleren van Chaos Studio vanuit GitHub Copilot.