Investiga una interrupción de GKE con la CLI de Antigravity y la extensión de SRE, y crea un informe post mortem atractivo

1. Introducción

856ff52e60953a92.png

Última actualización: 13/05/2026

Investiga una interrupción de GKE con la extensión de SRE y crea un informe post mortem atractivo

Te damos la bienvenida a este taller de SRE, dirigido a operadores que desean experimentar con arneses de SRE en Google Cloud.

En este codelab, se te guiará por el proceso:

  1. Instalar un clúster de GKE basado en una demostración de microservicios de código abierto y conocida
  2. Crea una interrupción de diferentes maneras (algunas más llamativas, otras más sutiles).
  3. Instala y usa la CLI de Antigravity (o un arnés similar) y la extensión de SRE para la siguiente parte.
  4. Investigar y, con suerte, solucionar la interrupción
  5. Crea un informe a posteriori.
  6. Usa las habilidades de generación de gráficos para crear un gráfico fundamentado que permita a los usuarios comprender qué sucedió y cuándo.

Esta es la estructura paso a paso del codelab:

Diagrama de estructura del codelab

El objetivo de este taller es el siguiente:

  1. Demostrar las capacidades de la extensión de SRE y mostrarte lo que puedes hacer con ella: configuración de OneMCP, Safe Executor, investigación, generación de análisis post mortem, gráficos y fragmentos de CSV
  2. Enseñarte las habilidades necesarias para investigar tu propio caso de Google Cloud

Hito 1: Configuración del entorno y simulación de interrupciones

El objetivo de este hito es configurar una aplicación de demostración de Kubernetes en GKE Autopilot, instalar la CLI de Antigravity y activar de forma artificial situaciones de falla del clúster de GKE para simular incidentes de producción.

Hito 2: Investigación y mitigación con la extensión de SRE

Después de interrumpir el entorno, usarás herramientas de la CLI basadas en agentes equipadas con la extensión de SRE para descubrir sistemáticamente la infraestructura, priorizar los problemas, implementar el patrón de ejecución seguro para las correcciones y verificar el estado del clúster.

Hito 3: Análisis posterior y generación de gráficos

Una vez que se resuelva, generarás un documento estructurado de análisis posterior del incidente y usarás las APIs de GCM (Google Cloud Monitoring) para extraer datos de métricas reales y crear gráficos visuales para documentar cuándo y cómo ocurrió la interrupción.

Qué compilarás

En este codelab, investigarás y corregirás las interrupciones de GKE con la extensión de SRE. Harás lo siguiente:

  • Simula una interrupción de GKE con el bloqueo de políticas de red, implementaciones canary con errores y actualizaciones de reglas de firewall.
  • Clasifica la interrupción del clúster con un asistente de CLI potenciado por la extensión de SRE.
  • Implementa los pasos de corrección de forma segura con el patrón Safe Executor.
  • Genera un documento a posteriori integral.
  • Genera gráficos de las métricas de incidentes con consultas de series temporales de Google Cloud Monitoring.

Qué aprenderás

  • Cómo inspeccionar los recursos y las políticas de Kubernetes de GKE con las habilidades de la extensión de SRE
  • Cómo aprovechar el patrón Safe Executor para ejecutar comandos sugeridos por el agente con una evaluación de riesgos adecuada
  • Cómo usar la habilidad monitoring-graphs para generar gráficos fundamentados de métricas directamente desde GCM
  • Cómo documentar los hallazgos de incidentes en un formato post mortem estructurado

Requisitos

  • Un proyecto de Google Cloud con facturación habilitada
  • Herramientas de línea de comandos: gcloud, kubectl y terraform.
  • La CLI de Antigravity instalada de forma local o en Cloud Shell
  • Un IDE (p. ej., VS Code, IntelliJ, RubyMine o Vim)

¿Por qué usar la extensión de SRE y la CLI de agentes?

