Introdução à solução de problemas do GKE

Nesta página, apresentamos técnicas básicas de solução de problemas para o Google Kubernetes Engine (GKE). Esta página é destinada a usuários iniciantes no Kubernetes e no GKE que querem aprender práticas eficazes de solução de problemas.

Nesta página, você encontra uma visão geral das seguintes ferramentas e técnicas para monitorar, diagnosticar e resolver problemas com o GKE:

• Analise a integridade do cluster e da carga de trabalho no console Google Cloud : tenha uma visão geral para identificar rapidamente possíveis problemas com seus clusters e apps.
• Investigue o estado do cluster com a ferramenta de linha de comando kubectl: use estes comandos para conferir o status em tempo real de recursos como nós e pods.
• Faça análises históricas com o Cloud Logging: consulte dados de registros históricos e examine eventos para identificar a causa raiz das falhas.
• Faça um monitoramento proativo com o Cloud Monitoring: acompanhe as métricas de desempenho ao longo do tempo, visualize tendências e crie alertas para detectar e responder a problemas antes que eles afetem os usuários.
• Acelere o diagnóstico com o Gemini Cloud Assist: analise mensagens de erro complexas, receba orientações de solução de problemas detalhadas e investigue problemas automaticamente.
• Como usar tudo isso: exemplo de cenário de solução de problemas: veja como usar essas ferramentas juntas em um tutorial detalhado para diagnosticar e resolver uma falha comum de app no mundo real.

Entender os principais conceitos

Se você não conhece o Kubernetes e o GKE, é essencial entender os conceitos básicos, como arquitetura de cluster e a relação entre pods e nós, antes de começar a resolver problemas. Para saber mais, consulte Começar a aprender sobre o GKE.

Também é útil entender quais partes do GKE você é responsável por manter e quais partes o Google Cloud é responsável por manter. Para mais informações, consulte Responsabilidade compartilhada do GKE.

Analisar a integridade do cluster e da carga de trabalho no console do Google Cloud

O console Google Cloud é um bom ponto de partida para a solução de problemas porque oferece uma visão rápida da integridade dos clusters e das cargas de trabalho. A integridade do cluster se refere à integridade da infraestrutura do GKE subjacente, como nós e rede, enquanto a integridade da carga de trabalho se refere ao status e ao desempenho dos apps em execução no cluster.

As seções a seguir descrevem as páginas de cluster e de carga de trabalho. Para fornecer uma visão completa da integridade do app, o console Google Cloud também oferece acesso a ferramentas avançadas de geração de registros e monitoramento, permitindo investigar a causa raiz de falhas anteriores e evitar proativamente as futuras. Para mais informações sobre essas ferramentas, consulte as seções Fazer análises históricas com o Cloud Logging e Realizar monitoramento proativo com o Cloud Monitoring.

Encontrar problemas de cluster

A página Clusters do Kubernetes oferece uma visão geral da integridade dos seus clusters. Para identificar problemas com qualquer um dos seus clusters, comece nesta página.

• Para começar, no console Google Cloud , acesse a página Clusters do Kubernetes.

  Acessar clusters do Kubernetes

Confira alguns exemplos de como usar essa página para resolver problemas:

• Para receber conselhos sobre como melhorar a integridade do cluster, a estratégia de upgrade e a otimização de custos, clique em Ver recomendações.
• Para identificar clusters não íntegros, consulte a coluna Status. Qualquer cluster sem uma marca de seleção verde precisa de atenção.
• Para conferir possíveis problemas, analise a coluna Notificações. Clique em qualquer mensagem de notificação para mais informações.

Investigar um cluster específico

Depois de descobrir um problema com um cluster, acesse a página Detalhes para informações detalhadas que ajudam a resolver problemas e entender a configuração.

Para acessar a página Detalhes de um cluster, faça o seguinte:

1. Acesse a página Clusters do Kubernetes.

   Acessar clusters do Kubernetes

2. Analise a coluna Nome e clique no nome do cluster que você quer investigar.

Confira alguns exemplos de como usar a página Detalhes do cluster para resolver problemas:

• Para verificações de integridade gerais, tente as seguintes opções:

  • Para acessar os painéis no nível do cluster, acesse a guia Observabilidade. Por padrão, o GKE ativa o Cloud Monitoring quando você cria um cluster. Quando o Cloud Monitoring está ativado, o GKE configura automaticamente os painéis nesta página. Confira algumas visualizações que podem ser mais úteis para resolver problemas:

    • Visão geral: confira um resumo de alto nível da integridade, da utilização de recursos e dos principais eventos do cluster. Esse painel ajuda a avaliar rapidamente o estado geral do cluster e identificar possíveis problemas.
    • Métricas de tráfego: confira as métricas de rede por nós para ter insights sobre o tráfego entre suas cargas de trabalho do Kubernetes.
    • Estado da carga de trabalho: confira o estado de implantações, pods e contêineres. Identifique instâncias com falha ou não íntegras e detecte restrições de recursos.

    • Plano de controle: confira a integridade e o desempenho do plano de controle. Com ele, é possível monitorar métricas importantes de componentes como kube-apiserver e etcd, identificar gargalos de desempenho e detectar falhas de componentes.

  • Para conferir os erros recentes do app, acesse a guia Erros do app. As informações nessa guia ajudam a priorizar e resolver erros mostrando o número de ocorrências, quando um erro apareceu pela primeira vez e quando ocorreu pela última vez.

    Para investigar melhor um erro, clique na mensagem para ver um relatório detalhado, incluindo links para registros relevantes.

• Se você estiver resolvendo problemas após um upgrade ou uma mudança recente, confira a seção Noções básicas do cluster na guia Detalhes do cluster. Confirme se a versão listada no campo Versão é a esperada. Para mais investigações, clique em Mostrar histórico de upgrade na seção Upgrades.

• Se você estiver usando um cluster padrão e seus pods estiverem travados em um estado Pending ou suspeitar que os nós estão sobrecarregados, verifique a guia Nós. A guia Nós não está disponível para clusters do Autopilot porque o GKE gerencia os nós para você.

  • Na seção Pools de nós, verifique se o escalonamento automático está configurado corretamente e se o tipo de máquina é adequado para suas cargas de trabalho.
  • Na seção Nós, procure qualquer nó com um status diferente de Ready. Um status NotReady indica um problema com o próprio nó, como pressão de recursos ou um problema com o kubelet (o kubelet é o agente que é executado em cada nó para gerenciar contêineres).

Encontrar problemas com a carga de trabalho

Quando você suspeitar que há um problema com um app específico, como uma implantação com falha, acesse a página Cargas de trabalho no console Google Cloud . Essa página oferece uma visão centralizada de todos os apps executados nos clusters.

• Para começar, no console Google Cloud , acesse a página Cargas de trabalho.

  Acesse "Cargas de trabalho"

Confira alguns exemplos de como usar essa página para resolver problemas:

• Para identificar cargas de trabalho não íntegras, consulte a coluna Status. Qualquer carga de trabalho sem uma marca de seleção verde precisa de atenção.
• Se um app não estiver respondendo, consulte a coluna Pods. Por exemplo, um status como 1/3 significa que apenas uma das três réplicas do app está em execução, indicando um problema.

Investigar uma carga de trabalho específica

Depois de identificar uma carga de trabalho problemática na visão geral, acesse a página Detalhes da carga de trabalho para isolar a causa raiz.

Para acessar a página Detalhes de uma carga de trabalho, faça o seguinte:

1. Acesse a página Cargas de trabalho.

   Acesse "Cargas de trabalho"

2. Clique na coluna Nome e clique no nome da carga de trabalho que você quer investigar.

Confira alguns exemplos de como usar a página Detalhes da carga de trabalho para resolver problemas:

• Para verificar a configuração da carga de trabalho, use as guias Visão geral e Detalhes. Use essas informações para verificar eventos, como se a tag de imagem de contêiner correta foi implantada ou se os limites e solicitações de recursos da carga de trabalho estão corretos.

• Para encontrar o nome de um pod específico com falha, acesse a seção Pods gerenciados. Talvez você precise dessas informações para comandos kubectl. Esta seção lista todos os pods controlados pela carga de trabalho, junto com os status. Para conferir um histórico de mudanças recentes em uma carga de trabalho, acesse a guia Histórico de revisões. Se você notar problemas de desempenho após uma nova implantação, use esta seção para identificar qual revisão está ativa. Em seguida, compare as configurações da revisão atual com as anteriores para identificar a origem do problema. Se essa guia não estiver visível, a carga de trabalho é de um tipo que não usa revisões ou ainda não recebeu atualizações.

• Se uma implantação parece ter falhado, acesse a guia Eventos. Essa página geralmente é a fonte de informações mais valiosa porque mostra eventos no nível do Kubernetes.

