Enquêter sur une panne GKE avec l'extension Antigravity CLI et SRE, et créer un post-mortem esthétique

1. Introduction

Dernière mise à jour : 13/05/2026

Enquêter sur une panne GKE avec l'extension SRE et créer un post-mortem esthétique

Bienvenue dans cet atelier SRE, destiné aux opérateurs qui souhaitent expérimenter les harnais SRE sur Google Cloud.

Cet atelier de programmation vous guidera à travers les étapes suivantes :

1. Installez un cluster GKE basé sur une démonstration de microservices Open Source bien connue.
2. Créez une panne en la simulant de différentes manières (certaines plus frappantes, d'autres plus subtiles).
3. Installez et utilisez l'interface de ligne de commande Antigravity (ou un harnais similaire) + l'extension SRE pour la partie suivante.
4. Enquêter sur la panne et, si possible, la résoudre.
5. Créez un post-mortem.
6. Utilisez vos compétences en matière de graphiques pour générer un graphique ancré qui permet aux spectateurs de comprendre ce qui s'est passé et quand.

Voici la structure détaillée de l'atelier de programmation :

L'objectif de cet atelier est de :

1. démontrer les capacités de l'extension SRE et vous montrer ce qu'il est possible de faire avec elle : configuration OneMCP, Safe Executor, investigation, génération de post-mortem, graphiques et extraits CSV.
2. Vous apprendrez à examiner votre propre scénario Google Cloud.

Remarque (*) : Bien que l'atelier de programmation suppose que vous utilisez Antigravity CLI, vous pouvez en fait utiliser n'importe quel autre harnais, comme Claude Code. N'hésitez pas à nous faire part de vos impressions en cliquant sur le lien de commentaires ci-dessous.

Étape 1 : Configuration de l'environnement et simulation d'une panne

L'objectif de cette étape est de configurer une application de démonstration Kubernetes sur GKE Autopilot, d'installer l'interface de ligne de commande Antigravity et de déclencher artificiellement des scénarios de défaillance de cluster GKE pour simuler des incidents de production.

Étape 2 : Enquête et atténuation avec l'extension SRE

Après avoir cassé l'environnement, vous utiliserez des outils CLI agentiques équipés de l'extension SRE pour découvrir systématiquement l'infrastructure, trier les problèmes, implémenter le modèle d'exécution sécurisé pour les correctifs et vérifier l'état du cluster.

Étape 3 : Post-mortem et génération de graphiques

Une fois le problème résolu, vous générerez un document post-mortem structuré sur l'incident et utiliserez les API GCM (Google Cloud Monitoring) pour extraire des données métriques réelles, en créant des graphiques visuels pour documenter quand et comment la panne s'est produite.

Objectifs de l'atelier

Dans cet atelier de programmation, vous allez examiner et corriger les pannes GKE à l'aide de l'extension SRE. Vous découvrirez comment :

• Simulez une panne GKE à l'aide du blocage des règles de réseau, des déploiements canary défectueux et des mises à jour des règles de pare-feu.
• Triez la panne du cluster à l'aide d'un assistant CLI optimisé par l'extension SRE.
• Implémentez les étapes de correction de manière sécurisée à l'aide du modèle Safe Executor.
• Générez un document post-mortem complet.
• Représentez graphiquement les métriques des incidents à l'aide des requêtes de séries temporelles Google Cloud Monitoring.

Points abordés

• Comment inspecter les ressources et les règles Kubernetes GKE à l'aide des compétences de l'extension SRE.
• Comment tirer parti du modèle Safe Executor pour exécuter les commandes suggérées par l'agent avec une évaluation des risques appropriée.
• Découvrez comment utiliser la compétence monitoring-graphs pour générer des graphiques ancrés de métriques directement depuis GCM.
• Documenter les conclusions d'un incident dans un format post-mortem structuré.

Prérequis

• Projet Google Cloud avec facturation activée
• Outils de ligne de commande : gcloud, kubectl, terraform.
• CLI Antigravity installée en local ou dans Cloud Shell.
• Un IDE (par exemple, vscode, IntelliJ, RubyMine ou Vim).

Pourquoi utiliser l'extension SRE et la CLI agentique ?

Les pannes de production sont rapides et nécessitent une corrélation entre plusieurs sous-systèmes (ressources Kubernetes, réseaux VPC, métriques Cloud Monitoring, autorisations IAM). L'extension SRE permet aux assistants CLI agentiques (comme Antigravity CLI) d'agir en tant que copilotes autonomes, en exécutant des playbooks précompilés, en interrogeant des graphiques de surveillance et en suggérant des corrections sûres tout en gardant l'opérateur humain dans la boucle.

Remarque sur la compatibilité : L'extension SRE a été initialement développée en tant qu'extension Gemini CLI, mais elle est structurée à l'aide de modèles standards et peut être importée en tant que plug-in pour n'importe quel harnais agentique moderne (tel qu'Antigravity CLI (agy), Claude Code ou Codex).

Si vous ne souhaitez pas utiliser la CLI Antigravity, cette extension devrait fonctionner parfaitement avec Claude Code et tout harnais similaire compatible avec les plug-ins (pour en savoir plus, consultez les spécifications des plug-ins).

2. Configuration

Pour les crédits Google Cloud : pour vous aider à vous lancer, utilisez ce lien ( instructions) pour profiter de vos crédits Google Cloud sans frais.

Choisissez l'une des options suivantes : Configuration de l'environnement à votre rythme si vous souhaitez exécuter cette

l'atelier de programmation sur votre propre machine, ou démarrer Cloud Shell si vous souhaitez exécuter cet atelier de programmation entièrement dans le cloud.

Configuration de l'environnement au rythme de chacun

1. Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

• Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pourrez toujours le modifier.
• L'ID du projet est unique parmi tous les projets Google Cloud et non modifiable une fois défini. La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
• Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.

Attention : Un ID de projet est unique. Une fois que vous l'avez choisi, personne d'autre ne peut l'employer. Vous en êtes le seul utilisateur. Même si un projet est supprimé, son ID ne peut pas être réutilisé.

Remarque : Si vous utilisez un compte Gmail, vous pouvez conserver l'emplacement par défaut défini sur Aucune organisation. Si vous utilisez un compte Google Workspace, choisissez un emplacement qui ait du sens pour votre organisation.

2. Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300 $.

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Dans la console Google Cloud, cliquez sur l'icône Cloud Shell dans la barre d'outils supérieure :

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez effectuer toutes les tâches de cet atelier de programmation dans un navigateur. Vous n'avez rien à installer.

3. Conditions préalables (installation)

Remarque : Si vous décidez d'exécuter cet atelier de programmation sur Cloud Shell, Python, uv et l'interface de ligne de commande Antigravity (antigravity) sont déjà préinstallés.

Pour ce tutoriel, vous devez installer :

1. Python et uv

python et uv (gestionnaire de paquets pour Python). Assurez-vous que uv est installé :

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

Pourquoi uv ? Bien que vous puissiez utiliser le gestionnaire Python de votre choix, l'utilisation de uv garantira que la configuration ENV/PATH pour Python sera la même pour vous et pour l'interface de ligne de commande Antigravity. Votre expérience shell sera donc en grande partie la même que celle de l'interface de ligne de commande Antigravity. Si vous utilisez virtualenv , par exemple, l'interface de ligne de commande Antigravity sera forcée d'effectuer des actions telles que "source .env/venv/bin/activate && my-original-command" pour imiter votre environnement.

2. CLI Antigravity (agy)

Pour installer la CLI Antigravity officielle (commande agy), ouvrez votre terminal et exécutez le programme d'installation bootstrap :

Pour macOS et Linux :

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

Pour Windows (PowerShell) :

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

Ce script détecte de manière dynamique votre système d'exploitation et votre architecture, puis télécharge la dernière version compilée.

agy

et configurez votre variable PATH. Redémarrez votre terminal ou rechargez la configuration de votre shell pour que les modifications prennent effet.

Authentification

Vous devez disposer d'une clé API Google AI Studio.

Exportez votre clé API :

export GEMINI_API_KEY="your-api-key"

Authentifiez-vous avec gcloud :

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

Configurer votre environnement de travail et déployer l'application de démonstration des microservices

Clonons l'application de démonstration des microservices et déployons l'infrastructure et l'application via Terraform.

C'est le moment d'ouvrir votre IDE (Visual Studio Code, IntelliJ, RubyMine, etc.) et d'ouvrir le dossier.

# 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

Pour tester votre configuration, vous pouvez accéder à http://[ADRESSE IP] et charger l'application Online Boutique.

Configurer votre environnement de travail pour l'extension sre-antigravity-cli

# 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 [e-mail]

Important : Assurez-vous d'exécuter Antigravity CLI depuis le dossier 📁 sre-testing-suite/test-scenarios/microservices-demo-gke/breakage-scenarios/ (remarque : dans certains clones plus anciens du dépôt, ce répertoire peut être nommé breakage-scnearios en raison d'une faute de frappe). L'IDE devrait également l'afficher comme nom racine. Cela permet de s'assurer que l'interface de ligne de commande Antigravity sélectionne la bonne configuration.

4. Étape 1 : Simuler l'indisponibilité (scénarios de défaillance)

Au cours de cette étape, nous allons intentionnellement endommager le cluster GKE déployé pour simuler un incident de production réel. Vous avez le choix entre trois scénarios (ou vous pouvez les essayer tous les trois les uns après les autres) :

Scénario 1 : Blocage du réseau du service de paiement (standard/autopilote)

Ce scénario simule une connexion interrompue entre le frontend et le service de paiement en appliquant un NetworkPolicy Kubernetes qui agit comme un "trou noir" de trafic.

1. Accédez au dossier du scénario :

   cd breakage1-checkout
   

2. Déclenchez la défaillance :

   ./break.sh
   

   Cette commande crée un objet NetworkPolicy nommé update-checkout-from-frontend dans l'espace de noms default, qui refuse le trafic entrant vers checkoutservice, sauf s'il provient d'un pod portant le libellé app: frontend-checkout-test (qui n'existe pas).
