Kit de ferramentas de IA da engenharia de nuvem: engenharia de plataforma no GKE usando o Gemini

1. Introdução

A solução de problemas em implantações do Kubernetes é uma parte comum e muitas vezes frustrante da vida diária de um engenheiro de plataforma. Geralmente, isso envolve muita investigação manual: analisar registros, executar comandos kubectl describe e fazer referências cruzadas em arquivos YAML para encontrar uma única incompatibilidade ou configuração incorreta.

Embora os chatbots de IA de uso geral possam ajudar a explicar conceitos ou escrever códigos básicos, eles operam em um vácuo. Eles não sabem nada sobre sua base de código específica ou o estado ativo do cluster, o que leva a muita cópia e colagem manual e troca de contexto.

Neste laboratório, você vai aprender a reduzir essa diferença usando ferramentas de IA com níveis crescentes de contexto. Você vai usar a CLI do Gemini e o Protocolo de Contexto de Modelo (MCP) para resolver problemas em um aplicativo corrompido no GKE. Ao final deste laboratório, você vai entender como usar a IA que conhece seus arquivos e infraestrutura para resolver problemas complexos mais rápido e como codificar esses fluxos de trabalho em "habilidades" reutilizáveis para sua equipe.

Principais conceitos

• Engenharia de plataforma:a engenharia de plataforma é a prática de criar e manter ferramentas e fluxos de trabalho internos que permitem que os desenvolvedores de software gerenciem a própria infraestrutura sem precisar ser especialistas em todos os serviços de nuvem subjacentes. O objetivo é reduzir o atrito técnico, mantendo a consistência e a segurança. Ao criar um caminho ideal padronizado, as equipes de plataforma garantem que os desenvolvedores de aplicativos possam implantar com segurança e rapidez, enquanto a equipe de plataforma mantém o controle sobre a governança e o custo.
• CLI do Gemini:a CLI do Gemini é uma interface de linha de comando que permite interagir com os modelos do Gemini diretamente no terminal. Ao contrário de um chatbot padrão baseado na Web, a CLI foi projetada para existir no seu ambiente de desenvolvimento, facilitando a integração da IA aos fluxos de trabalho baseados em shell. Ele permite transmitir a saída de outros comandos diretamente para o modelo e executar instruções sem sair do terminal.
• Protocolo de Contexto de Modelo (MCP):o MCP é um padrão aberto que permite que um modelo de IA se conecte a ferramentas ou fontes de dados específicas. Sem o MCP, um modelo de IA só sabe o que foi treinado e não pode acessar seus recursos específicos. Com o servidor MCP do GKE, a CLI do Gemini pode consultar ativamente a API do seu projeto do Google Cloud, inspecionar o estado dos seus clusters e executar comandos em seu nome. Ele atua como uma ponte entre o mecanismo de raciocínio do modelo e a API GKE real.
• Habilidades de agente:são pacotes de instruções, scripts e recursos que ampliam os recursos de um agente de IA para tarefas especializadas. Eles permitem codificar padrões organizacionais e automatizar fluxos de trabalho complexos.

Objetivos do laboratório

Neste laboratório, você vai:

1. Experiência de progressão de contexto:saiba como o aumento do contexto melhora a resolução de problemas com IA.
2. Solução de problemas manual x com IA:compare a dificuldade da depuração manual com os fluxos de trabalho assistidos por IA.
3. Depuração de contexto completo:use a CLI do Gemini com o servidor MCP do GKE para depurar aplicativos com reconhecimento total da infraestrutura.
4. Ampliar recursos:aprenda a escrever Skills personalizadas para automatizar fluxos de trabalho.

Observação sobre as saídas de LLM

Devido à natureza deste laboratório e ao funcionamento dos LLMs, as saídas que você vai receber provavelmente serão diferentes dos exemplos mostrados. Esse é o comportamento esperado da IA generativa. Concentre-se em entender as etapas e o raciocínio fornecido pelo modelo, em vez de tentar replicar o texto ou a formatação exatos nos exemplos.

2. Configuração do projeto

Antes de iniciar o laboratório, prepare o ambiente. Abra o Cloud Shell, selecione seu projeto e execute os scripts de configuração. Vamos começar!

Abrir o Cloud Shell

