GKE-Ausfall mit Antigravity CLI und SRE-Erweiterung untersuchen und einen aussagekräftigen Post-Mortem-Bericht erstellen

1. Einführung

856ff52e60953a92.png

Zuletzt aktualisiert: 13.05.2026

GKE-Ausfall mit der SRE-Erweiterung untersuchen und einen aussagekräftigen Post Mortem-Bericht erstellen

Willkommen zu diesem SRE-Workshop für Operatoren, die mit SRE-Harnesses in Google Cloud experimentieren möchten.

In diesem Codelab erfahren Sie, wie Sie das tun:

  1. Installieren Sie einen GKE-Cluster basierend auf einer bekannten Open-Source-Mikrodienste-Demo.
  2. Erstelle einen Ausfall, indem du ihn auf unterschiedliche Weise simulierst (einige auffälliger, andere subtiler).
  3. Installieren und verwenden Sie die Antigravity CLI (oder ein ähnliches Tool) + SRE-Erweiterung für den folgenden Teil.
  4. Untersuche und behebe den Ausfall.
  5. Erstellen Sie eine Analyse.
  6. Verwende die Diagrammfunktionen, um ein fundiertes Diagramm zu erstellen, mit dem Zuschauer nachvollziehen können, was wann passiert ist.

So ist das Codelab aufgebaut:

Diagramm zur Codelab-Struktur

Ziel dieses Workshops ist es,

  1. die Funktionen der SRE-Erweiterung demonstrieren und Ihnen zeigen, was damit möglich ist: OneMCP-Einrichtung, Safe Executor, Untersuchung, Post-Mortem-Generierung, Diagramme und CSV-Gists.
  2. Sie lernen, wie Sie Ihr eigenes Google Cloud-Szenario untersuchen.

Meilenstein 1: Umgebung einrichten und Ausfall simulieren

Ziel dieses Meilensteins ist es, eine Kubernetes-Demoanwendung in GKE Autopilot einzurichten, die Antigravity-Befehlszeile zu installieren und künstlich Szenarien für GKE-Clusterfehler auszulösen, um Produktionsvorfälle zu simulieren.

Meilenstein 2: Untersuchung und Eindämmung mit SRE-Erweiterung

Nachdem Sie die Umgebung beschädigt haben, verwenden Sie agentenbasierte CLI-Tools mit der SRE-Erweiterung, um die Infrastruktur systematisch zu ermitteln, die Probleme zu beheben, das sichere Ausführungsmuster für Korrekturen zu implementieren und den Clusterstatus zu überprüfen.

Meilenstein 3: Post Mortem und Diagrammerstellung

Nach der Behebung erstellen Sie ein strukturiertes Post-Mortem-Dokument für den Vorfall und verwenden GCM-APIs (Google Cloud Monitoring), um echte Messwertdaten abzurufen und visuelle Diagramme zu erstellen, die dokumentieren, wann und wie der Ausfall aufgetreten ist.

Umfang

In diesem Codelab untersuchen und beheben Sie GKE-Ausfälle mithilfe der SRE Extension. Sie werden Folgendes tun:

  • Simulieren Sie einen GKE-Ausfall mithilfe von Netzwerkrichtlinien, fehlerhaften Canary-Bereitstellungen und Firewallregel-Updates.
  • Mit einem CLI-Assistenten, der von der SRE-Erweiterung unterstützt wird, die Clusterunterbrechung beheben
  • Behebungsschritte sicher mit dem Safe Executor-Muster implementieren.
  • Erstellen Sie ein umfassendes Analysedokument.
  • Messwerte für Vorfälle mit Zeitreihenabfragen von Google Cloud Monitoring grafisch darstellen

Lerninhalte

  • So prüfen Sie GKE-Kubernetes-Ressourcen und ‑Richtlinien mit SRE Extension-Kenntnissen.
  • So nutzen Sie das Safe Executor-Muster, um von Agents vorgeschlagene Befehle mit einer angemessenen Risikobewertung auszuführen.
  • So verwenden Sie den monitoring-graphs-Skill, um fundierte Diagramme von Messwerten direkt aus GCM zu generieren.
  • So dokumentieren Sie Vorfallergebnisse in einem strukturierten Postmortem-Format.

