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

Risoluzione dei problemi relativi alle metriche di sistema

Autopilot Standard

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

Le metriche del cluster non vengono visualizzate in Cloud Monitoring

Assicurati di aver abilitato l'API Monitoring e l' API Logging nel tuo progetto. Dovresti anche verificare di poter visualizzare il tuo progetto nella panoramica di Cloud Monitoring nella Google Cloud console.

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 Google Cloud console e dalla Google Cloud CLI, ma puoi verificarlo facendo clic sui dettagli del cluster in the Google Cloud console 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, come nel seguente esempio:
```
monitoringConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
```
Se il monitoraggio non è abilitato, esegui il seguente comando per abilitarlo:
```
gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
```
Da quanto tempo è stato creato il cluster o è stato abilitato il monitoraggio?

Potrebbe essere necessaria fino a un'ora prima che le metriche di un nuovo cluster inizino a essere visualizzate in Cloud Monitoring.
Un pod heapster o gke-metrics-agent (l'agente di raccolta OpenTelemetry) è in esecuzione nel cluster nello spazio dei nomi kube-system?

Questo pod potrebbe non riuscire a pianificare i carichi di lavoro perché il cluster sta esaurendo le risorse. Verifica se Heapster o OpenTelemetry è in esecuzione eseguendo kubectl get pods --namespace=kube-system e controllando i pod con 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 verificare se il piano di controllo comunica con i nodi eseguendo il seguente comando:
```
kubectl logs POD_NAME
```
Se questo comando restituisce un errore, i tunnel SSH potrebbero essere la causa del problema. Per i passaggi di risoluzione dei problemi, consulta Risolvere i problemi relativi a SSH.

Identificare e risolvere i problemi di autorizzazione per la scrittura delle metriche

GKE utilizza i service account IAM collegati ai nodi per eseguire attività di sistema come il logging e il monitoraggio. Questi service account dei nodi devono avere almeno il ruolo Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) nel tuo progetto. Per impostazione predefinita, GKE utilizza il service account predefinito di Compute Engine, creato automaticamente nel progetto, come account di servizio dei nodi.

Se la tua organizzazione applica il iam.automaticIamGrantsForDefaultServiceAccounts vincolo della policy dell'organizzazione, il account di servizio Compute Engine predefinito nel tuo progetto potrebbe non ottenere automaticamente le autorizzazioni richieste per GKE.

Per identificare il problema, controlla la presenza di errori 401 nel carico di lavoro di monitoraggio del sistema nel 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 l'output è true, il carico di lavoro di sistema riscontra errori 401, che indicano una mancanza di autorizzazioni. Se l'output è false, salta il resto di questi passaggi e prova una procedura di risoluzione dei problemi diversa.

Per concedere il ruolo roles/container.defaultNodeServiceAccount al account di servizio predefinito di Compute Engine, completa i seguenti passaggi:

Console

Vai alla pagina Benvenuto:
Vai a Benvenuto
Nel campo Numero progetto, fai clic Copia negli appunti.
Vai alla pagina IAM:
Vai a IAM
Fai clic su Concedi l'accesso.
Nel campo Nuove entità, specifica il seguente valore:
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```
Sostituisci PROJECT_NUMBER con il numero del progetto che hai copiato.
Nel menu Seleziona un ruolo, seleziona il Kubernetes Engine Default Node Service Account ruolo.
Fai clic su Salva.

gcloud

Trova il tuo Google Cloud numero di progetto:
```
gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"
```
Sostituisci PROJECT_ID con l'ID progetto.

L'output è simile al seguente:
```
12345678901
```

Concedi il ruolo roles/container.defaultNodeServiceAccount al account di servizio predefinito di Compute Engine:

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

Sostituisci PROJECT_NUMBER con il numero del progetto dal passaggio precedente.

Verificare che l'agente delle metriche abbia memoria sufficiente

Se hai provato i passaggi di risoluzione dei problemi precedenti e le metriche non vengono ancora visualizzate, l'agente delle metriche potrebbe non avere memoria sufficiente.

Nella maggior parte dei casi, l'allocazione predefinita delle risorse all'agente delle metriche GKE è sufficiente. Tuttavia, se il DaemonSet si arresta in modo anomalo ripetutamente, puoi controllare il motivo della terminazione seguendo queste istruzioni:

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

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

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

Descrivi il pod con lo stato CrashLoopBackOff:

kubectl describe pod POD_NAME -n kube-system

Sostituisci POD_NAME con il nome del pod del passaggio precedente.

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