Las interrupciones de producción son rápidas y requieren correlación en varios subsistemas (recursos de Kubernetes, redes de VPC, métricas de Cloud Monitoring, permisos de IAM). La extensión de SRE permite que los asistentes de la CLI basados en agentes (como la CLI de Antigravity) actúen como copilotos autónomos, ejecuten guías precompiladas, consulten gráficos de supervisión y sugieran correcciones seguras, mientras mantienen al operador humano en el circuito.

2. Cómo prepararte

Elige una de las siguientes opciones: Configuración del entorno a tu propio ritmo si deseas ejecutar este

codelab en tu propia máquina, o inicia Cloud Shell si deseas ejecutar este codelab por completo en la nube.

Configuración del entorno de autoaprendizaje

  1. Accede a consola de Google Cloud y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla cuando quieras.
  • El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID de tu proyecto (suele identificarse como PROJECT_ID). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se usa el mismo durante todo el proyecto.
  • Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.
  1. A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no costará mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de $300.

Inicia Cloud Shell

Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

En Google Cloud Console, haz clic en el ícono de Cloud Shell en la barra de herramientas en la parte superior derecha:

Activar Cloud Shell

El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:

Captura de pantalla de la terminal de Google Cloud Shell que muestra que el entorno se conectó

Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Todo tu trabajo en este codelab se puede hacer en un navegador. No es necesario que instales nada.

3. Requisitos previos (instalación)

Para este instructivo, debes instalar lo siguiente:

1. Python y uv

python y uv (administrador de paquetes para Python). Asegúrate de tener instalado uv:

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

¿Por qué UV? Si bien puedes usar el administrador de Python que prefieras, usar uv garantizará que la configuración de ENV/PATH para Python sea igual para ti y para la CLI de Antigravity, por lo que tu experiencia de shell será casi la misma que la de la CLI de Antigravity. Si usas virtualenv , por ejemplo, Antigravity CLI se verá obligada a hacer cosas como "source .env/venv/bin/activate && my-original-command" para imitar tu entorno.

2. CLI de Antigravity (agy)

Para instalar la CLI oficial de Antigravity (el comando agy), abre la terminal y ejecuta el instalador de arranque:

Para macOS y Linux:

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

Para Windows (PowerShell):

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

Esta secuencia de comandos detectará de forma dinámica tu SO y arquitectura, y descargará la versión compilada más reciente de

agy

binario y configura tu PATH. Reinicia tu terminal o vuelve a cargar la configuración del shell para que los cambios tengan efecto.

efade99623113f1.png

Autenticación

Necesitas una clave de API de Google AI Studio.

Sigue estos pasos para exportar tu clave de API:

export GEMINI_API_KEY="your-api-key"

Autentícate con gcloud:

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

Configura tu entorno de trabajo e implementa la aplicación de demostración de microservicios

Clonemos la aplicación de demostración de microservicios y, luego, implementemos la infraestructura y la aplicación a través de Terraform.

Este es el momento en el que puedes abrir tu IDE (Visual Studio Code, IntelliJ, RubyMine, etc.) y abrir la carpeta.

# 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

Para probar tu configuración, puedes acceder a http://[DIRECCIÓN IP] y cargar la app de Online Boutique.

Configura tu entorno de trabajo para 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. Paso 1: Simula la interrupción (situaciones de falla)

En este paso, interrumpiremos intencionalmente el clúster de GKE implementado para simular un incidente de producción del mundo real. Tienes tres situaciones para elegir (o puedes probar las tres de forma secuencial):

Situación 1: Bloqueo de la red del servicio de confirmación de compra (estándar o piloto automático)

En este caso, se simula una conexión interrumpida entre el frontend y el servicio de confirmación de compra aplicando un NetworkPolicy de Kubernetes que actúa como un "agujero negro" de tráfico.

  1. Navega a la carpeta de la situación: 
    cd breakage1-checkout
  2. Activa la falla: 
    ./break.sh
    Esto crea una NetworkPolicy llamada update-checkout-from-frontend en el espacio de nombres default que rechaza el tráfico de entrada a checkoutservice, a menos que provenga de un Pod con la etiqueta app: frontend-checkout-test (que no existe).
  3. Intenta comprar artículos en el frontend de Online Boutique. La página de confirmación de compra se bloqueará o mostrará un error HTTP 500.

