Risoluzione dei problemi relativi alle metriche di sistema

Questa pagina mostra come risolvere i problemi relativi alle metriche di sistema nei cluster Google Kubernetes Engine (GKE).

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.

Le metriche del cluster non vengono visualizzate in Cloud Monitoring

Assicurati di avere aver abilitato l'API Monitoring e API Logging nel tuo progetto. Devi anche verificare di essere in grado di visualizzare il progetto nella panoramica di Cloud Monitoring nella console Google Cloud.

Se il problema persiste, controlla le seguenti potenziali cause:

  • Hai abilitato il monitoraggio sul cluster?

    Il monitoraggio è abilitato per impostazione predefinita per i cluster creati dalla console Google Cloud e da Google Cloud CLI, ma puoi verificarlo facendo clic sui dettagli del cluster nella console Google Cloud eseguendo il seguente comando:

    gcloud container clusters describe CLUSTER_NAME

    L'output di questo comando deve includere SYSTEM_COMPONENTS nell'elenco di enableComponents nella sezione monitoringConfig, in modo simile all'esempio seguente:

    monitoringConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS

    Se il monitoraggio non è abilitato, esegui questo comando per abilitarlo:

    gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM

  • Quanto tempo è passato dalla creazione del cluster o dall'attivazione del monitoraggio?

    Potrebbero essere necessarie fino a un'ora prima che le metriche di un nuovo cluster inizino a essere visualizzate in Cloud Monitoring.

  • È in esecuzione un heapster o gke-metrics-agent (OpenTelemetry Collector) nel tuo cluster nello spazio dei nomi kube-system?

    La pianificazione dei carichi di lavoro di questo pod potrebbe non riuscire perché le risorse del tuo cluster sono in esaurimento. Controllare se Heapster o OpenTelemetry sono in esecuzione eseguendo kubectl get pods --namespace=kube-system e controllando per i pod che contengono heapster o gke-metrics-agent nel nome.

  • Il piano di controllo del cluster è in grado di comunicare con i nodi?

    Cloud Monitoring si basa su questa comunicazione. Puoi controllare se il piano di controllo comunica con i nodi eseguendo seguente comando:

    kubectl logs POD_NAME

    Se questo comando restituisce un errore, è possibile che i tunnel SSH siano la causa problema. Per la procedura di risoluzione dei problemi, consulta la sezione Risolvere i problemi relativi a SSH.

Verifica che l'agente delle metriche abbia memoria sufficiente

Se hai provato i passaggi precedenti per la risoluzione dei problemi e le metriche non vengono visualizzati, l'agente delle metriche potrebbe avere memoria insufficiente.

Nella maggior parte dei casi, l'allocazione predefinita delle risorse l'agente delle metriche è sufficiente. Tuttavia, se il DaemonSet si arresta ripetutamente in modo anomalo, può verificare il motivo della chiusura seguendo queste istruzioni:

  1. Recupera i nomi dei pod dell'agente delle metriche GKE:

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

  2. Trova il pod con lo stato CrashLoopBackOff.

    L'output è simile al seguente:

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

  3. Descrivi il pod con lo stato CrashLoopBackOff:

    kubectl describe pod POD_NAME -n kube-system

    Sostituisci POD_NAME con il nome del pod nel passaggio precedente.

    Se il motivo dell'interruzione del pod è OOMKilled, l'agente ha bisogno di memoria aggiuntiva.

    L'output è simile al seguente:

      containerStatuses:
  ...
  lastState:
    terminated:
      ...
      exitCode: 1
      finishedAt: "2021-11-22T23:36:32Z"
      reason: OOMKilled
      startedAt: "2021-11-22T23:35:54Z"

  4. Aggiungi un'etichetta al nodo con l'agente delle metriche con errori. Puoi utilizza un'etichetta del nodo permanente o temporanea. Ti consigliamo di provare ad aggiungere altri 20 MB. Se l'agente continua ad arrestarsi in modo anomalo, puoi eseguire questo di nuovo, sostituendo l'etichetta del nodo con una che richiede una quantità maggiore di memoria aggiuntiva.

    Per aggiornare un pool di nodi con un'etichetta permanente, esegui questo comando:

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

    Sostituisci quanto segue:

    • NODEPOOL_NAME: il nome del pool di nodi.
    • CLUSTER_NAME: il nome del cluster esistente.
    • ADDITIONAL_MEMORY_NODE_LABEL: una delle etichette dei nodi di memoria aggiuntive. Utilizza uno dei seguenti valori:
      • Per aggiungere 10 MB: cloud.google.com/gke-metrics-agent-scaling-level=10
      • Per aggiungere 20 MB: cloud.google.com/gke-metrics-agent-scaling-level=20
      • Per aggiungere 50 MB: cloud.google.com/gke-metrics-agent-scaling-level=50
      • Per aggiungere 100 MB: cloud.google.com/gke-metrics-agent-scaling-level=100
      • Per aggiungere 200 MB: cloud.google.com/gke-metrics-agent-scaling-level=200
      • Per aggiungere 500 MB: cloud.google.com/gke-metrics-agent-scaling-level=500
    • COMPUTE_LOCATION: il Località di Compute Engine nel cluster.

    In alternativa, puoi aggiungere un'etichetta del nodo temporanea che vengono mantenuti dopo un upgrade utilizzando il seguente comando:

    kubectl label node/NODE_NAME \
ADDITIONAL_MEMORY_NODE_LABEL --overwrite

    Sostituisci quanto segue:

    • NODE_NAME: il nome del nodo dell'agente di misurazione interessato.
    • ADDITIONAL_MEMORY_NODE_LABEL: uno degli altri le etichette dei nodi di memoria, utilizza uno dei valori della precedente esempio.

Passaggi successivi