Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Solução de problemas de métricas do sistema

Autopilot Standard

Esta página mostra como resolver problemas relacionados às métricas do sistema nos clusters do Google Kubernetes Engine (GKE).

As métricas do cluster não aparecem no Cloud Monitoring

Verifique se você ativou a API Monitoring e a API Logging no projeto. Você também precisa confirmar que consegue acessar o projeto na Visão geral do Cloud Monitoring noGoogle Cloud console.

Se o problema continuar, verifique estas possíveis causas:

Você ativou o monitoramento no cluster?

O monitoramento é ativado por padrão para clusters criados no Google Cloud console e na Google Cloud CLI, mas você pode conferir isso clicando nos detalhes do cluster no the Google Cloud console e executando o seguinte comando:
```
gcloud container clusters describe CLUSTER_NAME
```
A saída desse comando precisa incluir SYSTEM_COMPONENTS na lista de enableComponents na seção monitoringConfig, semelhante ao exemplo abaixo:
```
monitoringConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
```
Se o monitoramento não estiver ativado, execute o seguinte comando para ativá-lo:
```
gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
```
Quanto tempo faz desde que o cluster foi criado ou que o monitoramento foi ativado?

Pode levar até uma hora para que as métricas de um novo cluster comecem a aparecer no Cloud Monitoring.
Um heapster ou gke-metrics-agent (o coletor do OpenTelemetry) está em execução no cluster no namespace kube-system?

Talvez esse pod não consiga programar cargas de trabalho porque o cluster pode estar com poucos recursos. Confira se o Heapster ou o OpenTelemetry está em execução, executando kubectl get pods --namespace=kube-system e verificando os pods com heapster ou gke-metrics-agent no nome.
O plano de controle do cluster pode se comunicar com os nós?

O Cloud Monitoring depende dessa comunicação. Para verificar se o plano de controle está se comunicando com os nós, execute o seguinte comando:
```
kubectl logs POD_NAME
```
Se esse comando retornar um erro, os túneis SSH podem estar causando o problema. Para ver as etapas de solução de problemas, consulte Resolver problemas de SSH.

Identificar e corrigir problemas de permissões para gravar métricas

O GKE usa contas de serviço do IAM anexadas aos nós para executar tarefas do sistema, como geração de registros e monitoramento. No mínimo, essas contas de serviço de nó precisam ter o papel de conta de serviço de nó padrão do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no projeto. Por padrão, o GKE usa a conta de serviço padrão do Compute Engine, que é criada automaticamente no projeto, como a conta de serviço do nó.

Se a organização aplicar a iam.automaticIamGrantsForDefaultServiceAccounts restrição de política da organização, a conta de serviço padrão do Compute Engine no projeto poderá não receber automaticamente as permissões necessárias para o GKE.

Para identificar o problema, verifique se há erros 401 na carga de trabalho de monitoramento do sistema no cluster:
```
[[ $(kubectl logs -l k8s-app=gke-metrics-agent -n kube-system -c gke-metrics-agent | grep -cw "Received 401") -gt 0 ]] && echo "true" || echo "false"
```
Se a saída for true, a carga de trabalho do sistema está apresentando erros 401, que indicam falta de permissões. Se a saída for false, pule o restante dessas etapas e tente um procedimento de solução de problemas diferente.

Para conceder o papel roles/container.defaultNodeServiceAccount à conta de serviço padrão do Compute Engine, siga estas etapas:

Console

Acesse a página Bem-vindo:
Acessar a página de boas-vindas
No campo Número do projeto, clique em Copiar para a área de transferência.
Acesse a página do IAM:
Acessar IAM
Clique em Conceder acesso.
No campo Novos participantes, especifique o seguinte valor:
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```
Substitua PROJECT_NUMBER pelo número do projeto que você copiou.
No menu Selecionar um papel, escolha o papel Conta de serviço de nó padrão do Kubernetes Engine.
Clique em Salvar.

gcloud

Encontre seu Google Cloud número do projeto:
```
gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"
```
Substitua PROJECT_ID pela ID do seu projeto.

O resultado será assim:
```
12345678901
```

Conceda o papel roles/container.defaultNodeServiceAccount à conta de serviço padrão do Compute Engine:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

Substitua PROJECT_NUMBER pelo número do projeto da etapa anterior.

Confirmar se o agente de métricas tem memória suficiente

Se você já tentou as etapas de solução de problemas anteriores e as métricas ainda não estão aparecendo, o agente de métricas pode ter memória insuficiente.

Na maioria dos casos, a alocação padrão de recursos para o agente de métricas do GKE é suficiente. No entanto, se o DaemonSet falhar repetidamente, verifique o motivo do encerramento com as seguintes instruções:

Consiga os nomes dos pods do agente de métricas do GKE:

kubectl get pods -n kube-system -l component=gke-metrics-agent

Encontre o pod com o status CrashLoopBackOff.

O resultado será assim:

NAME                    READY STATUS           RESTARTS AGE
gke-metrics-agent-5857x 0/1   CrashLoopBackOff 6        12m

Descreva o pod com o status CrashLoopBackOff:

kubectl describe pod POD_NAME -n kube-system

Substitua o POD_NAME pelo nome do pod da etapa anterior.

Se o motivo do encerramento do pod for OOMKilled, o agente vai precisar de mais memória.