Voraussetzungen

  • Google Cloud-Projekt mit aktivierter Abrechnungsfunktion
  • Befehlszeilentools: gcloud, kubectl, terraform.
  • Die Antigravity CLI ist lokal oder in Cloud Shell installiert.
  • Eine IDE (z.B. VS Code, IntelliJ, RubyMine oder Vim).

Warum SRE Extension + Agentic CLI?

Produktionsausfälle sind schnelllebig und erfordern eine Korrelation über mehrere Subsysteme hinweg (Kubernetes-Ressourcen, VPC-Netzwerke, Cloud Monitoring-Messwerte, IAM-Berechtigungen). Mit der SRE-Erweiterung können agentische CLI-Helfer (wie die Antigravity CLI) als autonome Copiloten fungieren, die vorkompilierte Playbooks ausführen, Überwachungsdiagramme abfragen und sichere Abhilfemaßnahmen vorschlagen, während der menschliche Bediener weiterhin eingebunden ist.

2. Einrichtung

Wählen Sie eine der folgenden Optionen aus: Einrichtung der Umgebung im eigenen Tempo, wenn Sie diese

Codelab auf Ihrem eigenen Computer ausführen oder Cloud Shell starten, wenn Sie dieses Codelab vollständig in der Cloud ausführen möchten.

Umgebung zum selbstbestimmten Lernen einrichten

  1. Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es handelt sich um einen String, der nicht von Google APIs verwendet wird. Sie können sie jederzeit aktualisieren.
  • Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich (kann nach dem Festlegen nicht mehr geändert werden). In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise ist es nicht wichtig, wie dieser String aussieht. In den meisten Codelabs müssen Sie auf Ihre Projekt-ID verweisen (in der Regel als PROJECT_ID angegeben). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige ID generieren. Alternativ können Sie einen eigenen Namen eingeben und prüfen, ob er verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
  • Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten
  1. Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs zu verwenden. Die Durchführung dieses Codelabs kostet wenig oder gar nichts. Wenn Sie Ressourcen herunterfahren möchten, um Kosten zu vermeiden, die über diese Anleitung hinausgehen, können Sie die erstellten Ressourcen oder das Projekt löschen. Neue Google Cloud-Nutzer können am kostenlosen Testzeitraum mit einem Guthaben von 300 $ teilnehmen.

Cloud Shell starten

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der Google Cloud Console rechts oben in der Symbolleiste auf das Cloud Shell-Symbol:

Cloud Shell aktivieren

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

Screenshot des Google Cloud Shell-Terminals, auf dem zu sehen ist, dass die Umgebung verbunden ist

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Alle Aufgaben in diesem Codelab können in einem Browser ausgeführt werden. Sie müssen nichts installieren.

3. Voraussetzungen (Installation)

Für diese Anleitung müssen Sie Folgendes installieren:

1. Python und uv

python und uv (Paketmanager für Python). Prüfen Sie, ob uv installiert ist:

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

Warum uv? Sie können zwar jeden beliebigen Python-Manager verwenden, aber mit uv wird sichergestellt, dass die ENV/PATH-Einrichtung für Python für Sie und für die Antigravity CLI gleich ist. Ihre Shell-Erfahrung ist also weitgehend dieselbe wie die der Antigravity CLI. Wenn Sie beispielsweise virtualenv verwenden, wird die Antigravity CLI gezwungen, Dinge wie „source .env/venv/bin/activate && my-original-command“ auszuführen, um Ihre Umgebung zu simulieren.

2. Antigravity CLI (agy)

Wenn Sie die offizielle Antigravity-CLI (den Befehl agy) installieren möchten, öffnen Sie das Terminal und führen Sie das Bootstrap-Installationsprogramm aus:

