Analizza un'interruzione di GKE con l'interfaccia a riga di comando Antigravity e l'estensione SRE e crea un post mortem dettagliato

1. Introduzione

856ff52e60953a92.png

Ultimo aggiornamento: 13/05/2026

Analizza un'interruzione di GKE con l'estensione SRE e crea un post mortem dettagliato

Ti diamo il benvenuto a questo workshop SRE, per gli operatori che vogliono sperimentare gli strumenti SRE su Google Cloud.

Questo codelab ti guiderà in questa procedura:

  1. Installa un cluster GKE basato su una microservices-demo open source ben nota.
  2. Crea un'interruzione rompendola in modi diversi (alcuni più evidenti, altri più sfumati).
  3. Installa e utilizza Antigravity CLI (o un harness simile) + SRE Extension per la parte successiva.
  4. Esamina e, se possibile, risolvi l'interruzione.
  5. Crea un post mortem.
  6. Utilizza le competenze di creazione di grafici per generare un grafico basato sui dati che consenta agli spettatori di capire cosa è successo e quando.

Ecco la struttura passo passo del codelab:

Diagramma della struttura del codelab

Lo scopo di questo workshop è:

  1. mostrare le funzionalità dell'estensione SRE e cosa è possibile fare con essa: configurazione di OneMCP, Safe Executor, indagine, generazione di post mortem, grafici e gist CSV.
  2. Insegnarti le competenze per analizzare il tuo scenario Google Cloud.

Traguardo 1: configurazione dell'ambiente e simulazione dell'interruzione

L'obiettivo di questo traguardo è configurare un'applicazione demo Kubernetes su GKE Autopilot, installare Antigravity CLI e attivare artificialmente scenari di interruzione del cluster GKE per simulare incidenti di produzione.

Traguardo 2: indagine e mitigazione con l'estensione SRE

Dopo aver interrotto l'ambiente, utilizzerai gli strumenti CLI agentic dotati dell'estensione SRE per scoprire sistematicamente l'infrastruttura, eseguire il triage dei problemi, implementare il pattern di esecuzione sicuro per le correzioni e verificare l'integrità del cluster.

Milestone 3: Post Mortem and Graph Generation

Una volta risolto il problema, genererai un documento post mortem strutturato dell'incidente e utilizzerai le API GCM (Google Cloud Monitoring) per estrarre i dati delle metriche reali, creando grafici visivi per documentare quando e come si è verificato l'interruzione.

Cosa creerai

In questo codelab, esaminerai e risolverai le interruzioni di GKE utilizzando l'estensione SRE. Imparerai a:

  • Simula un'interruzione di GKE utilizzando il blocco delle policy di rete, i deployment canary con bug e gli aggiornamenti delle regole firewall.
  • Esegui il triage dell'interruzione del cluster utilizzando un assistente CLI basato sull'estensione SRE.
  • Implementa i passaggi di correzione in modo sicuro utilizzando il pattern Safe Executor.
  • Genera un documento post mortem completo.
  • Rappresenta graficamente le metriche degli incident utilizzando le query delle serie temporali di Google Cloud Monitoring.

Cosa imparerai a fare

  • Come ispezionare le risorse e i criteri Kubernetes di GKE utilizzando le competenze dell'estensione SRE.
  • Come utilizzare il pattern Safe Executor per eseguire i comandi suggeriti dall'agente con una corretta valutazione del rischio.
  • Come utilizzare la skill monitoring-graphs per generare grafici basati su metriche direttamente da GCM.
  • Come documentare i risultati degli incidenti in un formato postmortem strutturato.

Che cosa ti serve

  • Un progetto Google Cloud con la fatturazione abilitata.
  • Strumenti a riga di comando: gcloud, kubectl, terraform.
  • Antigravity CLI installata localmente o in Cloud Shell.
  • Un IDE (ad es. vscode, IntelliJ, RubyMine o Vim).

Perché l'estensione SRE + l'interfaccia a riga di comando Agentic?

Le interruzioni della produzione sono rapide e richiedono la correlazione tra più sottosistemi (risorse Kubernetes, reti VPC, metriche Cloud Monitoring, autorizzazioni IAM). L'estensione SRE consente agli helper della CLI agentica (come Antigravity CLI) di fungere da copiloti autonomi, eseguendo playbook precompilati, interrogando grafici di monitoraggio e suggerendo correzioni sicure, il tutto mantenendo l'operatore umano nel ciclo.

2. Preparazione

Scegli una delle seguenti opzioni: Configurazione dell'ambiente autonomo se vuoi eseguire questa