• Para conferir os registros do app, clique na guia Registros. Esta página ajuda você a entender o que está acontecendo dentro do cluster. Procure aqui mensagens de erro e rastreamentos de pilha que podem ajudar a diagnosticar problemas.

• Para confirmar exatamente o que foi implantado, acesse a guia YAML. Esta página mostra o manifesto YAML ativo da carga de trabalho no cluster. Essas informações são úteis para encontrar discrepâncias nos manifestos controlados por origem. Se você estiver visualizando um manifesto YAML de um único pod, essa guia também vai mostrar o status do pod, que fornece insights sobre falhas no nível do pod.

Investigar o estado do cluster com a ferramenta de linha de comando kubectl

Embora o console Google Cloud ajude você a entender se há um problema, a ferramenta de linha de comandokubectlé essencial para descobrir por quê. Ao se comunicar diretamente com o plano de controle do Kubernetes, a ferramenta de linha de comando kubectl permite coletar as informações detalhadas necessárias para resolver problemas no ambiente do GKE.

As seções a seguir apresentam alguns comandos essenciais que são um ponto de partida eficiente para a solução de problemas do GKE.

Antes de começar

Antes de começar, faça o seguinte:

• Instale kubectl.

• Configure a ferramenta de linha de comando kubectl para se comunicar com o cluster:

  gcloud container clusters get-credentials CLUSTER_NAME \
      --location=LOCATION
  

  Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.

• Revise suas permissões. Para saber se você tem as permissões necessárias para executar comandos kubectl, use o comando kubectl auth can-i. Por exemplo, para ver se você tem permissão para executar kubectl get nodes, execute o comando kubectl auth can-i get nodes.

  Se você tiver as permissões necessárias, o comando vai retornar yes. Caso contrário, ele vai retornar no.

  Se você não tiver permissão para executar um comando kubectl, talvez veja uma mensagem de erro semelhante a esta:

  Error from server (Forbidden): pods "POD_NAME" is forbidden: User
  "USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the
  namespace "default"
  

  Se você não tiver as permissões necessárias, peça ao administrador do cluster para atribuir os papéis necessários a você.

Ter uma visão geral do que está em execução

O comando kubectl get ajuda a ter uma visão geral do que está acontecendo no cluster. Use os comandos a seguir para conferir o status de dois dos componentes mais importantes do cluster, nós e pods:

1. Para verificar se os nós estão íntegros, confira os detalhes de todos os nós e os respectivos status:

   kubectl get nodes
   

   O resultado será assim:

   NAME                                        STATUS   ROLES    AGE     VERSION
   
   gke-cs-cluster-default-pool-8b8a777f-224a   Ready    <none>   4d23h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-egb2   Ready    <none>   4d22h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-p5bn   Ready    <none>   4d22h   v1.32.3-gke.1785003
   

   Qualquer outro status que não seja Ready exige mais investigação.

2. Para verificar se os pods estão íntegros, veja detalhes sobre todos os pods e os respectivos status:

   kubectl get pods --all-namespaces
   

   O resultado será assim:

   NAMESPACE   NAME       READY   STATUS      RESTARTS   AGE
   kube-system netd-6nbsq 3/3     Running     0          4d23h
   kube-system netd-g7tpl 3/3     Running     0          4d23h
   

   Qualquer outro status que não seja Running exige mais investigação. Confira alguns status comuns que você pode encontrar:

   • Running: um estado de execução íntegro.
   • Pending: o pod está aguardando para ser programado em um nó.
   • CrashLoopBackOff: os contêineres no pod falham repetidamente em um loop porque o app inicia, sai com um erro e é reiniciado pelo Kubernetes.
   • ImagePullBackOff: o pod não pode extrair a imagem do contêiner.

Os comandos anteriores são apenas dois exemplos de como usar o comando kubectl get. Você também pode usar o comando para saber mais sobre vários tipos de recursos do Kubernetes. Para uma lista completa dos recursos que você pode explorar, consulte kubectl get na documentação do Kubernetes.

Saiba mais sobre recursos específicos

Depois de identificar um problema, você precisa saber mais detalhes. Um exemplo de problema pode ser um pod que não tem o status Running. Para mais detalhes, use o comando kubectl describe.

Por exemplo, para descrever um pod específico, execute o seguinte comando:

kubectl describe pod POD_NAME -n NAMESPACE_NAME