Für macOS und Linux:

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

Unter Windows (PowerShell):

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

Dieses Skript erkennt Ihr Betriebssystem und Ihre Architektur dynamisch und lädt die neueste kompilierte Version von

agy

-Binärdatei und konfigurieren Sie Ihren PATH. Starten Sie das Terminal neu oder laden Sie die Shell-Konfiguration neu, damit die Änderungen wirksam werden.

efade99623113f1.png

Authentifizierung

Sie benötigen entweder einen Google AI Studio-API-Schlüssel.

API-Schlüssel exportieren:

export GEMINI_API_KEY="your-api-key"

Mit gcloud authentifizieren:

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

Arbeitsumgebung einrichten und Mikrodienste-Demoanwendung bereitstellen

Wir klonen die Anwendung „microservices-demo“ und stellen die Infrastruktur und Anwendung über Terraform bereit.

Jetzt können Sie Ihre IDE (Visual Studio Code, IntelliJ, RubyMine usw.) öffnen und den Ordner öffnen.

# 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

Um die Einrichtung zu testen, können Sie auf http://[IP-ADRESSE] zugreifen und die Online-Boutique-App laden.

Arbeitsumgebung für sre-antigravity-cli-extension einrichten

# 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. Schritt 1: Ausfall simulieren (Szenarien für Unterbrechungen)

In diesem Schritt werden wir den bereitgestellten GKE-Cluster absichtlich beschädigen, um einen Produktionsvorfall in der Praxis zu simulieren. Sie haben drei Szenarien zur Auswahl (oder Sie können alle drei nacheinander ausprobieren):

Szenario 1: Blockierung des Checkout-Dienstnetzwerks (Standard/Autopilot)

In diesem Szenario wird eine unterbrochene Verbindung zwischen dem Frontend und dem Checkout-Dienst simuliert, indem ein Kubernetes-NetworkPolicy angewendet wird, das als Traffic-„Black Hole“ fungiert.

  1. Rufen Sie den Szenarioordner auf: 
    cd breakage1-checkout
  2. Lösen Sie das Problem aus: 
    ./break.sh
    Dadurch wird eine NetworkPolicy namens update-checkout-from-frontend im Namespace default erstellt, die eingehenden Traffic zu checkoutservice ablehnt, sofern er nicht von einem Pod mit dem Label app: frontend-checkout-test (das nicht vorhanden ist) stammt.
  3. Versuchen Sie, Artikel über das Frontend der Online-Boutique zu kaufen. Die Zahlungsseite reagiert nicht mehr oder es wird ein HTTP 500-Fehler angezeigt.

Szenario 2: Fehlerhafter Canary-Rollout (Autopilot mit Istio)

In diesem Szenario wird ein fehlerhaftes Deployment simuliert, bei dem eine fehlerhafte Version des Frontends über ein Kubernetes-Canary-Deployment bereitgestellt wird.

  1. Rufen Sie den Szenarioordner auf: 
    cd ../breakage2-canary
  2. Lösen Sie das Problem aus: 
    ./break.sh
    Dadurch wird eine Canary-Bereitstellung frontend-canary bereitgestellt, die einen Tippfehler in ihren Umgebungsvariablen enthält: PRODUCT_CATALOG_SERVICE_ADDR ist auf productcatalogservices:3550 anstelle von productcatalogservice:3550 konfiguriert.
  3. Laden Sie die Startseite des Frontends. Gelegentlich schlägt der Aufruf fehl (abhängig von den Routinggewichten), weil der Canary-Dienst den Produktkatalog nicht auflösen kann.

Szenario 3: Blockierung von VPC-Firewall-Clustern

