Esercitazione: Distribuire un'applicazione di esempio e testare la resilienza della zona con Chaos Studio

In questa esercitazione distribuirai un'applicazione di esempio per la vendita al dettaglio in un cluster di Servizio Azure Kubernetes (AKS) con ridondanza della zona di disponibilità e poi userai un'area di lavoro di Azure Chaos Studio per simulare due volte il guasto di una zona di disponibilità. Al primo avvio emerge una reale carenza di resilienza: il front-end dell'applicazione è deliberatamente vincolato a un'unica zona, quindi la vetrina online diventa indisponibile insieme a quella zona. Quindi correggi la distribuzione, esegui di nuovo lo stesso scenario e osservi come l'applicazione superi il guasto. Nel frattempo, avvii un monitor accessibile dal browser che mostra il guasto e la relativa correzione nel momento in cui si verificano, e impari perché la disponibilità della vetrina online e lo stato dei nodi del cluster non cambiano nello stesso momento.

Questa esercitazione costituisce un'ottima prima demo e riutilizza l'applicazione di esempio demo dello store AKS dalle guide introduttive di AKS, quindi non sono necessari né un registro contenitori né una fase di compilazione. Pianificare circa un'ora: la creazione del cluster più due esecuzioni dello scenario di circa 5 minuti ciascuno.

Importante

Le aree di lavoro e gli scenari di Azure Chaos Studio sono in anteprima pubblica. Microsoft fornisce questa anteprima "così com'è" e "come disponibile" e non è coperta da contratti di servizio o garanzia limitata. Microsoft fornisce supporto ai clienti per l'anteprima nei limiti del possibile. Questa anteprima non è destinata all'uso in produzione. Per altre informazioni, vedere gli articoli seguenti:

In questa esercitazione apprenderai a:

  • Creare un cluster AKS i cui nodi sono distribuiti in tre zone di disponibilità.
  • Distribuire l'applicazione di esempio Store Demo di AKS e vincolarne il front-end a una zona per una demo deterministica.
  • Avviare un monitoraggio basato su browser che tiene traccia della vetrina, del nodo di destinazione e del posizionamento dei pod in tempo reale.
  • Creare un'area di lavoro nell'ambito del gruppo di risorse dell'infrastruttura del cluster.
  • Eseguire lo scenario Di riduzione della zona di calcolo e osservare che l'applicazione ha esito negativo.
  • Correggi la distribuzione con un vincolo di posizionamento rigido per zona, verificala ed esegui nuovamente lo scenario.
  • Confronta i report dei due scenari.

Questo tutorial è pensato per ottenere una demo funzionante. Per i concetti alla base di ogni passaggio, le avvertenze di interrompere l'infrastruttura gestita dal servizio Azure Kubernetes e come interpretare i risultati in un carico di lavoro reale, vedere Testare la resilienza del carico di lavoro nel servizio Azure Kubernetes con Chaos Studio.

Prerequisiti

  • Una sottoscrizione di Azure. Se non si ha un account Azure, creare un account gratuito prima di iniziare.
  • interfaccia della riga di comando di Azure, kubectl, kubelogine Python 3 (solo libreria standard- nessun pacchetto da installare). Azure Cloud Shell ha tutti e quattro preinstallati. Se si lavora in locale, eseguire l'installazione kubectl con az aks install-cli e kubelogin separatamente.
  • Il provider di risorse Microsoft.Chaos registrato nella sottoscrizione. Per registrarla per la prima volta, vedere Registrare il provider di risorse Chaos Studio.

Creare un cluster del servizio Azure Kubernetes con ridondanza della zona