Neste laboratório, use o Cloud Shell, um ambiente de terminal baseado em navegador fornecido pelo Google Cloud. Ele vem pré-configurado com todas as ferramentas necessárias, incluindo a CLI do Google Cloud (gcloud), o kubectl e a CLI do Gemini, economizando o tempo de instalação dessas ferramentas na sua máquina local.

1. Acesse o Console do Google Cloud.
2. No cabeçalho do canto superior direito do console, clique no botão Ativar o Cloud Shell (parece um prompt de terminal >_).
3. Uma sessão de terminal é aberta na parte de baixo da janela do navegador. Se for solicitado, clique em Continuar.

Selecionar um projeto

No terminal do Cloud Shell, verifique se você está trabalhando no projeto correto.

1. Selecione um projeto atual ou crie um novo especificamente para este laboratório no console.
2. Anote o ID do projeto. Defina o projeto no shell atual executando: gcloud config set project [YOUR_PROJECT_ID]

Configuração do laboratório

Agora, execute os scripts de configuração para preparar o ambiente e introduzir os bugs do laboratório.

1. Clone o repositório
   :👉💻 execute os comandos a seguir para clonar apenas o diretório do laboratório:

   git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos ~/devrel-demos
   cd ~/devrel-demos
   git sparse-checkout set codelabs/ai-toolkit-lab-1
   

2. Navegue até o diretório do laboratório:
   👉💻 Execute:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
   

3. Definir variáveis de ambiente
   :👉💻 execute os comandos a seguir para definir seu projeto e região:

   export PROJECT_ID=$(gcloud config get-value project)
   export REGION=us-central1
   

4. Execute o script de configuração
   :esse script ativa as APIs listadas abaixo, cria um cluster do GKE Autopilot e garante que as ferramentas necessárias estejam instaladas.
   👉💻 Execute o script no diretório raiz:

   ./setup.sh
   

   Observação: a criação do cluster pode levar de 5 a 10 minutos.
5. Inicialize o estado corrompido:
   para simular o cenário em que seus colegas deixaram um ambiente corrompido, execute o script break.sh. Ele copia os manifestos corrompidos para o diretório de base de código ativo.
   👉💻 Execute o script:

   ./break.sh
   

6. Prepare-se para os exercícios práticos
   :para evitar que a IA trapaceie (veja as soluções), mude para o diretório cymbal-bank no restante do laboratório.
   👉💻 Execute:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
   

APIs ativadas

O script de configuração ativa várias APIs do Cloud. Confira o que eles fazem:

• container.googleapis.com::a API do Google Kubernetes Engine. Ele é necessário para qualquer operação no nível do cluster.
• generativelanguage.googleapis.com::a API que permite que a CLI do Gemini se comunique com os modelos do Gemini.
• cloudresourcemanager.googleapis.com::necessário para inspecionar metadados para envolvidos no projeto e gerenciar permissões.
• logging.googleapis.com::essencial para a solução de problemas, já que permite buscar e analisar registros dos seus contêineres.

3. Fase 0: solução de problemas manual (sem IA)

Agora que você está no diretório cymbal-bank, vamos tentar encontrar os erros manualmente. Essa é a "maneira difícil". Conheça o desempenho de referência antes de deixar a IA fazer o trabalho pesado. A solução de problemas manual significa usar ferramentas padrão, como kubectl, para inspecionar o estado do cluster, buscar registros e ler arquivos YAML para identificar inconsistências. Muitas vezes, esse processo é lento, tedioso e exige experiência para conectar os pontos. Isso serve como um ponto de referência perfeito para as ferramentas de IA que você usa depois.

1. Tente implantar:vamos ver o que o Kubernetes acha desses manifestos.
   👉💻 Execute o seguinte comando para aplicar os manifestos:

   kubectl apply -f kubernetes-manifests/
   

   Os pods podem levar alguns segundos para serem iniciados. Use "watch kubectl get pods" para acompanhar a inicialização deles. Quando eles estiverem ativos, use ctrl+c para sair do watch.Você vai notar dois pods com falha na lista:
   • O pod frontend mostra um "CreateContainerConfigError". Esse tipo de erro geralmente sugere que o contêiner está com problemas para carregar a configuração necessária. Pense em quais recursos externos um contêiner pode precisar para iniciar. Há variáveis de ambiente, secrets ou ConfigMaps que podem estar configurados incorretamente ou ausentes? Investigue a configuração do pod para encontrar o problema específico.
   • O pod userservice está no estado "ImagePullBackOff". Isso geralmente significa que o cluster não consegue recuperar a imagem do contêiner que foi instruído a usar. Considere os detalhes da solicitação de imagem: o nome e a tag da imagem estão exatamente corretos? Há possíveis problemas de permissão com o registro? Verifique de onde a imagem está sendo extraída para identificar o motivo da falha na solicitação.