3. Essayez d'acheter des articles sur l'interface utilisateur de la boutique en ligne. La page de paiement se bloque ou affiche une erreur HTTP 500.

Scénario 2 : Déploiement Canary bogué (autopilote avec Istio)

Ce scénario simule un mauvais déploiement dans lequel une version boguée du frontend est déployée via un déploiement Canary Kubernetes.

1. Accédez au dossier du scénario :

   cd ../breakage2-canary
   

2. Déclenchez la défaillance :

   ./break.sh
   

   Cette commande déploie un déploiement Canary frontend-canary qui contient une faute de frappe dans ses variables d'environnement : PRODUCT_CATALOG_SERVICE_ADDR est configuré sur productcatalogservices:3550 au lieu de productcatalogservice:3550.
3. Chargez la page d'accueil de l'interface. Il échouera parfois (en fonction des pondérations de routage), car le service canary ne parvient pas à résoudre le catalogue de produits.

Scénario 3 : Blocage du cluster de pare-feu VPC

Ce scénario simule une erreur de configuration du pare-feu VPC qui bloque tout le trafic entrant vers le cluster GKE.

1. Accédez au dossier du scénario :

   cd ../breakage3-firewall
   

2. Déclenchez la défaillance :

   ./break.sh
   

   Cette commande crée une règle de pare-feu au niveau du VPC nommée frontend-ingress-v2 avec priority=1 et l'action DENY ciblant le trafic entrant vers les ports 80, 443 et 8080.
