Investigar uma interrupção do GKE com a CLI do Antigravity e a extensão SRE e criar um belo post mortem

1. Introdução

856ff52e60953a92.png

Última atualização:13/05/2026

Investigue uma interrupção do GKE com a extensão do SRE e crie um post-mortem incrível

Este é um workshop de SRE para operadores que querem testar os arneses de SRE no Google Cloud.

Este codelab vai mostrar como:

  1. Instale um cluster do GKE com base em uma microservices-demo de código aberto conhecida.
  2. Crie uma interrupção de várias maneiras (algumas mais evidentes, outras mais sutis).
  3. Instale e use a CLI do Antigravity (ou um arnês semelhante) + a extensão do SRE para a próxima parte.
  4. Investigue e corrija a interrupção.
  5. Crie uma análise post mortem.
  6. Use as habilidades de criação de gráficos para gerar um gráfico fundamentado que permita aos espectadores entender o que aconteceu e quando.

Confira a estrutura detalhada do codelab:

Diagrama da estrutura do codelab

O objetivo deste workshop é:

  1. demonstrar os recursos da extensão SRE e mostrar o que é possível fazer com ela: configuração do OneMCP, Safe Executor, investigação, geração de análise post-mortem, gráficos e resumos em CSV.
  2. Ensinar as habilidades necessárias para investigar seu próprio cenário do Google Cloud.

Marco 1: configuração do ambiente e simulação de interrupção

O objetivo desta etapa é configurar um aplicativo de demonstração do Kubernetes no Autopilot do GKE, instalar a CLI do Antigravity e acionar artificialmente cenários de falha do cluster do GKE para simular incidentes de produção.

Marco 2: investigação e mitigação com a extensão de SRE

Depois de interromper o ambiente, você vai usar ferramentas de CLI agentivas equipadas com a extensão SRE para descobrir sistematicamente a infraestrutura, classificar os problemas, implementar o padrão de execução segura para correções e verificar a integridade do cluster.

Marco 3: análise post-mortem e geração de gráficos

Depois de resolvido, você vai gerar um documento estruturado de análise pós-incidente e usar as APIs do GCM (Google Cloud Monitoring) para extrair dados de métricas reais, criando gráficos visuais para documentar quando e como a interrupção ocorreu.

O que você vai criar

Neste codelab, você vai investigar e corrigir interrupções do GKE usando a extensão do SRE. Você vai:

  • Simule uma interrupção do GKE usando bloqueio de política de rede, implantações canário com bugs e atualizações de regras de firewall.
  • Triagem da interrupção do cluster usando um assistente de CLI com tecnologia da extensão SRE.
  • Implemente etapas de correção com segurança usando o padrão Safe Executor.
  • Gere um documento post mortem abrangente.
  • Representar graficamente as métricas de incidentes usando consultas de séries temporais do Google Cloud Monitoring.

O que você vai aprender

  • Como inspecionar recursos e políticas do Kubernetes no GKE usando habilidades de extensão de SRE.
  • Como usar o padrão Safe Executor para executar comandos sugeridos pelo agente com a avaliação de risco adequada.
  • Como usar a habilidade monitoring-graphs para gerar gráficos fundamentados de métricas diretamente do GCM.
  • Como documentar descobertas de incidentes em um formato estruturado de análise post-mortem.

O que é necessário

  • um projeto do Google Cloud com faturamento ativado
  • Ferramentas de linha de comando: gcloud, kubectl, terraform.
  • CLI do Antigravity instalada localmente ou no Cloud Shell.
  • Um ambiente de desenvolvimento integrado (por exemplo, vscode, IntelliJ, RubyMine ou Vim).

Por que a extensão de SRE + CLI com agentes?

As interrupções na produção são rápidas e exigem correlação em vários subsistemas (recursos do Kubernetes, redes VPC, métricas do Cloud Monitoring, permissões do IAM). A extensão SRE permite que assistentes de CLI agênticos (como a CLI do Antigravity) atuem como copilotos autônomos, executando playbooks pré-compilados, consultando gráficos de monitoramento e sugerindo correções seguras, mantendo o operador humano no processo.

2. Etapas da configuração

Escolha uma das seguintes opções: Configuração do ambiente no seu ritmo se quiser executar este

codelab na sua própria máquina ou Iniciar o Cloud Shell se quiser executar este codelab inteiramente na nuvem.

Configuração de ambiente autoguiada

  1. Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google e pode ser atualizada quando você quiser.
  • O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto.
  • Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
  1. Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Inicie o Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do Google Cloud, clique no ícone do Cloud Shell na barra de ferramentas superior à direita:

Ativar o Cloud Shell

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

Captura de tela do terminal do Google Cloud Shell mostrando que o ambiente foi conectado

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Neste codelab, todo o trabalho pode ser feito com um navegador. Você não precisa instalar nada.

3. Pré-requisitos (instalação)

Para este tutorial, você precisa instalar:

1. Python e uv

python e uv (gerenciador de pacotes para Python). Verifique se você tem o uv instalado:

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

Por que uv? Embora você possa usar o gerenciador do Python que preferir, o uv garante que a configuração ENV/PATH do Python seja igual para você e para a CLI do Antigravity. Assim, sua experiência de shell será quase a mesma da CLI do Antigravity. Se você usar virtualenv , por exemplo, a CLI do Antigravity será forçada a fazer coisas como "source .env/venv/bin/activate && my-original-command" para imitar seu ambiente.

2. CLI do Antigravity (agy)

Para instalar a CLI do Antigravity oficial (o comando agy), abra o terminal e execute o instalador de bootstrap:

Para macOS e Linux:

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

Para Windows (PowerShell):

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

Esse script vai detectar dinamicamente seu SO e arquitetura, baixar o

agy

binário e configure seu PATH. Reinicie o terminal ou recarregue a configuração do shell para que as mudanças entrem em vigor.

efade99623113f1.png

Authentication

Você precisa de uma chave de API do Google AI Studio.

Exporte sua chave de API:

export GEMINI_API_KEY="your-api-key"

Faça a autenticação com o gcloud:

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

Configurar seu ambiente de trabalho e implantar o aplicativo de demonstração de microsserviços

Vamos clonar o aplicativo microservices-demo e implantar a infraestrutura e o aplicativo usando o Terraform.

Agora é possível abrir o IDE (Visual Studio Code, IntelliJ, RubyMine etc.) e a pasta.

# 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 testar sua configuração, acesse http://[IP ADDRESS] e carregue o app online-boutique.

Configurar seu ambiente de trabalho 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. Etapa 1: simular a interrupção (cenários de falha)

Nesta etapa, vamos interromper intencionalmente o cluster do GKE implantado para simular um incidente de produção real. Você pode escolher entre três cenários ou tentar os três em sequência:

Cenário 1: bloqueio de rede do serviço de finalização de compra (padrão/piloto automático)

Esse cenário simula uma conexão interrompida entre o front-end e o serviço de finalização da compra aplicando um NetworkPolicy do Kubernetes que atua como um "buraco negro" de tráfego.

  1. Navegue até a pasta do cenário: 
    cd breakage1-checkout
  2. Acione a interrupção: 
    ./break.sh
    Isso cria uma NetworkPolicy chamada update-checkout-from-frontend no namespace default, que nega o tráfego de entrada para checkoutservice, a menos que ele venha de um pod com o rótulo app: frontend-checkout-test (que não existe).
  3. Tente comprar itens no front-end da Online Boutique. A página de finalização da compra vai travar ou mostrar um erro HTTP 500.

Cenário 2: implantação canário com bugs (Autopilot com Istio)

Esse cenário simula uma implantação ruim em que uma versão com bugs do front-end é lançada por uma implantação canário do Kubernetes.

  1. Navegue até a pasta do cenário: 
    cd ../breakage2-canary
  2. Acione a interrupção: 
    ./break.sh
    Isso implanta uma implantação canário frontend-canary que tem um erro de digitação nas variáveis de ambiente: PRODUCT_CATALOG_SERVICE_ADDR está configurado como productcatalogservices:3550 em vez de productcatalogservice:3550.
  3. Carregue a página inicial do front-end. Às vezes, ele falha (dependendo das ponderações de roteamento) porque o serviço canário não consegue resolver o catálogo de produtos.

Cenário 3: bloqueio de cluster do firewall da VPC

Esse cenário simula um erro na configuração do firewall da VPC que bloqueia todo o tráfego de entrada para o cluster do GKE.

  1. Navegue até a pasta do cenário: 
    cd ../breakage3-firewall
  2. Acione a interrupção: 
    ./break.sh
    Isso cria uma regra de firewall no nível da VPC chamada frontend-ingress-v2 com priority=1 e ação DENY direcionada ao tráfego de entrada para as portas 80, 443 e 8080.
  3. O site da Online Boutique vai ficar completamente inacessível, e as solicitações vão atingir o tempo limite.

5. Etapa 2: investigação de interrupção com a extensão SRE

Agora que o aplicativo está inativo, vamos iniciar a investigação usando seu assistente de CLI (CLI do Antigravity).

  1. Volte para a pasta principal de cenários de falha e inicie o auxiliar da CLI: 
    cd ..