Substitua:

• POD_NAME: o nome do pod com problemas.
• NAMESPACE_NAME: o namespace em que o pod está. Se você não tiver certeza de qual é o namespace, revise a coluna Namespace na saída do comando kubectl get pods.

A saída do comando kubectl describe inclui informações detalhadas sobre seu recurso. Confira algumas das seções mais úteis para revisar ao solucionar problemas de um pod:

• Status: o status atual do pod.
• Conditions: a integridade e a prontidão geral do pod.
• Restart Count: quantas vezes os contêineres no pod foram reiniciados. Números altos podem ser motivo de preocupação.
• Events: um registro de eventos importantes que aconteceram com esse pod, como a programação em um nó, o pull da imagem do contêiner e se ocorreram erros. A seção Events geralmente é onde você encontra as pistas diretas sobre por que um pod está falhando.

Assim como o comando kubectl get, é possível usar o comando kubectl describe para saber mais sobre vários tipos de recursos. Para uma lista completa dos recursos que você pode explorar, consulte kubectl describe na documentação do Kubernetes.

Fazer análises históricas com o Cloud Logging

Embora a ferramenta de linha de comando kubectl seja muito útil para inspecionar o estado ativo dos objetos do Kubernetes, a visualização dela geralmente é limitada ao momento atual. Para entender a causa raiz de um problema, muitas vezes é necessário investigar o que aconteceu ao longo do tempo. Quando você precisar desse contexto histórico, use o Cloud Logging.

O Cloud Logging agrega registros dos seus clusters do GKE, apps contêinerizados e outros serviços do Google Cloud .

Entender os principais tipos de registros para solução de problemas

O Cloud Logging coleta automaticamente vários tipos diferentes de registros do GKE que podem ajudar na solução de problemas:

• Registros de nó e de ambiente de execução (kubelet, containerd): os registros dos serviços de nó subjacentes. Como o kubelet gerencia o ciclo de vida de todos os pods no nó, os registros dele são essenciais para resolver problemas como inicializações de contêineres, eventos de falta de memória (OOM), falhas de sondagem e erros de montagem de volume. Esses registros também são cruciais para diagnosticar problemas no nível do nó, como um nó com status NotReady.

  Como o containerd gerencia o ciclo de vida dos contêineres, incluindo a extração de imagens, os registros dele são essenciais para resolver problemas que ocorrem antes que o kubelet possa iniciar o contêiner. Os registros do containerd ajudam a diagnosticar problemas no nível do nó no GKE, já que documentam as atividades específicas e os possíveis erros do ambiente de execução do contêiner.

• Registros do app (stdout, stderr): os streams de saída e erro padrão dos seus processos em contêineres. Esses registros são essenciais para depurar problemas específicos do app, como falhas, erros ou comportamento inesperado.

• Registros de auditoria: respondem "quem fez o quê, onde e quando?" para seu cluster. Eles rastreiam ações administrativas e chamadas de API feitas para o servidor da API Kubernetes, o que é útil para diagnosticar problemas causados por mudanças de configuração ou acesso não autorizado.

Cenários comuns de solução de problemas

Depois de identificar um problema, você pode consultar esses registros para saber o que aconteceu. Para ajudar você a começar, a análise de registros pode ajudar com estes problemas:

• Se um nó tiver um status NotReady, analise os registros dele. Os registros kubelet e containerd geralmente revelam a causa subjacente, como problemas de rede ou restrições de recursos.
• Se um novo nó não for provisionado e não entrar no cluster, analise os registros da porta serial do nó. Esses registros capturam a atividade de inicialização antecipada e de inicialização do kubelet antes que os agentes de registro do nó estejam totalmente ativos.
• Se um pod não tiver sido iniciado no passado, revise os registros do app para esse pod e verifique se há falhas. Se os registros estiverem vazios ou o pod não puder ser programado, verifique os registros de auditoria para eventos relevantes ou os registros de nós no nó de destino para encontrar pistas sobre pressão de recursos ou erros de extração de imagens.
• Se uma implantação crítica foi excluída e ninguém sabe o motivo, consulte os registros de auditoria da Atividade do administrador. Esses registros podem ajudar você a identificar qual usuário ou conta de serviço emitiu a chamada da API de exclusão, fornecendo um ponto de partida claro para sua investigação.

Como acessar registros