3. Le site Web de la boutique en ligne deviendra complètement inaccessible et les requêtes expireront.

5. Étape 2 : Enquêter sur une panne avec l'extension SRE

Maintenant que l'application est hors service, commençons l'enquête à l'aide de votre assistant CLI (Antigravity CLI).

1. Revenez au dossier principal des scénarios de rupture et lancez votre outil d'assistance CLI :

   cd ..
   agy
   

2. Demandez à l'assistant d'effectuer une découverte de l'infrastructure et un diagnostic :

   Investigate my GKE cluster for outages. Are all services healthy?
   

3. Ce que fait l'agent :
   • Elle active les skills investigation-entrypoint et gcp-playbooks.
   • Il liste les pods, les déploiements et les services Kubernetes pour localiser les cibles en échec.
   • Il inspecte les règles de réseau (pour le scénario 1), les configurations de déploiement (pour le scénario 2) ou les règles de pare-feu (pour le scénario 3).
4. Dans le scénario 1, l'agent doit signaler : 🔴 Incident identifié : un NetworkPolicy nommé update-checkout-from-frontend isole les pods checkoutservice.
5. Pour le scénario 2, l'agent doit signaler : 🔴 Incident identifié : le déploiement frontend-canary est configuré avec un point de terminaison de service non valide productcatalogservices:3550 au lieu de productcatalogservice:3550.
6. Pour le scénario 3, l'agent doit indiquer : 🔴 Incident identifié : une règle de pare-feu VPC frontend-ingress-v2 refuse le trafic entrant sur les ports 80, 443 et 8080.

6. Étape 3 : Atténuer et résoudre l'indisponibilité

Utilisons le modèle Safe Executor de la CLI pour résoudre l'indisponibilité.

1. Demandez à votre assistant CLI de proposer et d'appliquer une correction :

   Propose a fix for the outage and apply it.
   