2. Inspecione o dano:use comandos padrão do Kubernetes para ver o que está falhando.
   • 👉💻 Verifique o status e os nomes dos pods:

     kubectl get pods
     

     • Observação:você vê pods em ImagePullBackOff, CrashLoopBackOff, Pending ou CreateContainerConfigError.
     • Observação:um pod no estado Running não significa necessariamente que ele está funcionando corretamente. Por exemplo, pode estar faltando sondas de integridade suficientes (atividade/prontidão), fazendo com que ele seja marcado como em execução mesmo que o aplicativo interno esteja falhando. Os registros podem mostrar erros, apesar de um pod aparentemente em execução. Há 11 erros diferentes para corrigir no total.
   • 👉💻 Descreva um pod com falha para ver eventos (substitua [POD_NAME] pelo nome de um pod real):

     kubectl describe pod [POD_NAME]
     

   • 👉💻 Verifique os registros de um pod com falha para conferir erros de aplicativo:

     kubectl logs [POD_NAME]
     

3. O trabalho de detetive:abra os manifestos em kubernetes-manifests/ usando o editor do Cloud Shell ou cat no terminal. Tente correlacionar os erros que aparecem nos registros e eventos com a configuração nos arquivos YAML.Desafio:tente corrigir APENAS UM erro manualmente. Perceba como você precisa alternar entre arquivos para descobrir o restante da cadeia de falhas.

4. Fase 1: perguntar à Web (interface da Web do Gemini)

Como a solução de problemas manual é lenta, vamos usar um assistente de IA. O web app Gemini é uma interface de chat poderosa e de uso geral. Ele é excelente em explicar conceitos e gerar snippets de código. No entanto, ele opera com contexto zero do seu ambiente específico. Ele não pode acessar seus arquivos, inspecionar seu cluster ou executar comandos. É necessário copiar e colar manualmente as mensagens de erro e o conteúdo dos arquivos.

1. Acesse o Gemini:abra gemini.google.com em uma nova guia. Faça login com sua Conta do Google.
2. Peça ajuda com um erro específico:diga que você vê o erro ImagePullBackOff no pod userservice.
   👉💬 Insira este comando na interface da Web do Gemini:
   My Kubernetes deployment for 'userservice' is failing with ImagePullBackOff. Here is the image name: us-central1-docker.pkg.dev/bank-of-anthos-ci/bank-of-anthos/user-service:v0.6.9. What is wrong?
3. Resposta da IA:o Gemini dá uma lista de causas comuns:
   • A imagem não existe.
   • Você não tem permissão para extrair.
   • Há um erro de digitação.
   Ele sugere verificar suas permissões do IAM ou do registro. Mas ele não pode saber que o nome real da imagem é userservice (sem o hífen) a menos que veja seu projeto.

O principal ponto de atrito aqui é que o Gemini não tem visibilidade do seu ambiente local. Para fornecer o contexto necessário, você precisaria fazer isso manualmente (enviando comandos e copiando e colando texto), o que é demorado e propenso a erros.

5. Fase 2: poder do terminal (CLI do Gemini)

Agora, acesse o terminal usando a CLI do Gemini. A CLI do Gemini leva o poder dos modelos do Gemini diretamente para o seu terminal. A CLI está disponível onde você trabalha. Ele lê arquivos locais, aceita entradas transmitidas por pipe e até executa comandos do shell em seu nome (com sua aprovação). Isso é muito útil para integrar a IA aos seus fluxos de trabalho sem precisar mudar de contexto. Para informações mais detalhadas e uso avançado, consulte a documentação oficial da CLI do Gemini.

Observação:a CLI do Antigravity foi lançada oficialmente e é a sucessora da CLI do Gemini. Este laboratório continua usando a CLI do Gemini. Para mais detalhes sobre a CLI Antigravity, confira a documentação oficial (em inglês).