Use a Análise de registros para consultar, visualizar e analisar registros do GKE no console Google Cloud . A Análise de registros oferece opções avançadas de filtragem que ajudam a isolar o problema.

Para acessar e usar o Explorador de registros, siga estas etapas:

1. No console Google Cloud , acesse a página Explorador de registros.

   Acessar o Explorador de registros

2. No painel de consulta, insira uma consulta. Use a linguagem de consulta do Logging para escrever consultas segmentadas. Confira alguns filtros comuns para começar:

   Tipo de filtro	Descrição	Valor de exemplo
   resource.type	O tipo de recurso do Kubernetes.	k8s_cluster, k8s_node, k8s_pod, k8s_container
   log_id	O fluxo de registros do recurso.	stdout, stderr
   resource.labels.RESOURCE_TYPE.name	Filtre recursos com um nome específico. Substitua RESOURCE_TYPE pelo nome do recurso que você quer consultar. Por exemplo, namespace ou pod.	example-namespace-name, example-pod-name
   severity	O nível de gravidade do registro.	DEFAULT, INFO, WARNING, ERROR, CRITICAL
   jsonPayload.message=~	Uma pesquisa de expressão regular por texto na mensagem de registro.	scale.down.error.failed.to.delete.node.min.size.reached

   Por exemplo, para resolver problemas com um pod específico, talvez seja necessário isolar os registros de erros dele. Para ver apenas os registros com uma gravidade ERROR para esse pod, use a seguinte consulta:

   resource.type="k8s_container"
   resource.labels.pod_name="POD_NAME"
   resource.labels.namespace_name="NAMESPACE_NAME"
   severity=ERROR
   

   Substitua:

   • POD_NAME: o nome do pod com problemas.
   • NAMESPACE_NAME: o namespace em que o pod está. Se você não tiver certeza do namespace, revise a coluna Namespace na saída do comando kubectl get pods.

   Para mais exemplos, consulte Consultas relacionadas ao Kubernetes na documentação do Google Cloud Observability.

3. Clique em Executar consulta.

4. Para conferir a mensagem de registro completa, incluindo o payload JSON, metadados e carimbo de data/hora, clique na entrada de registro.

Para mais informações sobre os registros do GKE, consulte Sobre os registros do GKE.

Realizar monitoramento proativo com o Cloud Monitoring

Depois que um problema ocorre, a análise dos registros é uma etapa fundamental na solução de problemas. No entanto, um sistema verdadeiramente resiliente também exige uma abordagem proativa para identificar problemas antes que eles causem uma interrupção.

Para identificar problemas futuros de forma proativa e acompanhar os principais indicadores de desempenho ao longo do tempo, use o Cloud Monitoring. O Cloud Monitoring oferece painéis, métricas e recursos de alerta. Essas ferramentas ajudam você a encontrar taxas de erro em ascensão, aumento da latência ou restrições de recursos, o que ajuda a agir antes que os usuários sejam afetados.

Analisar métricas úteis

O GKE envia automaticamente um conjunto de métricas para o Cloud Monitoring. As seções a seguir listam algumas das métricas mais importantes para solução de problemas:

• Métricas de desempenho e integridade do contêiner
• Métricas de desempenho e integridade do nó
• Métricas de desempenho e integridade do pod

Para uma lista completa de métricas do GKE, consulte Métricas do sistema do GKE.

Métricas de desempenho e integridade do contêiner

Comece com essas métricas quando suspeitar de um problema com um app específico. Elas ajudam a monitorar a integridade do app, incluindo a descoberta de se um contêiner está reiniciando com frequência, ficando sem memória ou sendo limitado por limites de CPU.

Métricas de performance e integridade do nó

Analise essas métricas quando precisar diagnosticar problemas com a infraestrutura do GKE. Essas métricas são cruciais para entender a integridade e a capacidade geral dos nós, ajudando você a investigar se o nó está em risco ou sob pressão ou se ele tem memória suficiente para programar novos pods.

Métricas de performance e integridade do pod

Essas métricas ajudam a resolver problemas relacionados à interação de um pod com o ambiente dele, como rede e armazenamento. Use essas métricas quando precisar diagnosticar pods de inicialização lenta, investigar possíveis problemas de conectividade de rede ou gerenciar proativamente o armazenamento para evitar falhas de gravação de volumes cheios.

Visualizar métricas com o Metrics Explorer

Para visualizar o estado do seu ambiente do GKE, crie gráficos com base em métricas usando o Metrics Explorer.