Un test di guasto di una zona ha senso solo con un cluster progettato per resistere al guasto di una zona, quindi crea un cluster con tre nodi distribuiti in tre zone di disponibilità. Questo esempio usa Stati Uniti orientali 2; qualsiasi area con zone di disponibilità funziona.

  1. Creare un gruppo di risorse e il 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

    La creazione del cluster richiede alcuni minuti.

  2. In una nuova sessione kubectl di Cloud Shell non è ancora connessa ad alcun cluster. Impostare la sottoscrizione, recuperare le credenziali e convertire kubeconfig per l'autenticazione Microsoft Entra prima di eseguire qualsiasi kubectl comando:

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

    Sostituisci <SUBSCRIPTION_ID> con l'ID della sottoscrizione. Ignorare az account set se la sottoscrizione è già attiva. Il passaggio kubelogin è necessario anche in una nuova sessione di Cloud Shell: senza di esso, il primo comando kubectl su un cluster autenticato con Entra non riesce e restituisce un errore di autenticazione.

  3. Verificare che i nodi si estendono su tre zone:

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

    La ZONE colonna mostra un nodo in ogni zona, ad esempio eastus2-1, eastus2-2e eastus2-3. Il numero di zona dopo il nome dell'area è quello di destinazione più avanti nella configurazione dello scenario.

Distribuire l'applicazione di esempio

La demo del negozio AKS è un piccolo negozio al dettaglio con un front-end web, un servizio prodotti, un servizio ordini e una coda RabbitMQ. Le immagini del contenitore sono pubbliche, quindi è possibile distribuirla con un singolo comando.

  1. Distribuire l'applicazione:

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

    Il manifest distribuisce ogni componente con una sola replica. Il cluster è con ridondanza della zona, ma l'applicazione no. Questa esercitazione espone e quindi risolve questo gap di resilienza.

  2. Attendere che il front-end ottenga un indirizzo IP pubblico:

    kubectl get service store-front --watch

    Quando il EXTERNAL-IP valore passa da <pending> a un indirizzo IP pubblico, premere Ctrl+C per arrestare l'orologio.

  3. Apri http://<EXTERNAL-IP> nel browser e verifica che il negozio venga caricato. Mantenere aperta questa scheda. Si tratta di una visualizzazione secondaria dell'integrità dell'applicazione durante il test. Il monitoraggio avviato in un secondo momento è quello principale.

Per informazioni su come viene compilata e distribuita l'applicazione stessa, vedere la serie di esercitazioni del servizio Azure Kubernetes.

Vincolare il front-end a una singola zona per una demo deterministica

Nota

Vincolare una singola replica a un'unica zona è una configurazione didattica volutamente creata per questa demo, non una raccomandazione per un ambiente di produzione. Una distribuzione in produzione non dovrebbe mai vincolare una singola replica a una singola zona, poiché ciò elimina la ridondanza che il cluster è progettato per garantire. Questa esercitazione lo fa intenzionalmente, in modo che il fallimento dell'esecuzione 1 sia affidabile e ripetibile anziché dipendere dalla zona che lo scheduler ha selezionato.

Senza un vincolo di posizionamento esplicito, lo scheduler può collocare l'unica replica del front-end in qualsiasi zona e una normale ripianificazione può avvenire così rapidamente che è facile non notarne l'impatto. Vincolare la replica a una zona nota rende prevedibile la destinazione e fa sì che il guasto sia osservabile ogni volta che si esegue la demo.

  1. Trovare il nodo in cui è in esecuzione il store-front pod e leggere l'etichetta di zona del nodo:

    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 è l'etichetta di zona completa, ad esempio eastus2-1. Mantenere aperta questa sessione della shell: si riutilizza questo valore per il monitoraggio e successivamente per la configurazione dello scenario (che richiede solo il numero, la parte dopo l'ultimo trattino, 1 ad esempio in eastus2-1).

  2. Applica una patch al deployment store-front per richiedere la schedulazione in quella zona e aggiungi un'annotazione che contrassegni la patch come schema solo dimostrativo:

    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. Verificare che il pin sia mantenuto: la replica deve essere di nuovo in un nodo in $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)"

    Se i due valori non coincidono, ripetere il passaggio precedente: l'esecuzione 1 non sarà deterministica finché non coincidono.

Scaricare e avviare il monitoraggio demo