Contexto e visibilidade

Antes de continuar, saiba que a visibilidade da CLI Gemini no seu projeto depende de onde você a inicia. O modelo pode ver arquivos e pastas relativos ao seu diretório de trabalho atual. Se você executar a CLI na raiz do projeto, ela terá acesso a todos os arquivos dele. Se você executar em um subdiretório, a visualização será restrita a esse subdiretório e aos filhos dele. Sempre verifique se você está no diretório correto antes de pedir que o modelo analise ou modifique arquivos.

Como iniciar a CLI do Gemini

O Cloud Shell inclui a CLI do Gemini por padrão. Basta iniciar para começar a usar com seus arquivos locais.

1. Acesse o diretório do Cymbal Bank:
   👉💻 Execute o seguinte comando para confirmar se você está no diretório correto:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
   

2. Iniciar a CLI do Gemini
   👉💻 Execute o seguinte comando para iniciar a CLI do Gemini:

   gemini
   

Como usar a CLI do Gemini

Tudo o que você sabe sobre esse aplicativo é onde encontrar o código e que ele está falhando. Vamos saber mais e ver como o Gemini pode ajudar você a corrigir o aplicativo. Primeiro, teste a capacidade de analisar o contexto fazendo uma pergunta sobre os arquivos do aplicativo que ele precisa acessar.

1. Explore a base de código:peça ao Gemini para explicar o que é e o que faz esse aplicativo.
   👉💬 Insira este comando na CLI do Gemini:
   What is this application and what does it do?
   A CLI do Gemini lê os arquivos no diretório atual e fornece uma visão geral de alto nível do projeto.
2. Tente encontrar um problema na base de código:como a CLI do Gemini vê seus arquivos, peça para ela encontrar uma incompatibilidade.
   👉💬 Insira este comando na CLI do Gemini:
   The contacts service pod is running, but I can't reach the service. Review kubernetes-manifests/contacts.yaml and check for common issues
   A CLI do Gemini lê os arquivos e identifica a incompatibilidade entre app: contacts-backend e app: contacts. Isso é uma grande vitória em relação às fases anteriores.
3. Peça para corrigir:
   👉💬 Insira este comando na CLI do Gemini:
   Fix the label mismatch in contacts.yaml so the service matches the deployment.
   A CLI do Gemini mostra o YAML corrigido ou até aplica a mudança se você aprovar o comando.
4. A limitação:embora ele veja os arquivos, ainda não sabe o que está realmente sendo executado no cluster. Se um pod falhar devido a um erro de execução não óbvio no YAML estático, ele não poderá ajudar sem registros ou estado do cluster.

Observação:a CLI do Gemini vai pedir sua permissão ao executar comandos ou fazer modificações em arquivos. Isso garante que você mantenha o controle sobre seu ambiente. Quando aparecer um comando como o abaixo, pressione "Enter" para responder "1. Permitir uma vez" para cada solicitação de ação. Você também pode tocar na tecla de seta para baixo e pressionar "Enter" para selecionar "2. Permitir esta sessão", o que fará com que a CLI do Gemini sempre realize essa ação de forma independente, sem pedir sua permissão, durante toda a conversa. No entanto, se você fechar e reabrir a CLI do Gemini, ela não terá mais essa permissão e vai pedir autorização novamente antes de realizar qualquer ação.

Observação:se você ficar preso ou quiser tentar de novo do zero, redefina os manifestos do Kubernetes para o estado inicial corrompido a qualquer momento executando ../break.sh no diretório cymbal-bank.

Observação:se você atingir um limite de uso, selecione "Parar" e execute /model para ver quais modelos atingiram os limites e mudar para um modelo diferente, como gemini-2.5-flash-lite. Em seguida, peça ao modelo para "continuar" o laboratório usando o novo modelo.

6. Fase 3: depuração de contexto completo (CLI do Gemini + MCP do GKE)

Embora a Fase 2 tenha mostrado o poder da IA quando ela pode acessar seus arquivos, ela também era ruidosa. Você precisava aprovar manualmente cada leitura de arquivo e ação de ferramenta, o que criava um atrito significativo durante uma sessão de depuração complexa. A fase 3 apresenta o servidor MCP do GKE para ajudar a corrigir isso, fornecendo à IA o "reconhecimento da infraestrutura" direto. Isso permite que o Gemini resolva problemas de registros, eventos e metadados com menos interrupções manuais, criando um fluxo de solução de problemas mais automatizado e coeso.