Para usar o Metrics Explorer, siga estas etapas:

1. No console Google Cloud , acesse a página Metrics Explorer.

   Acessar o Metrics Explorer

2. No campo Métricas, selecione ou insira a métrica que você quer inspecionar.

3. Confira os resultados e observe as tendências ao longo do tempo.

Por exemplo, para investigar o consumo de memória dos pods em um namespace específico, faça o seguinte:

1. Na lista Selecionar uma métrica, escolha a métrica kubernetes.io/container/memory/used_bytes e clique em Aplicar.
2. Clique em Adicionar filtro e selecione namespace_name.
3. Na lista Valor, selecione o namespace que você quer investigar.
4. No campo Agregação, selecione Soma > pod_name e clique em OK. Essa configuração mostra uma linha de série temporal separada para cada pod.
5. Clique em Salvar gráfico.

O gráfico resultante mostra o uso da memória de cada pod ao longo do tempo, o que pode ajudar você a identificar visualmente pods com consumo de memória muito alto ou crescente.

O Metrics Explorer oferece muita flexibilidade na forma de criar as métricas que você quer visualizar. Para mais informações sobre as opções avançadas do Metrics Explorer, consulte Criar gráficos com o Metrics Explorer na documentação do Cloud Monitoring.

Criar alertas para detecção proativa de problemas

Para receber notificações quando algo der errado ou quando as métricas violarem determinados limites, configure políticas de alertas no Cloud Monitoring.

Por exemplo, para configurar uma política de alertas que notifica quando o limite de CPU do contêiner fica acima de 80% por cinco minutos, faça o seguinte:

1. No console Google Cloud , acesse a página Alertas.

   Acessar o alerta

2. Clique em Criar política.

3. Na caixa Selecionar uma métrica, filtre por CPU limit utilization e selecione a seguinte métrica: kubernetes.io/container/cpu/limit_utilization.

4. Clique em Aplicar.

5. Deixe o campo Adicionar um filtro em branco. Essa configuração aciona um alerta quando um cluster viola o limite.

6. Na seção Transformar dados, faça o seguinte:

   1. Na lista Janela contínua, selecione 1 minuto. Essa configuração significa que o Google Cloud calcula um valor médio a cada minuto.

   2. Na lista Função de janela contínua, selecione média.

      Ambas as configurações calculam a média de uso do limite de CPU para cada contêiner a cada minuto.

7. Clique em Próxima.

8. Na seção Configurar alerta, faça o seguinte:

   1. Em Tipo de condição, selecione Limite.
   2. Em Gatilho de alerta, selecione Qualquer série temporal viola.
   3. Em Posição do limite, selecione Acima do limite.
   4. Em Valor do limite, insira 0.8. Esse valor representa o limite de 80% que você quer monitorar.
   5. Clique em Opções avançadas.
   6. Na lista Janela de novo teste, selecione 5 min. Essa configuração significa que o alerta é acionado apenas se o uso da CPU permanecer acima de 80% por um período contínuo de cinco minutos, o que reduz alarmes falsos de picos breves.
   7. No campo Nome da condição, dê um nome descritivo para a condição.
   8. Clique em Próxima.

9. Na seção Configurar as notificações e finalizar o alerta, faça o seguinte:

   1. Na lista Canais de notificação, selecione o canal em que você quer receber o alerta. Se você não tiver um canal, clique em Gerenciar canais de notificação para criar um.
   2. No campo Nomear a política de alertas, dê a ela um nome claro e descritivo.
   3. Não mude os valores padrão dos outros campos.
   4. Clique em Próxima.

10. Revise a política e, se estiver tudo certo, clique em Criar política.

Para saber mais sobre outras maneiras de criar alertas, consulte a Visão geral dos alertas na documentação do Cloud Monitoring.

Acelere o diagnóstico com o Gemini Cloud Assist

Às vezes, a causa do problema não fica imediatamente óbvia, mesmo quando você usa as ferramentas discutidas nas seções anteriores. Investigar casos complexos pode ser demorado e exige conhecimento profundo. Para cenários como esse, o Gemini Cloud Assist pode ajudar. Ele pode detectar automaticamente padrões ocultos, anomalias e fornecer resumos para ajudar você a identificar rapidamente uma causa provável.

Acessar o Gemini Cloud Assist

Para acessar o Gemini Cloud Assist, siga estas etapas:

1. No console Google Cloud , acesse qualquer página.