Un orologio solo kubectl terminale è troppo lento e facile da perdere durante una demo live. Il segnale dello storefront non si muove in perfetta sincronia con quello del cluster. Questo tutorial usa un piccolo script di monitoraggio Python, proveniente dal repository di esempi di Chaos Studio, come strumento principale per monitorare l'esecuzione.

  1. Scaricate il monitor e lo script di verifica della correzione:

    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

    Questi collegamenti vengono aggiunti a un commit specifico in modo che continuino a funzionare indipendentemente dalle modifiche successive all'esempio. Una volta che la pull request di integrazione viene unita, le revisioni successive di questo tutorial potranno invece fare riferimento a una release contrassegnata da un tag.

  2. Avvia il monitor, puntandolo verso l'indirizzo IP esterno della vetrina e la zona che hai fissato nella sezione precedente:

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

    Il monitoraggio usa solo la libreria standard Python, quindi non c'è altro da installare. Per impostazione predefinita, esegue il polling ogni 5 secondi, configurabile con --interval o la variabile di MONITOR_INTERVAL_SECONDS ambiente. Questa impostazione predefinita è sufficientemente frequente da determinare l'ordine dei segnali senza interrogare l'API di Kubernetes o la vetrina in modo troppo aggressivo.

  3. In Cloud Shell, seleziona Anteprima Web e imposta la porta su 8787 per aprire il monitor in una scheda del browser. Se invece lo esegui in locale, apri http://localhost:8787.

    La pagina di monitoraggio è ora la visualizzazione principale per entrambe le esecuzioni. Mostra quattro segnali:

    • Stato HTTP della vetrina - una richiesta verso la vetrina che bypassa la cache, in modo da visualizzare uno stato in tempo reale di raggiungibilità/non raggiungibilità anziché un esito positivo memorizzato nella cache.
    • Stato del nodo della zona di destinazione: se il nodo nella zona di destinazione è Ready o NotReady.
    • Posizionamento dei pod front-end : i store-front pod in esecuzione e la zona in cui si trova ognuno di essi.
    • Cronologia delle transizioni : sequenza temporale in esecuzione di ogni modifica dello stato precedente, con timestamp, in modo da poter esaminare la sequenza al termine dell'esecuzione invece di basarsi su ciò che si è notato in tempo reale.

    Se un controllo di kubectl o dell'API Kubernetes non va a buon fine - ad esempio, perché il server API è temporaneamente irraggiungibile o il kubeconfig non è più valido - il monitor mostra un banner rosso ben visibile con l'indicazione dell'errore, invece di lasciare il segnale interessato bloccato su un segnaposto "verifica in corso". Il resto della dashboard continua a mostrare l’ultimo stato noto e valido e la cronologia finché il banner è visualizzato. Considera il banner come un segnale a sé stante: significa che il monitor ha perso visibilità, non che l’elemento che sta monitorando sia in salute.

Creare un'area di lavoro nell'ambito del gruppo di risorse dell'infrastruttura

AKS colloca i set di scalabilità di macchine virtuali dei nodi del cluster in un gruppo di risorse dell'infrastruttura separato (il cui nome inizia con MC_ per impostazione predefinita), non nel gruppo di risorse che contiene la risorsa del cluster. Definire l'ambito dell'area di lavoro per il gruppo di risorse dell'infrastruttura in modo da individuare i nodi. Per informazioni di base, consultare Perché un'area di lavoro con ambito limitato al cluster AKS non trova destinazioni di calcolo.

  1. Trovare il nome del gruppo di risorse dell'infrastruttura:

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

  2. Nel portale di Azure cercare Chaos Studio, selezionare Aree di lavoro e quindi crea.

  3. Nella scheda Informazioni di base selezionare il chaos-demo-rg gruppo di risorse, denominare l'area di lavoro chaos-demo-workspacee scegliere un'area supportata. L'area dell'area di lavoro non deve corrispondere all'area del cluster.

  4. Nella scheda Ambito selezionare Gruppo di risorse come tipo di ambito e quindi selezionare il gruppo di risorse dell'infrastruttura nel passaggio 1.

  5. Nella scheda Identità scegliere Assegnata dal sistema.

  6. Selezionare Rivedi e crea>crea e quindi Vai alla risorsa.

    Una volta completato il rilevamento, il set di scalabilità di macchine virtuali del nodo del cluster (con un nome simile a aks-nodepool1-12345678-vmss) compare come risorsa individuata.

  7. Se nel portale viene visualizzato un banner che indica che l'identità non dispone delle autorizzazioni di lettura per l'ambito dell'area di lavoro, selezionare Assegna il ruolo Lettore per l'ambito dell'area di lavoro. Per creare assegnazioni di ruolo, sono necessarie le autorizzazioni di Proprietario o Amministratore dell'accesso utente sul gruppo di risorse dell'infrastruttura.