Situación 2: Lanzamiento de versión Canary con errores (piloto automático con Istio)

En este caso, se simula una implementación incorrecta en la que se lanza una versión con errores del frontend a través de una implementación de versiones canary de Kubernetes.

  1. Navega a la carpeta de la situación: 
    cd ../breakage2-canary
  2. Activa la falla: 
    ./break.sh
    Esto implementa una implementación de versiones canary frontend-canary que tiene un error tipográfico en sus variables de entorno: PRODUCT_CATALOG_SERVICE_ADDR está configurado como productcatalogservices:3550 en lugar de productcatalogservice:3550.
  3. Carga la página principal del frontend. En ocasiones, fallará (según los pesos de enrutamiento) porque el servicio canary no puede resolver el catálogo de productos.

Situación 3: Bloqueo del clúster del firewall de VPC

En este caso, se simula un error en la configuración del firewall de VPC que bloquea todo el tráfico de entrada al clúster de GKE.

  1. Navega a la carpeta de la situación: 
    cd ../breakage3-firewall
  2. Activa la falla: 
    ./break.sh
    Esto crea una regla de firewall a nivel de la VPC llamada frontend-ingress-v2 con priority=1 y la acción DENY que segmenta el tráfico de entrada para los puertos 80, 443 y 8080.
  3. El sitio web de Online Boutique dejará de estar disponible por completo y las solicitudes agotarán el tiempo de espera.

5. Paso 2: Investigación de la interrupción con la extensión de SRE

Ahora que la aplicación no funciona, comencemos la investigación con tu asistente de la CLI (CLI de Antigravity).

  1. Regresa a la carpeta principal de situaciones de interrupción y ejecuta el asistente de la CLI: 
    cd ..
agy
  2. Pídele al asistente que realice una detección de infraestructura y una verificación de diagnóstico: 
    Investigate my GKE cluster for outages. Are all services healthy?
  3. Qué hace el agente:
    • Activa las habilidades de investigation-entrypoint y gcp-playbooks.
    • Enumera los pods, las implementaciones y los servicios de Kubernetes para ubicar los destinos con errores.
    • Inspecciona las políticas de red (para el caso 1), los parámetros de configuración de implementación (para el caso 2) o las reglas de firewall (para el caso 3).
  4. En el caso del escenario 1, el agente debe informar lo siguiente: 🔴 Se identificó un incidente: Un NetworkPolicy llamado update-checkout-from-frontend está aislando los pods de checkoutservice.
  5. En la situación 2, el agente debe informar lo siguiente: 🔴 Se identificó el incidente: La implementación frontend-canary está configurada con un extremo de servicio no válido productcatalogservices:3550 en lugar de productcatalogservice:3550.
  6. En el caso del escenario 3, el agente debe informar lo siguiente: 🔴 Se identificó un incidente: Una regla de firewall de VPC frontend-ingress-v2 está rechazando el tráfico de entrada en los puertos 80, 443 y 8080.

6. Paso 3: Mitigación y corrección de la interrupción

Usemos el patrón Safe Executor de la CLI para solucionar la interrupción.

  1. Pídele a tu asistente de la CLI que proponga y aplique una corrección: 
    Propose a fix for the outage and apply it.
  2. Safe Executor in Action:
    • Antes de ejecutar sugerencias de comandos, la extensión de SRE ejecuta una auditoría de seguridad con la habilidad safe-sre-investigator.
    • Te mostrará el comando exacto que pretende ejecutar y calificará el riesgo (p.ej., bajo, medio o alto).
    • En el caso de la situación 1, se propondrá lo siguiente: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • En el caso 2, se propondrá lo siguiente: 
      kubectl delete deployment frontend-canary
    • En el caso de la situación 3, se propondrá lo siguiente: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. Confirma la ejecución del comando cuando te lo solicite la CLI.
  4. Para verificar que el sitio web esté en funcionamiento y sea completamente funcional, actualiza la página principal de Online Boutique.
  5. En tu shell, puedes ejecutar la secuencia de comandos de verificación del escenario correspondiente para verificar el estado: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. Paso 4: Genera el informe post mortem del incidente