2. Na barra de ferramentas do console Google Cloud , clique em spark Abrir ou fechar o chat do Gemini Cloud Assist.

   O painel Assistente do Cloud é aberto. Clique nos exemplos de comandos, se eles aparecerem, ou digite um comando no campo Digite um comando.

Confira exemplos de comandos

Para ajudar você a entender como o Gemini Cloud Assist pode ser útil, confira alguns exemplos de comandos:

Para saber mais, acesse os recursos a seguir:

• Saiba como escrever comandos melhores.
• Saiba como usar o painel do Gemini Cloud Assist.
• Leia Aspectos gerais do Gemini para o Google Cloud .
• Saiba como o Gemini para o Google Cloud usa seus dados.

Usar as investigações do Gemini Cloud Assist

Além do chat interativo, o Gemini Cloud Assist pode realizar análises mais automatizadas e detalhadas com o Gemini Cloud Assist Investigations. Esse recurso é integrado diretamente a fluxos de trabalho, como a Análise de registros, e é uma ferramenta poderosa de análise de causa raiz.

Quando você inicia uma investigação de um erro ou recurso específico, o Gemini Cloud Assist analisa registros, configurações e métricas. Ele usa esses dados para produzir observações e hipóteses classificadas sobre prováveis causas principais e, em seguida, fornece as próximas etapas recomendadas. Você também pode transferir esses resultados para um caso de suporte do Google Cloud para fornecer um contexto valioso que pode ajudar a resolver o problema mais rápido.

Para mais informações, consulte Investigações do Gemini Cloud Assist na documentação do Gemini.

Como fazer tudo funcionar em conjunto: exemplo de cenário de solução de problemas

Este exemplo mostra como usar uma combinação de ferramentas do GKE para diagnosticar e entender um problema comum do mundo real: um contêiner que falha repetidamente devido à falta de memória.

O cenário

Você é o engenheiro de plantão de um app da Web chamado product-catalog que é executado no GKE.

Sua investigação começa quando você recebe um alerta automático do Cloud Monitoring:

Alert: High memory utilization for container 'product-catalog' in 'prod' cluster.

Esse alerta informa que há um problema e indica que ele tem algo a ver com a carga de trabalho product-catalog.

Confirmar o problema no console do Google Cloud

Comece com uma visão geral das suas cargas de trabalho para confirmar o problema.

1. No console Google Cloud , acesse a página Cargas de trabalho e filtre pela carga de trabalho product-catalog.
2. Confira a coluna de status Pods. Em vez do 3/3 normal, você vê o valor mostrando um status não íntegro: 2/3. Esse valor informa que um dos pods do app não tem o status Ready.
3. Para investigar mais, clique no nome da carga de trabalho product-catalog para acessar a página de detalhes.
4. Na página de detalhes, confira a seção Pods gerenciados. Você identifica imediatamente um problema: a coluna Restarts do pod mostra 14, um número muito alto.

Esse alto número de reinicializações confirma que o problema está causando instabilidade no app e sugere que um contêiner está falhando nas verificações de integridade ou falhando.

Encontrar o motivo com comandos kubectl

Agora que você sabe que o app está reiniciando repetidamente, é preciso descobrir o motivo. O comando kubectl describe é uma boa ferramenta para isso.

1. Você recebe o nome exato do pod instável:

   kubectl get pods -n prod
   

   A saída é esta:

   NAME                             READY  STATUS            RESTARTS  AGE
   product-catalog-d84857dcf-g7v2x  0/1    CrashLoopBackOff  14        25m
   product-catalog-d84857dcf-lq8m4  1/1    Running           0         2h30m
   product-catalog-d84857dcf-wz9p1  1/1    Running           0         2h30m
   

2. Descreva o pod instável para conferir o histórico detalhado de eventos:

   kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod
   

