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


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

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

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 monitoramento do Cloud no Console do Google Cloud.

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 console do Google Cloud e na CLI do Google Cloud, mas você pode conferir isso clicando nos detalhes do cluster no console do Google Cloud 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.

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:

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

    kubectl get pods -n kube-system -l component=gke-metrics-agent
    
  2. 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
    
  3. 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.

    O resultado será assim:

      containerStatuses:
      ...
      lastState:
        terminated:
          ...
          exitCode: 1
          finishedAt: "2021-11-22T23:36:32Z"
          reason: OOMKilled
          startedAt: "2021-11-22T23:35:54Z"
    
  4. Adicionar um identificador de nó temporário ao nó com o agente de métricas com falha. É possível usar um identificador de nó permanente ou temporário. Recomendamos adicionar 20 MB a mais. Se o agente continuar falhando, execute novamente esse comando, substituindo o rótulo do nó por um que solicite uma quantidade maior de memória.

    Para atualizar um pool de nós com um identificador persistente, execute o seguinte comando:

    gcloud container node-pools update NODEPOOL_NAME \
        --cluster=CLUSTER_NAME \
        --node-labels=ADDITIONAL_MEMORY_NODE_LABEL \
        --location=COMPUTE_LOCATION
    

    Substitua:

    • NODEPOOL_NAME: o nome do pool de nós.
    • CLUSTER_NAME: o nome do cluster existente.
    • ADDITIONAL_MEMORY_NODE_LABEL: um dos outros identificadores de nó de memória, use um dos seguintes valores:
      • Para adicionar 10 MB: cloud.google.com/gke-metrics-agent-scaling-level=10
      • Para adicionar 20 MB: cloud.google.com/gke-metrics-agent-scaling-level=20
      • Para adicionar 50 MB: cloud.google.com/gke-metrics-agent-scaling-level=50
      • Para adicionar 100 MB: cloud.google.com/gke-metrics-agent-scaling-level=100
      • Para adicionar 200 MB: cloud.google.com/gke-metrics-agent-scaling-level=200
      • Para adicionar 500 MB: cloud.google.com/gke-metrics-agent-scaling-level=500
    • COMPUTE_LOCATION: o local do Compute Engine do cluster.

    Como alternativa, adicione um rótulo de nó temporário que não seja mantido após um upgrade usando o seguinte comando:

    kubectl label node/NODE_NAME \
    ADDITIONAL_MEMORY_NODE_LABEL --overwrite
    

    Substitua:

    • NODE_NAME: o nome do nó do agente de métricas afetado.
    • ADDITIONAL_MEMORY_NODE_LABEL: um dos outros identificadores de nó de memória, use um dos valores do exemplo anterior.

A seguir