O que é o MCP?

Para entender o MCP, é útil primeiro entender o conceito de ferramentas no mundo da IA. Uma ferramenta é essencialmente uma função ou um aplicativo externo que um LLM pode usar para realizar ações ou buscar dados que não seriam acessíveis de outra forma, como verificar a previsão do tempo, executar um script específico ou consultar um banco de dados. Embora as ferramentas individuais sejam poderosas, compartilhá-las de forma segura e consistente entre diferentes agentes e ambientes de IA sempre foi um desafio. O MCP resolve isso atuando como uma plataforma padronizada que pode hospedar essas ferramentas e expô-las a qualquer cliente de IA compatível.

O Protocolo de Contexto de Modelo (MCP) é um protocolo de código aberto que permite que modelos de IA acessem ferramentas e fontes de dados externas de forma segura. Em vez de codificar integrações para cada ferramenta ou banco de dados específico, o MCP oferece uma maneira padronizada para que os modelos interajam com o ambiente.

Para ver as ferramentas disponíveis na CLI do Gemini, execute /mcp dentro dela.

Neste laboratório, o servidor MCP do GKE permite que a CLI do Gemini interaja diretamente com seu cluster do GKE, inspecionando recursos, lendo registros e ajudando você a depurar problemas com total conhecimento do estado ativo do cluster. Isso transforma a IA de um analisador de código estático em um assistente ativo de solução de problemas que entende o estado ativo da sua infraestrutura.

Configurar a extensão do MCP do GKE

Por padrão, a CLI do Gemini é uma ferramenta de uso geral. Configure o servidor MCP do GKE criando um arquivo de configuração.

1. 👉💻 Primeiro, saia da CLI do Gemini se ainda estiver nela digitando /quit.
2. 👉💻 Execute o seguinte comando para criar o diretório de extensão:

   mkdir -p ~/.gemini/extensions/gke
   

3. 👉💻 Execute o comando a seguir para criar o arquivo de configuração. Esse comando injeta automaticamente seu PROJECT_ID no arquivo:

   cat << EOF > ~/.gemini/extensions/gke/gemini-extension.json
   {
     "name": "gke",
     "version": "1.0.0",
     "mcpServers": {
       "container": {
         "httpUrl": "https://container.googleapis.com/mcp",
         "authProviderType": "google_credentials",
         "oauth": {
           "scopes": ["https://www.googleapis.com/auth/container"]
         },
         "timeout": 30000,
         "headers": {
           "x-goog-user-project": "$PROJECT_ID"
         }
       }
     }
   }
   EOF
   

4. 👉💻 Inicie a CLI do Gemini:

   gemini
   

5. Verifique se o servidor MCP está ativado digitando /mcp na CLI do Gemini.

Pedir ao Gemini para depurar usando o estado do cluster

1. Depurar implantação com falha:agora, peça ao Gemini para inspecionar o cluster e corrigir os manifestos com base no que ele encontrar.
   👉💬 Insira este comando na CLI do Gemini:
   The frontend deployment is failing. Can you use your tools to check the logs and events of the pods, and then fix it?
   O Gemini usa ferramentas do MCP para chamar comandos kubectl nos bastidores. Ele vê o erro ImagePullBackOff, explica a causa e sugere a correção adequada.
2. Corrija problemas complexos:peça para ele analisar os registros em busca de erros no nível do aplicativo.
   👉💬 Insira este comando na CLI do Gemini:
   Check the logs for the 'contacts' pod. Why is it failing to connect to the database?
   Ele identifica o erro de conexão recusada e o rastreia até a incompatibilidade de porta ou de nome de serviço em config.yaml.
3. Iterar:continue pedindo ao Gemini para corrigir os outros problemas encontrados na Fase 0.
   👉💬 Insira este comando na CLI do Gemini:
   Check if the service 'contacts' is correctly routing traffic to its pods
   👉💬 Insira este comando na CLI do Gemini:
   Are there any pods failing due to resource limits?

Observação:se você ficar preso ou quiser tentar de novo do zero, redefina os manifestos do Kubernetes para o estado inicial corrompido a qualquer momento executando ../break.sh no diretório cymbal-bank.