In diesem Szenario wird ein Fehler in der VPC-Firewallkonfiguration simuliert, der den gesamten eingehenden Traffic zum GKE-Cluster blockiert.

  1. Rufen Sie den Szenarioordner auf: 
    cd ../breakage3-firewall
  2. Lösen Sie das Problem aus: 
    ./break.sh
    Dadurch wird eine Firewallregel auf VPC-Ebene mit dem Namen frontend-ingress-v2 mit priority=1 und der Aktion DENY erstellt, die auf eingehenden Traffic zu den Ports 80, 443 und 8080 ausgerichtet ist.
  3. Die Online-Boutique-Website ist dann nicht mehr erreichbar und Anfragen laufen in ein Zeitlimit.

5. Schritt 2: Ausfalluntersuchung mit der SRE-Erweiterung

Nachdem die Anwendung ausgefallen ist, beginnen wir mit der Untersuchung mithilfe Ihres CLI-Assistenten (Antigravity CLI).

  1. Kehren Sie zum Hauptordner für die Szenarien für Fehler zurück und starten Sie das CLI-Hilfsprogramm: 
    cd ..
agy
  2. Bitten Sie den Assistenten, eine Infrastrukturerkennung und eine Diagnoseprüfung durchzuführen: 
    Investigate my GKE cluster for outages. Are all services healthy?
  3. Was der KI-Agent tut
      :
    • Dadurch werden die Skills investigation-entrypoint und gcp-playbooks aktiviert.
    • Dort werden Kubernetes-Pods, -Bereitstellungen und -Dienste aufgeführt, um fehlerhafte Ziele zu finden.
    • Es werden Netzwerkrichtlinien (für Szenario 1), Bereitstellungskonfigurationen (für Szenario 2) oder Firewallregeln (für Szenario 3) geprüft.
  4. Im Szenario 1 sollte der Agent Folgendes melden: 🔴 Vorfall erkannt: Ein NetworkPolicy mit dem Namen update-checkout-from-frontend isoliert die checkoutservice-Pods.
  5. Im Fall 2 sollte der Kundenservicemitarbeiter Folgendes melden: 🔴 Vorfall erkannt: Die Bereitstellung frontend-canary ist mit einem ungültigen Dienstendpunkt productcatalogservices:3550 anstelle von productcatalogservice:3550 konfiguriert.
  6. Für Szenario 3 sollte der Kundenservicemitarbeiter Folgendes melden: 🔴 Vorfall erkannt: Eine VPC-Firewallregel frontend-ingress-v2 lehnt eingehenden Traffic an den Ports 80, 443 und 8080 ab.

6. Schritt 3: Ausfall beheben und eindämmen

Wir verwenden das Safe Executor-Muster der CLI, um die Störung zu beheben.

  1. Bitten Sie Ihren CLI-Assistenten, eine Korrektur vorzuschlagen und anzuwenden: 
    Propose a fix for the outage and apply it.
  2. Safe Executor in Aktion:
    • Bevor Befehlsvorschläge ausgeführt werden, führt die SRE Extension mit dem safe-sre-investigator-Skill eine Sicherheitsprüfung durch.
    • Sie sehen den genauen Befehl, der ausgeführt werden soll, und die Risikobewertung (z.B. niedrig, mittel, hoch).
    • Für Szenario 1 wird Folgendes vorgeschlagen: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • Für Szenario 2 wird Folgendes vorgeschlagen: 
      kubectl delete deployment frontend-canary
    • Für Szenario 3 wird Folgendes vorgeschlagen: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. Bestätigen Sie die Ausführung des Befehls, wenn Sie von der Befehlszeile dazu aufgefordert werden.
  4. Prüfen Sie, ob die Website wieder verfügbar und voll funktionsfähig ist, indem Sie die Startseite von Online Boutique aktualisieren.
  5. In Ihrer Shell können Sie das entsprechende Szenarioprüfskript ausführen, um den Zustand zu prüfen: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. Schritt 4: Erstellen des Incident Post Mortem