codelab sulla tua macchina oppure avvia Cloud Shell se vuoi eseguire questo codelab interamente nel cloud.

Configurazione dell'ambiente autonomo

  1. Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È una stringa di caratteri non utilizzata dalle API di Google. Puoi sempre aggiornarlo.
  • L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo l'impostazione). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere identificato come PROJECT_ID). Se non ti piace l'ID generato, puoi generarne un altro casuale. In alternativa, puoi provare a crearne uno e verificare se è disponibile. Non può essere modificato dopo questo passaggio e rimane per tutta la durata del progetto.
  • Per tua informazione, esiste un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
  1. Successivamente, dovrai abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. Completare questo codelab non costa molto, se non nulla. Per arrestare le risorse ed evitare addebiti oltre a quelli previsti in questo tutorial, puoi eliminare le risorse che hai creato o il progetto. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.

Avvia Cloud Shell

Sebbene Google Cloud possa essere gestito da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.

Nella console Google Cloud, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:

Attiva Cloud Shell

Bastano pochi istanti per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere un risultato simile a questo:

Screenshot del terminale Google Cloud Shell che mostra che l'ambiente è connesso

Questa macchina virtuale è caricata con tutti gli strumenti per sviluppatori di cui avrai bisogno. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione della rete. Tutto il lavoro in questo codelab può essere svolto all'interno di un browser. Non devi installare nulla.

3. Prerequisiti (installazione)

Per questo tutorial, devi installare:

1. Python e uv

python e uv (gestore dei pacchetti per Python). Assicurati di aver installato uv:

$ curl -LsSf https://astral.sh/uv/install.sh | sh

Perché la protezione UV? Sebbene tu possa utilizzare il gestore Python che preferisci, l'utilizzo di uv garantisce che la configurazione ENV/PATH per Python sia uguale per te e per Antigravity CLI, in modo che la tua esperienza shell sia per lo più la stessa di quella di Antigravity CLI. Se utilizzi virtualenv , ad esempio, Antigravity CLI sarà costretta a eseguire operazioni come "source .env/venv/bin/activate && my-original-command" per simulare il tuo ambiente.

2. Antigravity CLI (agy)

Per installare la CLI Antigravity ufficiale (il comando agy), apri il terminale ed esegui il programma di installazione bootstrap:

Per macOS e Linux:

$ curl -fsSL https://antigravity.google/cli/install.sh | bash

Per Windows (PowerShell):

irm https://antigravity.google/cli/install.ps1 | iex

Questo script rileva dinamicamente il sistema operativo e l'architettura, scarica l'ultima versione compilata

agy

binario e configura il PATH. Riavvia il terminale o ricarica la configurazione della shell affinché le modifiche abbiano effetto.

efade99623113f1.png

Autenticazione

Devi disporre di una chiave API di Google AI Studio.

Esporta la chiave API:

export GEMINI_API_KEY="your-api-key"

Esegui l'autenticazione con gcloud:

export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
export GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"
gcloud auth application-default login

Configura l'ambiente di lavoro ed esegui il deployment dell'applicazione demo di microservizi

Cloniamo l'applicazione microservices-demo ed eseguiamo il deployment dell'infrastruttura e dell'applicazione tramite Terraform

Questo è il momento in cui puoi aprire il tuo IDE (Visual Studio Code, IntelliJ, RubyMine, ..) e aprire la cartella.

# 1. Find an empty directory, and download this repo.
git clone https://github.com/GoogleCloudPlatform/microservices-demo.git
cd microservices-demo/terraform

# 2. Update project ID to your gcloud project ID
sed -i 's/<project_id_here>/YOUR_ACTUAL_PROJECT_ID/g' terraform.tfvars

# 3. Deploy the microservices-demo application in GKE autopilot
# If there is a prompt answer yes and continue. This step can take up to 10 mins for provision gke autopilot cluster and deploy microservices-demo application
terraform init
terraform plan
terraform apply

# 4. Verify the IP address of frontend-service to access the online-boutique application
kubectl get service frontend-external | awk '{print $4}'

# 5. Find an empty directory , and download this repo.
git clone https://github.com/palladius/sre-testing-suite.git
cd sre-testing-suite/test-scenarios/microservices-demo-gke/breakage-scenarios

Per testare la configurazione, puoi accedere a http://[IP ADDRESS] e caricare l'app online-boutique

Configura l'ambiente di lavoro per sre-antigravity-cli-extension