7. Fase 4: capacitar a equipe (Habilidades do Agente)

Por fim, amplie os recursos da IA para suas necessidades específicas criando Habilidades do Agente personalizadas.

O que são habilidades de agente?

As habilidades do agente são pacotes de instruções, scripts e recursos que estendem um agente de IA para tarefas especializadas. Elas permitem codificar padrões organizacionais e automatizar fluxos de trabalho complexos. Uma habilidade fica em um diretório específico e contém um arquivo SKILL.md que define o comportamento dela. Ao criar habilidades, você garante que a IA siga um processo consistente e repetível em vez de improvisar.

Um diretório de habilidades típico tem esta aparência:

my-skill/
├── SKILL.md          # Main instruction file (Required)
├── scripts/           # Helper scripts (Optional)
└── resources/         # Templates or data files (Optional)

Como criar uma habilidade de solução de problemas do Kubernetes

Em vez de criar esses arquivos manualmente, a CLI do Gemini oferece uma maneira eficiente de criar habilidades usando linguagem natural.

Imagine que você quer criar uma habilidade chamada k8s-troubleshooter para automatizar as etapas que acabou de realizar.

1. Crie a habilidade usando comandos: você pode pedir para a CLI do Gemini criar a habilidade com base no que aprendeu hoje.
   👉💬 Insira este comando na CLI do Gemini:
   Create a new skill called 'k8s-troubleshooter' that helps diagnose issues with Kubernetes manifests and cluster state. It should be able to analyze pod logs, events, and resource descriptions to identify common deployment problems and configuration errors.
   assim como quando ela chama uma ferramenta ou realiza uma ação, a CLI do Gemini informa que o comando ativou a habilidade "criador de habilidades". Essa é uma habilidade pré-configurada na CLI do Gemini que permite que o Gemini crie habilidades de agente.
   O Gemini vai pedir sua permissão para criar o diretório de habilidades. Para aprovar, selecione 1. Permitir uma vez.
   O Gemini vai fazer o seguinte automaticamente:
   • Cria um diretório em ~/.gemini/skills/k8s-troubleshooter/.
   • Gera um arquivo SKILL.md com instruções com base no seu comando.
   • Cria diretórios de recursos padrão.
2. Reinicie a CLI do Gemini
   👉💻 Feche a CLI do Gemini (/quit) e reinicie:

   gemini
   

3. Verifique se a skill foi carregada:
   👉💻 Para verificar se a skill está ativa, digite /skills na CLI do Gemini. Você vai ver k8s-troubleshooter na lista.
4. Como funciona na prática:agora, invoque a habilidade:
   👉💬 Insira este comando na CLI do Gemini:
   Use the k8s-troubleshooter skill to find out why the contacts service is failing.
   A IA segue o plano estruturado em SKILL.md em vez de improvisar, o que leva a resultados mais consistentes.

Exercício: crie suas próprias habilidades

Pense no seu fluxo de trabalho diário. Que tarefa repetitiva você poderia automatizar com uma Skill?

• Ideia:uma habilidade para auditar manifestos e verificar se eles seguem as práticas recomendadas de segurança antes da implantação.
• Ideia:uma habilidade para gerar configurações complexas de cluster do GKE com base no tipo de carga de trabalho.

8. Conclusão

Este laboratório demonstra uma nova maneira de interagir com a infraestrutura em nuvem progredindo por diferentes níveis de contexto de IA. Ao passar de contexto zero para contexto completo da infraestrutura (CLI do Gemini + GKE MCP), você percebe como um assistente de IA se torna muito mais eficaz quando tem acesso aos seus arquivos e ao estado do cluster.

Resumo do laboratório

• O contexto é importante:você vê como as ferramentas de IA sem contexto não podem ajudar com problemas específicos da base de código.
• Contexto do terminal:você usa a CLI do Gemini para analisar arquivos locais e identificar erros de configuração diretamente no seu espaço de trabalho.
• Depuração de contexto completo:você usa a CLI do Gemini com o MCP para permitir que a IA diagnostique e corrija problemas complexos correlacionando arquivos de base de código com o estado do cluster ativo.
• Extensibilidade:você vai aprender sobre as habilidades e como usá-las para codificar o conhecimento organizacional.

Limpeza