Ein wesentlicher Bestandteil des SRE-Lebenszyklus ist die Dokumentation des Vorfalls, damit das Team daraus lernen kann. Lass uns das mit dem postmortem-create-Skill automatisieren.

  1. Bitten Sie Ihren CLI-Assistenten, das Post-Mortem-Dokument zu schreiben: 
    Create a postmortem for the checkout service network policy outage.
  2. Der Kundenservicemitarbeiter erfasst Details zu:
    • Die Startzeit des Vorfalls (aus dem Verlauf/den Logs Ihres CLI-Befehls).
    • Die Grundursache (die blockierende NetworkPolicy).
    • Die Maßnahmen, die zur Eindämmung ergriffen wurden.
  3. Es wird eine neue Markdown-Datei mit dem Namen postmortem.md in Ihrem Arbeitsbereich erstellt.
  4. Öffnen Sie postmortem.md, um sich die Details anzusehen. Es werden Bereiche wie
      angezeigt.
    • Übersicht der Vorfälle
    • Zeitlicher Ablauf der Ereignisse
    • Ursachenanalyse (Root Cause Analysis, RCA)
    • Maßnahmen / Vorbeugende Maßnahmen

8. Schritt 5: Diagramme mit fundierten Messwerten hinzufügen

Damit die Post-Mortem-Analyse professionell ist, benötigen wir einen visuellen Nachweis des Vorfalls. Wir verwenden den monitoring-graphs-Skill, um Zeitreihendaten aus Google Cloud Monitoring (GCM) abzurufen und ein PNG-Diagramm mit dem Fehleranstieg zu generieren.

  1. Bitten Sie Ihren CLI-Helfer, das Diagramm zu erstellen und in den Postmortem-Bericht einzufügen: 
    Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md.
  2. Details
    • Der Agent ruft das Python-Skript monitoring-graphs auf, um Cloud Monitoring abzufragen.
    • Damit werden Messwerte abgerufen, z.B. kubernetes.io/container/restart_count oder loadbalancing.googleapis.com/https/request_count.
    • Das Diagramm wird mit matplotlib gezeichnet und als incident_metrics.png gespeichert.
    • Dadurch wird die Datei postmortem.md aktualisiert, indem ein Bildlink eingefügt wird: 
      ![Incident Metric Graph](incident_metrics.png)
  3. Öffnen Sie die generierte Datei incident_metrics.png, um das Diagramm mit den genauen Zeitpunkten zu sehen, an denen der Cluster ausgefallen ist und der Traffic wieder normal war.

9. Schritt 6: Bereinigung

Damit für Ihr Google Cloud-Konto keine unnötigen Gebühren anfallen, bereinigen wir die bereitgestellte Infrastruktur.

  1. Rufen Sie den Terraform-Ordner auf: 
    cd ../../microservices-demo/terraform
  2. Führen Sie den Befehl „destroy“ aus: 
    terraform destroy -auto-approve
  3. Prüfen Sie, ob alle GCP GKE-Ressourcen erfolgreich gelöscht wurden.

10. Glückwunsch!

Sie haben das Codelab „GKE-Cluster-Fehler und ‑Ausfälle untersuchen“ abgeschlossen.

Behandelte Themen:

  • Sie haben die 10-schichtige Mikrodienst-Demoanwendung „Online Boutique“ in GKE bereitgestellt.
  • Es wurden drei SRE-Ausfälle in der Praxis simuliert (Ablehnung von Netzwerkrichtlinien, fehlerhafter Canary-Rollout, Ablehnung von VPC-Firewallregeln).
  • Die SRE-Erweiterung für die Antigravity CLI wurde verwendet, um die Ausfälle zu erkennen und zu diagnostizieren.
  • Das Safe Executor-Muster wurde verwendet, um Korrekturbefehle zu prüfen und auszuführen.
  • Er hat eine professionelle Markdown-Analyse erstellt.
  • Abgefragte Cloud Monitoring-Messwerte, um automatisch ein fundiertes Vorfall-Diagramm zu generieren und einzubetten.

Weitere Informationen zum Erweitern Ihres CLI-Agents finden Sie auf der GitHub-Seite zur SRE-Erweiterung.