# 1. Install the SRE Extension plugin globally
git clone https://github.com/gemini-cli-extensions/sre.git ~/.gemini/config/plugins/sre-extension

# 2. Launch the Antigravity CLI (agy)
agy  # This runs the CLI under your current breakage-scenarios folder.
# Login with your corporate or personal account when prompted.

# 3. Within the agy agent prompt, configure your MCP servers and GCP project
Use the gcp-mcp-setup skill to setup my GCP project "<gcp_project_id>" with email jane-doe-sre@credible-company.com

4. Passaggio 1: simula l'interruzione (scenari di interruzione)

In questo passaggio, interromperemo intenzionalmente il cluster GKE di cui è stato eseguito il deployment per simulare un incidente di produzione reale. Puoi scegliere tra tre scenari (o provarli tutti e tre in sequenza):

Scenario 1: blocco della rete di servizi di pagamento (standard/autopilota)

Questo scenario simula una connessione interrotta tra il frontend e il servizio di pagamento applicando un NetworkPolicy Kubernetes che funge da "buco nero" del traffico.

  1. Vai alla cartella dello scenario: 
    cd breakage1-checkout
  2. Attiva l'interruzione: 
    ./break.sh
    Viene creata una NetworkPolicy denominata update-checkout-from-frontend nello spazio dei nomi default, che nega il traffico in entrata a checkoutservice, a meno che non provenga da un pod con l'etichetta app: frontend-checkout-test (che non esiste).
  3. Prova ad acquistare articoli nel frontend della Boutique online. La pagina di pagamento si bloccherà o mostrerà un errore HTTP 500.

Scenario 2: implementazione canary con bug (autopilota con Istio)

Questo scenario simula un deployment errato in cui viene implementata una versione buggata del frontend tramite un deployment canary di Kubernetes.

  1. Vai alla cartella dello scenario: 
    cd ../breakage2-canary
  2. Attiva l'interruzione: 
    ./break.sh
    Viene eseguito il deployment di un deployment canary frontend-canary che presenta un errore di battitura nelle variabili di ambiente: PRODUCT_CATALOG_SERVICE_ADDR è configurato su productcatalogservices:3550 anziché su productcatalogservice:3550.
  3. Carica la home page del frontend. A volte non andrà a buon fine (a seconda dei pesi di routing) perché il servizio canary non riesce a risolvere il catalogo dei prodotti.

Scenario 3: blocco del cluster firewall VPC

Questo scenario simula un errore nella configurazione del firewall VPC che blocca tutto il traffico in entrata verso il cluster GKE.

  1. Vai alla cartella dello scenario: 
    cd ../breakage3-firewall
  2. Attiva l'interruzione: 
    ./break.sh
    In questo modo viene creata una regola firewall a livello di VPC denominata frontend-ingress-v2 con priority=1 e azione DENY che ha come target il traffico in entrata verso le porte 80, 443 e 8080.
  3. Il sito web Online Boutique diventerà completamente irraggiungibile e le richieste andranno in timeout.

5. Passaggio 2: indagine sull'interruzione con l'estensione SRE

Ora che l'applicazione non è più disponibile, iniziamo l'indagine utilizzando l'assistente CLI (Antigravity CLI).

  1. Torna alla cartella principale degli scenari di interruzione e avvia l'helper CLI: 
    cd ..
agy
  2. Chiedi all'assistente di eseguire un controllo di rilevamento e diagnostica dell'infrastruttura: 
    Investigate my GKE cluster for outages. Are all services healthy?
  3. Cosa fa l'agente:
    • Attiva le skill investigation-entrypoint e gcp-playbooks.
    • Elenca pod, deployment e servizi Kubernetes per individuare i target non riusciti.
    • Ispeziona i criteri di rete (per lo scenario 1), le configurazioni di deployment (per lo scenario 2) o le regole firewall (per lo scenario 3).
  4. Per lo scenario 1, l'agente deve segnalare: 🔴 Incidente identificato: un NetworkPolicy denominato update-checkout-from-frontend sta isolando i pod checkoutservice.
  5. Per lo scenario 2, l'agente deve segnalare: 🔴 Incidente identificato: il deployment frontend-canary è configurato con un endpoint di servizio non valido productcatalogservices:3550 anziché productcatalogservice:3550.
  6. Per lo scenario 3, l'agente deve segnalare: 🔴 Incidente identificato: una regola firewall VPC frontend-ingress-v2 nega il traffico in entrata sulle porte 80, 443 e 8080.

6. Passaggio 3: mitigazione e risoluzione dell'interruzione