3. Você analisa a saída e encontra pistas nas seções Last State e Events:

   Containers:
     product-catalog-api:
       ...
       State:          Waiting
         Reason:       CrashLoopBackOff
       Last State:     Terminated
         Reason:       OOMKilled
         Exit Code:    137
         Started:      Mon, 23 Jun 2025 10:50:15 -0700
         Finished:     Mon, 23 Jun 2025 10:54:58 -0700
       Ready:          False
       Restart Count:  14
   ...
   Events:
     Type     Reason     Age                           From                Message
     ----     ------     ----                          ----                -------
     Normal   Scheduled  25m                           default-scheduler   Successfully assigned prod/product-catalog-d84857dcf-g7v2x to gke-cs-cluster-default-pool-8b8a777f-224a
     Normal   Pulled     8m (x14 over 25m)             kubelet             Container image "us-central1-docker.pkg.dev/my-project/product-catalog/api:v1.2" already present on machine
     Normal   Created    8m (x14 over 25m)             kubelet             Created container product-catalog-api
     Normal   Started    8m (x14 over 25m)             kubelet             Started container product-catalog-api
     Warning  BackOff    3m (x68 over 22m)             kubelet             Back-off restarting failed container
   

   A saída fornece duas pistas importantes:

   • Primeiro, a seção Last State mostra que o contêiner foi encerrado com Reason: OOMKilled, o que indica que ele ficou sem memória. Esse motivo é confirmado pelo Exit Code: 137, que é o código de saída padrão do Linux para um processo que foi encerrado devido ao consumo excessivo de memória.
   • Em segundo lugar, a seção Events mostra um evento Warning: BackOff com a mensagem Back-off restarting failed container. Essa mensagem confirma que o contêiner está em um loop de falha, que é a causa direta do status CrashLoopBackOff que você viu antes.

Visualizar o comportamento com métricas

O comando kubectl describe informou o que aconteceu, mas o Cloud Monitoring pode mostrar o comportamento do seu ambiente ao longo do tempo.

1. No console Google Cloud , acesse o Metrics Explorer.
2. Você seleciona a métrica container/memory/used_bytes.
3. Filtre a saída para seu cluster, namespace e nome do pod específicos.

O gráfico mostra um padrão distinto: o uso de memória aumenta constantemente e depois cai abruptamente para zero quando o contêiner é encerrado por falta de memória e reiniciado. Essa evidência visual confirma um vazamento de memória ou um limite de memória insuficiente.

Encontrar a causa raiz nos registros

Agora você sabe que o contêiner está ficando sem memória, mas ainda não sabe exatamente por quê. Para descobrir a causa raiz, use o Explorador de registros.

1. No console Google Cloud , acesse o Explorador de registros.

2. Escreva uma consulta para filtrar os registros do contêiner específico de pouco antes do horário da última falha (que você viu na saída do comando kubectl describe):

   resource.type="k8s_container"
   resource.labels.cluster_name="example-cluster"
   resource.labels.namespace_name="prod"
   resource.labels.pod_name="product-catalog-d84857dcf-g7v2x"
   timestamp >= "2025-06-23T17:50:00Z"
   timestamp < "2025-06-23T17:55:00Z"
   

3. Nos registros, você encontra um padrão repetido de mensagens logo antes de cada falha:

   {
     "message": "Processing large image file product-image-large.jpg",
     "severity": "INFO"
   },
   {
     "message": "WARN: Memory cache size now at 248MB, nearing limit.",
     "severity": "WARNING"
   }
   

Essas entradas de registro informam que o app está tentando processar arquivos de imagem grandes carregando-os totalmente na memória, o que acaba esgotando o limite de memória do contêiner.

As descobertas

Ao usar as ferramentas juntas, você tem uma visão completa do problema:

• O alerta de monitoramento notificou você sobre um problema.
• O console Google Cloud mostrou que o problema estava afetando usuários (reinicializações).
• Os comandos kubectl apontaram o motivo exato das reinicializações (OOMKilled).
• O Metrics Explorer visualizou o padrão de vazamento de memória ao longo do tempo.
• O Explorador de registros revelou o comportamento específico que estava causando o problema de memória.

Agora você já pode implementar uma solução. Você pode otimizar o código do app para processar arquivos grandes de maneira mais eficiente ou, como uma correção de curto prazo, aumentar o limite de memória do contêiner (especificamente, o valor spec.containers.resources.limits.memory) no manifesto YAML da carga de trabalho.

A seguir

• Para receber conselhos sobre como resolver problemas específicos, consulte os guias de solução de problemas do GKE.

• Se você não encontrar uma solução para seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos:

  • Abrir um caso de suporte entrando em contato com o Cloud Customer Care.
  • Receber suporte da comunidade fazendo perguntas no StackOverflow e usando a tag google-kubernetes-engine para pesquisar problemas semelhantes. Você também pode participar do canal do Slack #kubernetes-engine para receber mais suporte da comunidade.
  • Abrir bugs ou solicitações de recursos usando o Issue Tracker público.