2. Safe Executor en action :
   • Avant d'exécuter les suggestions de commandes, l'extension SRE effectue un audit de sécurité à l'aide de la compétence safe-sre-investigator.
   • Il vous indiquera la commande exacte qu'il compte exécuter et évaluera le risque (par exemple, faible, moyen ou élevé).
   • Pour le scénario 1, il proposera :

     kubectl delete networkpolicy update-checkout-from-frontend
     

   • Pour le scénario 2, il proposera :

     kubectl delete deployment frontend-canary
     

   • Pour le scénario 3, il proposera :

     gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
     

3. Confirmez l'exécution de la commande lorsque vous y êtes invité par la CLI.
4. Actualisez la page d'accueil d'Online Boutique pour vérifier que le site Web est de nouveau opérationnel et entièrement fonctionnel.
5. Dans votre shell, vous pouvez exécuter le script de vérification du scénario correspondant pour vérifier l'état :

   ./breakage1-checkout/check.sh
   # or ./breakage2-canary/check.sh
   # or ./breakage3-firewall/check.sh
   

7. Étape 4 : Générer l'analyse post-mortem de l'incident

La documentation de l'incident est une étape essentielle du cycle de vie SRE, car elle permet à l'équipe d'en tirer des enseignements. Nous allons automatiser cela à l'aide de la compétence postmortem-create.

1. Dans votre assistant CLI, demandez à rédiger le document post-mortem :

   Create a postmortem for the checkout service network policy outage.
   

2. L'agent vous demandera des informations sur les points suivants :
   • Heure de début de l'incident (récupérée à partir de l'historique/des journaux de commandes CLI).
   • La cause racine (la NetworkPolicy bloquante).
   • les mesures prises pour l'atténuer.
3. Il écrira un nouveau fichier Markdown nommé postmortem.md dans votre espace de travail.
4. Ouvrez postmortem.md pour examiner les détails. Vous verrez des sections telles que :
   • Récapitulatif de l'incident
   • Chronologie des événements
   • Analyse des causes fondamentales
   • Mesures à prendre / Mesures préventives

8. Étape 5 : Ajouter des graphiques de métriques ancrées

Pour que le post-mortem soit professionnel, nous avons besoin d'une preuve visuelle de l'incident. Nous allons utiliser la compétence monitoring-graphs pour extraire les données de série temporelle de Google Cloud Monitoring (GCM) et générer un graphique PNG montrant le pic d'erreurs.

1. Demandez à votre assistant CLI de générer le graphique et de l'ajouter au 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. Sous le capot
   :
   • L'agent appelle le script Python monitoring-graphs pour interroger Cloud Monitoring.
   • Il récupère des métriques (par exemple, kubernetes.io/container/restart_count ou loadbalancing.googleapis.com/https/request_count).
   • Il représente le graphique à l'aide de matplotlib et l'enregistre sous le nom incident_metrics.png.
   • Il met à jour le fichier postmortem.md en insérant un lien d'image :

     ![Incident Metric Graph](incident_metrics.png)
     

3. Ouvrez le fichier incident_metrics.png généré pour afficher le graphique illustrant les moments exacts où le cluster a été mis hors service et où le trafic est revenu à la normale.

9. Étape 6 : Effectuer un nettoyage

Pour éviter que des frais inutiles ne soient facturés sur votre compte Google Cloud, nettoyons l'infrastructure déployée.

1. Accédez au dossier Terraform :

   cd ../../microservices-demo/terraform
   

2. Exécutez la commande de suppression :

   terraform destroy -auto-approve
   

3. Vérifiez que toutes les ressources GKE GCP ont bien été supprimées.

10. Félicitations !

Vous avez terminé l'atelier de programmation sur l'étude des pannes et des dysfonctionnements des clusters GKE.

Points abordés :

• Déployez la démo de microservices Online Boutique à 10 niveaux sur GKE.
• Nous avons simulé trois pannes SRE réelles (refus de stratégie réseau, déploiement canary bogué, refus de règle de pare-feu VPC).
• Utiliser l'extension SRE pour Antigravity CLI afin de découvrir et de diagnostiquer les pannes
• Utilisation du modèle Safe Executor pour examiner et exécuter les commandes de correction.
• Créer un post-mortem Markdown professionnel.
• Métriques Cloud Monitoring interrogées pour générer et intégrer automatiquement un graphique d'incidents ancré.

Pour en savoir plus sur l'extension de votre agent CLI, consultez la page GitHub de l'extension SRE.