Utilizziamo il pattern Safe Executor della CLI per risolvere l'interruzione.

  1. Chiedi all'assistente CLI di proporre e applicare una correzione: 
    Propose a fix for the outage and apply it.
  2. Safe Executor in azione:
    • Prima di eseguire i suggerimenti per i comandi, l'estensione SRE esegue un controllo di sicurezza utilizzando la skill safe-sre-investigator.
    • Ti mostrerà il comando esatto che intende eseguire e valuterà il rischio (ad es. basso, medio, alto).
    • Per lo scenario 1, verrà proposto: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • Per lo scenario 2, verrà proposto: 
      kubectl delete deployment frontend-canary
    • Per lo scenario 3, verrà proposto: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. Conferma l'esecuzione del comando quando richiesto dalla CLI.
  4. Verifica che il sito web sia di nuovo attivo e completamente funzionante aggiornando la home page di Online Boutique.
  5. Nella shell, puoi eseguire lo script di controllo dello scenario corrispondente per verificare l'integrità: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. Passaggio 4: genera l'analisi post-mortem dell'incidente

Una parte essenziale del ciclo di vita SRE è la documentazione dell'incidente, in modo che il team possa imparare da esso. Automatizziamo questa operazione utilizzando la skill postmortem-create.

  1. Nell'assistente CLI, chiedi di scrivere il documento post mortem: 
    Create a postmortem for the checkout service network policy outage.
  2. L'agente raccoglierà i dettagli relativi a:
    • L'ora di inizio dell'incidente (recuperata dalla cronologia/dai log dei comandi della CLI).
    • La causa principale (la NetworkPolicy di blocco).
    • Le azioni intraprese per mitigarla.
  3. Verrà creato un nuovo file Markdown denominato postmortem.md nello spazio di lavoro.
  4. Apri postmortem.md per esaminare i dettagli. Vedrai sezioni come:
    • Riepilogo dell'incidente
    • Cronologia degli eventi
    • Analisi della causa principale (RCA)
    • Azioni / Misure preventive

8. Passaggio 5: aggiunta di grafici delle metriche basate su dati reali

Per rendere professionale l'analisi post-mortem, abbiamo bisogno di prove visive dell'incidente. Utilizzeremo la skill monitoring-graphs per recuperare i dati delle serie temporali da Google Cloud Monitoring (GCM) e generare un grafico PNG che mostra il picco di errori.

  1. Chiedi all'helper della CLI di generare il grafico e aggiungerlo all'analisi post-mortem: 
    Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md.
  2. Sotto il cofano:
    • L'agente chiama lo script Python monitoring-graphs per eseguire query su Cloud Monitoring.
    • Recupera le metriche (ad es. kubernetes.io/container/restart_count o loadbalancing.googleapis.com/https/request_count).
    • Traccia il grafico utilizzando matplotlib e lo salva come incident_metrics.png.
    • Aggiorna il file postmortem.md inserendo un link immagine: 
      ![Incident Metric Graph](incident_metrics.png)
  3. Apri il file incident_metrics.png generato per visualizzare il grafico che illustra i momenti esatti in cui il cluster è andato inattivo e quando il traffico è tornato alla normalità.

9. Passaggio 6: pulizia

Per assicurarti che il tuo account Google Cloud non comporti addebiti non necessari, liberiamo spazio nell'infrastruttura di cui è stato eseguito il deployment.

  1. Vai alla cartella Terraform: 
    cd ../../microservices-demo/terraform
  2. Esegui il comando destroy: 
    terraform destroy -auto-approve
  3. Verifica che tutte le risorse GKE di Google Cloud siano state eliminate correttamente.

10. Complimenti!

Hai completato il Codelab relativo all'analisi di interruzioni e malfunzionamenti dei cluster GKE.

Argomenti trattati:

  • È stato eseguito il deployment della demo di microservizi Online Boutique a 10 livelli in GKE.
  • Simulazione di tre interruzioni SRE reali (negazione dei criteri di rete, implementazione canary con bug, negazione della regola firewall VPC).
  • Ha utilizzato l'estensione SRE per Antigravity CLI per scoprire e diagnosticare le interruzioni.
  • Ha sfruttato il pattern Safe Executor per esaminare ed eseguire i comandi di correzione.
  • È stato creato un postmortem professionale in Markdown.
  • Eseguite query sulle metriche di Cloud Monitoring per generare e incorporare automaticamente un grafico degli incidenti basato su dati reali.

Per maggiori dettagli sull'estensione dell'agente CLI, consulta la pagina GitHub dell'estensione SRE.