Assegni all'identità i ruoli di cui lo scenario stesso ha bisogno nella sezione seguente, dove la convalida ti indica esattamente cosa manca. Per una procedura dettagliata completa di ogni passaggio di creazione dell'area di lavoro, vedere la guida introduttiva all'area di lavoro.

Esegui lo scenario e guarda l'app andare in errore

Lo scenario Zona di ambiente di calcolo non disponibile simula un guasto in una zona di disponibilità arrestando le istanze del set di scalabilità di macchine virtuali nella zona di destinazione per la durata configurata. Le istanze si riavviano al termine della durata dell'azione.

  1. Nell'area di lavoro selezionare Scenari e quindi selezionare Zona di calcolo inattiva dalla libreria di scenari.

  2. Configurare lo scenario. Per la zona di disponibilità immettere il numero da $PIN_ZONE (la parte dopo l'ultimo trattino, ad esempio 1 in eastus2-1). Imposta la durata su 5 minuti: un tempo sufficiente per vedere stabilizzarsi i segnali di storefront, nodo e pod, senza dover attendere troppo a lungo. Questa durata di 5 minuti è prevista per questa specifica demo; altri tipi di scenario prevedono indicazioni sulla durata proprie, in base a ciò che viene testato. Ad esempio, uno scenario basato sul comportamento di memorizzazione nella cache DNS richiede una durata sufficiente per superare il TTL della cache del record, che può essere molto più lungo di 5 minuti. Selezionare Salva configurazione.

  3. La convalida verifica se l'identità gestita dell'area di lavoro può eseguire tutte le azioni richieste dallo scenario sulle risorse di destinazione. Se la convalida segnala autorizzazioni mancanti, selezionare Correggi autorizzazioni nella pagina di configurazione dello scenario per concedere all'identità i ruoli predefiniti consigliati. In questo scenario, si tratta del ruolo Virtual Machine Contributor nel set di scalabilità delle macchine virtuali del nodo. Per assegnare i ruoli manualmente o per usare ruoli personalizzati con privilegi minimi anziché ruoli predefiniti, vedere Autorizzazioni e identità nelle aree di lavoro di Chaos Studio e Usare ruoli personalizzati con privilegi minimi con aree di lavoro Chaos Studio.

    Se in fase di esecuzione manca ancora un ruolo obbligatorio, l'esecuzione si avvia comunque, ma le operazioni di arresto non riescono e nel report dello scenario viene segnalato un errore di autorizzazione.

  4. Selezionare Esegui e conferma.

Possono essere necessari alcuni minuti dopo l'inizio dell'esecuzione prima che lo spegnimento abbia effetto, quindi non allarmarti se non vedi subito alcun cambiamento sul monitor. Guardare quindi la pagina di monitoraggio:

  • Il segnale HTTP della vetrina e lo stato del nodo di destinazione non cambiano nello stesso momento. Il segnale a livello di applicazione è quello che gli utenti effettivamente sperimentano ed è quello da considerare come primario; i segnali dei nodi e dei pod sono la contabilità interna del cluster che si recuperano in seguito. Aspettatevi che lo storefront mostri “non raggiungibile” con un certo anticipo rispetto a quando il nodo mostra NotReady: questo intervallo è normale, è dovuto alla propagazione asincrona dei segnali e non indica un problema della demo.
  • Lo stato del nodo di destinazione cambia in NotReady.
  • Poiché il front-end è vincolato a quella zona, la sua unica replica non ha nessun altro posto in cui possa essere eseguita. La vetrina rimane irraggiungibile finché Kubernetes non riesce a ripianificare il pod, operazione che, con il pin attivo, avviene solo quando il nodo di destinazione torna disponibile oppure si modifica il vincolo di posizionamento. Non fare affidamento su un valore fisso del tempo di inattività in questo caso; controlla la cronologia delle transizioni del monitor per verificare cosa è successo davvero durante l'esecuzione.

Questo risultato è la conclusione. Il cluster era con ridondanza di zona, ma la scelta di posizionamento dell'applicazione ha trasformato un guasto della zona in un'interruzione senza una fine definita finché il vincolo è rimasto in vigore. La cronologia delle transizioni del monitor è il registro che indica con precisione quando lo store non era raggiungibile e, successivamente, quando è tornato disponibile.

Risoluzione dei problemi: l'impatto non è visibile

Se il monitor mostra che la storefront rimane raggiungibile nel corso dell'esecuzione 1, verifica questi elementi prima di concludere che lo scenario non abbia funzionato:

  • Conferma che il PIN sia stato applicato. Eseguire kubectl get pods -l app=store-front -o wide e verificare che il nodo del pod sia in $PIN_ZONE. Se la patch non è stata applicata, lo scheduler potrebbe aver collocato la replica altrove. Una semplice riprogrammazione durante l'interruzione può avvenire così rapidamente da passare inosservata senza il PIN.
  • Verificare che il monitoraggio guardi la zona e l'URL corretti. Riavvia monitor.py con il valore esatto --target-zone e l'URL della vetrina del cluster. Un valore non aggiornato o digitato erroneamente visualizza un fuorviante stato "sano".
  • Verifica il report dello scenario Skipped per le azioni. Se le azioni di arresto mostrano Skipped anziché Succeeded, l'esecuzione non ha trovato destinazioni corrispondenti nella zona di destinazione. Vedere Interpretare i risultati.
  • Dargli qualche secondo. L'azione di arresto stesso richiede poco tempo per essere applicata dopo l'avvio dell'esecuzione. La cronologia delle transizioni del monitor mostra le marche temporali esatte non appena si verificano.

Correggere la distribuzione e verificarla

Ora sostituisci il vincolo intenzionale su una singola zona con una soluzione reale su scala cluster: tre repliche, rigidamente vincolate a una per zona.

  1. Rimuovi il pin della zona che hai aggiunto in precedenza:

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

  2. Ridimensionare il front-end a tre repliche e aggiungere un vincolo di distribuzione della topologia che richiede una replica per zona anziché semplicemente preferirla:

    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 rende la distribuzione di una replica per zona un requisito rigido. Una replica che non può soddisfare il requisito rimane Pending invece di finire in una zona che ha già una replica. Si tratta di un compromesso intenzionale: garantisce la copertura delle zone da cui dipende questo test, al costo che una replica possa temporaneamente rimanere non pianificata se una zona non ha capacità disponibile. ScheduleAnyway consentirebbe allo scheduler di ignorare il vincolo in condizioni di stress, che è esattamente lo scenario di errore che questa correzione risolve.

  3. Verificare la correzione prima di considerarla attendibile. Esegui lo script di verifica. Attende il completamento della distribuzione in modo che i pod obsoleti della precedente revisione con una sola replica non vengano conteggiati, quindi conferma che ogni zona abbia almeno un pod Readystore-front:

    ./verify-fix.sh

    Una kubectl chiamata, una richiesta API o il codice JSON restituito può avere esito negativo temporaneo, ovvero un breve timeout, una connessione eliminata, senza che la correzione stessa non sia riuscita. Lo script continua a riprovare in caso di errori temporanei fino al raggiungimento del proprio timeout, anziché terminare al primo errore. Solo allo scadere di tale timeout termina con uno stato di uscita diverso da zero e con un messaggio diagnostico che indica in quale zona manca ancora una replica pronta. Non procedere a eseguire il test 2 finché il test precedente non viene superato. Un esito positivo è quello che conferma che "una replica per zona" è un fatto verificato, invece di una supposizione derivata dal comando patch.

Eseguire di nuovo lo scenario e confrontarlo

  1. Nell'area di lavoro, esegui nuovamente lo scenario Compute Zone Down con la stessa zona di destinazione e la stessa durata di 5 minuti.

  2. Guarda il monitor. Il nodo di destinazione va comunque NotReady e trascina con sé anche la propria replica store-front, ma lo storefront continua a rispondere, servito dalle repliche nelle zone sopravvissute. L’affermazione oggetto del test è la disponibilità mantenuta durante l’interruzione della zona, dimostrata dallo storico continuo del monitor, non dall’assenza di richieste perse, né dal fatto che il monitor mostri uno stato di integrità ininterrotto per tutta la durata. Una breve interruzione è ancora possibile mentre Azure Load Balancer si riallinea alle restanti repliche integre; un passaggio di verifica mostra una breve oscillazione di convergenza, non un'interruzione che duri quanto l'intera durata del disservizio. Il tempo necessario per la convergenza varia in base all'ambiente, quindi non fare affidamento su un limite temporale fisso: usa la cronologia delle transizioni del monitor per distinguere un'anomalia transitoria da un'interruzione prolungata.

I componenti con una sola replica possono comunque subire una breve interruzione. Se il nodo della coda RabbitMQ si trova nella zona di destinazione, l'invio degli ordini subisce un rallentamento durante il ripristino del relativo pod. Trovare il successivo componente più debole e decidere se valga la pena correggerlo è esattamente il ciclo che il chaos testing è progettato per alimentare.

Confrontare i report dello scenario

  1. Nell'area di lavoro selezionare Cronologia di esecuzione. Sono state eseguite due esecuzioni completate dello stesso scenario.

  2. Selezionare ciascuna esecuzione e quindi selezionare Genera report. Verificare che le azioni di arresto mostrino lo stato Completato in entrambi i casi, il che significa che ogni esecuzione ha individuato e interrotto delle istanze nella zona di destinazione. Se vengono visualizzate azioni con stato Ignorato, l'esecuzione non ha trovato destinazioni corrispondenti. Le cause consuete sono un ambito che non include il gruppo di risorse dell'infrastruttura o una zona di destinazione senza nodi. Per altre informazioni, vedere Testare la resilienza del carico di lavoro nel servizio Azure Kubernetes con Chaos Studio.

  3. Si noti che entrambi i report hanno lo stesso aspetto anche se i risultati dell'applicazione erano opposti. Riuscito indica che l'interruzione è stata applicata: non significa che l'applicazione abbia continuato a funzionare correttamente. Il report dimostra quale interruzione si è verificata e quando; la cronologia delle transizioni del monitor è quella che dimostra il comportamento dell'applicazione in risposta a tale interruzione. Abbinare i due consente di trasformare un'esecuzione in una prova: il report registra l'ora dell'errore e il monitor mostra la differenza tra prima e dopo che la correzione ha prodotto.

È possibile scaricare entrambi i report come prove precedenti e successive per le revisioni della resilienza. Per informazioni dettagliate, vedere Report di scenario.

Pulire le risorse

Eliminare il gruppo di risorse per rimuovere il cluster, l'applicazione di esempio e l'area di lavoro. L'eliminazione del cluster elimina anche il gruppo di risorse dell'infrastruttura.

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

Segnalare problemi e funzionalità di richiesta

Azure Chaos Studio è sviluppato in modo aperto. Per segnalare un bug, richiedere una funzionalità o porre una domanda su aree di lavoro, scenari o l'estensione interfaccia della riga di comando di Azure, aprire un problema nel repository Chaos Studio in GitHub. Inviando un problema, è possibile tenere traccia dello stato di avanzamento e visualizzare le richieste provenienti da altri clienti.

Passaggi successivi

  • Last updated on