Para evitar cobranças contínuas, execute o script de encerramento. Essa etapa não é necessária se você estiver fazendo o laboratório no Qwiklabs.

👉💻 Execute o seguinte comando no diretório do workshop:

cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
./teardown.sh

Próximas etapas

Confira algumas recomendações de leitura:

• Documentação da CLI do Gemini: a documentação oficial da CLI do Gemini.
• Documentação do GKE: a página de destino de toda a documentação do GKE.
• Engenharia de plataforma no Google Cloud: orientações sobre como abordar a engenharia de plataforma no Google Cloud.
• IA e machine learning no GKE: documentação sobre a execução de cargas de trabalho de IA/ML no GKE.
• Centro de arquitetura do Google Cloud: orientações e práticas recomendadas para criar cargas de trabalho no Google Cloud.

9. Apêndice: solução para falhas no manifesto

Se você tiver dificuldades ou quiser verificar os erros, confira a lista de falhas introduzidas no diretório manifests-broken/ e como corrigi-las:

1. URLs malformados em config.yaml:
   • Erro : TRANSACTIONS_API_ADDR: "ledgerwriter::8080" (dois pontos).
   • Motivo:o aplicativo não consegue analisar o endereço, o que causa erros de conexão.
   • Correção:mude de volta para "ledgerwriter:8080".
2. Rótulos incompatíveis em contacts.yaml:
   • Erro:o seletor de serviço foi definido como app: contacts-backend em vez de contacts.
   • Por quê:o serviço não consegue encontrar os pods (que ainda têm app: contacts), então o tráfego não será roteado.
   • Correção:mude o seletor para app: contacts.
3. Incompatibilidades de porta em userservice.yaml:
   • Erro:o serviço targetPort foi definido como 8081 em vez de 8080.
   • Por quê:o tráfego enviado ao serviço será encaminhado para a porta errada do contêiner, causando uma conexão recusada.
   • Correção:mude targetPort de volta para 8080.
4. Nomes de serviços incompatíveis em config.yaml:
   • Erro : BALANCES_API_ADDR: "balance-reader:8080" (em vez de balancereader).
   • Motivo:o nome do host não será resolvido no DNS porque o serviço se chama balancereader.
   • Correção:mude de volta para "balancereader:8080".
5. Políticas de extração de imagens em contacts.yaml:
   • Erro: imagePullPolicy: Never.
   • Por quê:o K8s não extrairá a imagem do registro, supondo que ela seja local. Ele vai falhar com ErrImagePull.
   • Correção:remova a linha ou defina como IfNotPresent.
6. Falhas na sondagem de prontidão em userservice.yaml:
   • Erro:o caminho mudou para /healthz em vez de /ready.
   • Motivo:o contêiner não atende a /healthz, então a sondagem falha e o pod nunca é marcado como pronto.
   • Correção:mude o caminho de volta para /ready.
7. Limites de recursos no contacts.yaml:
   • Erro:o limite de memória foi definido como 10Mi em vez de 128Mi.
   • Por quê:o app precisa de mais memória para iniciar, o que faz com que ele seja OOMKilled.
   • Correção:restaure o limite de memória.
8. Variáveis de ambiente ausentes em frontend.yaml:
   • Erro:a variável de ambiente REGISTERED_OAUTH_CLIENT_ID foi removida.
   • Por quê:o app pode falhar ou desativar recursos se as variáveis de ambiente esperadas estiverem ausentes.
   • Correção:restaure a definição da variável de ambiente.
9. Chave do ConfigMap incompatível em frontend.yaml:
   • Erro : key: DEMO_USER em vez de DEMO_LOGIN_USERNAME.
   • Motivo:o K8s não consegue encontrar a chave no ConfigMap, o que faz com que o contêiner não seja iniciado.
   • Correção:mude a chave de volta para DEMO_LOGIN_USERNAME.
10. Erro de digitação no nome da imagem em userservice.yaml:
    • Erro : user-service em vez de userservice.
    • Motivo:a imagem não existe no registro, causando ImagePullBackOff.
    • Correção:corrija o nome da imagem.
11. Problemas com contas de serviço em contacts.yaml:
    • Erro : bank-of-anthos-sa em vez de bank-of-anthos.
    • Motivo:a ServiceAccount não existe ou não tem permissões.
    • Correção:use o nome correto da conta de serviço.