agy
  2. Peça ao assistente para fazer uma descoberta de infraestrutura e uma verificação de diagnóstico: 
    Investigate my GKE cluster for outages. Are all services healthy?
  3. O que o agente faz:
    • Ele ativa as habilidades investigation-entrypoint e gcp-playbooks.
    • Ele lista pods, implantações e serviços do Kubernetes para localizar destinos com falha.
    • Ele inspeciona políticas de rede (para o cenário 1), configurações de implantação (para o cenário 2) ou regras de firewall (para o cenário 3).
  4. Para o cenário 1, o agente precisa informar: 🔴 Incidente identificado: um NetworkPolicy chamado update-checkout-from-frontend está isolando os pods checkoutservice.
  5. Para o cenário 2, o agente precisa informar: 🔴 Incidente identificado: a implantação frontend-canary está configurada com um endpoint de serviço inválido productcatalogservices:3550 em vez de productcatalogservice:3550.
  6. Para o cenário 3, o agente precisa informar: 🔴 Incidente identificado: uma regra de firewall da VPC frontend-ingress-v2 está negando o tráfego de entrada nas portas 80, 443 e 8080.

6. Etapa 3: mitigar e corrigir a interrupção

Vamos usar o padrão Safe Executor da CLI para corrigir a interrupção.

  1. Peça ao assistente da CLI para propor e aplicar uma correção: 
    Propose a fix for the outage and apply it.
  2. Safe Executor em ação:
    • Antes de executar sugestões de comandos, a extensão SRE faz uma auditoria de segurança usando a habilidade safe-sre-investigator.
    • Ele vai mostrar o comando exato que pretende executar e classificar o risco (por exemplo, baixo, médio, alto).
    • Para o cenário 1, ele vai propor: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • Para o cenário 2, ele vai propor: 
      kubectl delete deployment frontend-canary
    • Para o cenário 3, ele vai propor: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. Confirme a execução do comando quando solicitado pela CLI.
  4. Atualize a página inicial da Online Boutique para verificar se o site está funcionando normalmente.
  5. No shell, execute o script de verificação do cenário correspondente para verificar a integridade: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. Etapa 4: gerar o post mortem do incidente

Uma parte essencial do ciclo de vida de SRE é documentar o incidente para que a equipe possa aprender com ele. Vamos automatizar isso usando a habilidade postmortem-create.

  1. No assistente de CLI, peça para escrever o documento de análise pós-mortem: 
    Create a postmortem for the checkout service network policy outage.
  2. O agente vai coletar detalhes sobre:
    • O horário de início do incidente (recuperado do histórico/registros de comandos da CLI).
    • A causa raiz (o NetworkPolicy de bloqueio).
    • As ações tomadas para mitigar o problema.
  3. Ele vai gravar um novo arquivo Markdown chamado postmortem.md no seu espaço de trabalho.
  4. Abra postmortem.md para conferir os detalhes. Você vai encontrar seções como:
    • Resumo do incidente
    • Cronograma dos eventos
    • Análise da causa raiz (RCA)
    • Ações necessárias / Medidas preventivas

8. Etapa 5: adicionar gráficos de métricas fundamentadas

Para tornar o postmortem profissional, precisamos de provas visuais do incidente. Vamos usar a habilidade monitoring-graphs para buscar dados de série temporal do Google Cloud Monitoring (GCM) e gerar um gráfico PNG mostrando o pico de erros.

  1. Peça ao assistente da CLI para gerar o gráfico e adicioná-lo ao postmortem: 
    Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md.
  2. Em segundo plano:
    • O agente chama o script Python monitoring-graphs para consultar o Cloud Monitoring.
    • Ele busca métricas (por exemplo, kubernetes.io/container/restart_count ou loadbalancing.googleapis.com/https/request_count).
    • Ele cria o gráfico usando matplotlib e o salva como incident_metrics.png.
    • Ele atualiza o arquivo postmortem.md inserindo um link da imagem: 
      ![Incident Metric Graph](incident_metrics.png)
  3. Abra o arquivo incident_metrics.png gerado para ver o gráfico que ilustra os momentos exatos em que o cluster ficou inativo e quando o tráfego voltou ao normal.

9. Etapa 6: limpeza

Para garantir que sua conta do Google Cloud não gere cobranças desnecessárias, vamos limpar a infraestrutura implantada.

  1. Navegue até a pasta do Terraform: 
    cd ../../microservices-demo/terraform
  2. Execute o comando de exclusão: 
    terraform destroy -auto-approve
  3. Verifique se todos os recursos do GKE do GCP foram excluídos.

10. Parabéns!

Você concluiu o codelab de investigação de falhas e interrupções do cluster do GKE.

Conteúdo abordado:

  • Implantamos a demonstração de microsserviços do Online Boutique de 10 níveis no GKE.
  • Simulamos três interrupções de SRE no mundo real (negação de política de rede, implantação canário com bugs e negação de regra de firewall da VPC).
  • Usou a extensão do SRE para a CLI do Antigravity para descobrir e diagnosticar as interrupções.
  • Usou o padrão Safe Executor para revisar e executar comandos de correção.
  • Criou um postmortem profissional em Markdown.
  • Consultamos métricas do Cloud Monitoring para gerar e incorporar automaticamente um gráfico de incidentes fundamentado.

Para mais detalhes sobre como estender seu agente de CLI, confira a página da extensão SRE no GitHub.