Una parte esencial del ciclo de vida de la SRE es documentar el incidente para que el equipo pueda aprender de él. Automatizaremos este proceso con la habilidad postmortem-create.

  1. En tu asistente de la CLI, pídele que escriba el documento de análisis posterior al incidente: 
    Create a postmortem for the checkout service network policy outage.
  2. El agente recopilará detalles sobre lo siguiente:
    • Hora de inicio del incidente (recuperada del historial o los registros de comandos de la CLI)
    • La causa raíz (la NetworkPolicy de bloqueo).
    • Las medidas que se tomaron para mitigar el problema
  3. Se escribirá un nuevo archivo Markdown llamado postmortem.md en tu espacio de trabajo.
  4. Abre postmortem.md para revisar los detalles. Verás secciones como las siguientes:
    • Resumen del incidente
    • Cronograma de eventos
    • Análisis de causa raíz (RCA)
    • Elementos de acción y medidas preventivas

8. Paso 5: Agrega gráficos de métricas fundamentadas

Para que el análisis post mortem sea profesional, necesitamos pruebas visuales del incidente. Usaremos la habilidad monitoring-graphs para recuperar datos de series temporales de Google Cloud Monitoring (GCM) y generar un gráfico en PNG que muestre el aumento repentino de errores.

  1. Pídele a tu asistente de la CLI que genere el gráfico y lo agregue al informe 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. Detrás de escena:
    • El agente llama a la secuencia de comandos de Python monitoring-graphs para consultar Cloud Monitoring.
    • Recupera métricas (p.ej., kubernetes.io/container/restart_count o loadbalancing.googleapis.com/https/request_count).
    • Traza el gráfico con matplotlib y lo guarda como incident_metrics.png.
    • Actualiza el archivo postmortem.md insertando un vínculo de imagen: 
      ![Incident Metric Graph](incident_metrics.png)
  3. Abre el archivo incident_metrics.png generado para ver el gráfico que ilustra los momentos exactos en los que el clúster dejó de funcionar y cuando el tráfico volvió a la normalidad.

9. Paso 6: Limpieza

Para asegurarnos de que tu cuenta de Google Cloud no incurra en cargos innecesarios, limpiemos la infraestructura implementada.

  1. Navega a la carpeta de Terraform: 
    cd ../../microservices-demo/terraform
  2. Ejecuta el comando destroy: 
    terraform destroy -auto-approve
  3. Verifica que todos los recursos de GKE de GCP se hayan borrado correctamente.

10. ¡Felicitaciones!

Completaste el codelab de investigación de interrupciones y fallas del clúster de GKE.

Temas abordados:

  • Implementaste la demostración de microservicios de Online Boutique de 10 niveles en GKE.
  • Se simularon tres interrupciones de SRE del mundo real (rechazo de política de red, lanzamiento de versión canary con errores y rechazo de regla de firewall de VPC).
  • Usaste la extensión de SRE para la CLI de Antigravity para descubrir y diagnosticar las interrupciones.
  • Se aprovechó el patrón Safe Executor para revisar y ejecutar comandos de corrección.
  • Se creó un análisis a posteriori profesional en Markdown.
  • Se consultaron las métricas de Cloud Monitoring para generar y, luego, incorporar automáticamente un gráfico de incidentes fundamentado.

Para obtener más detalles sobre cómo extender tu agente de CLI, consulta la página de GitHub de la extensión de SRE.