Risolvere i problemi di osservabilità di GKE su Bare Metal

Questo documento ti aiuta a risolvere i problemi di osservabilità in GKE su Bare Metal. Se riscontri uno di questi problemi, esamina le correzioni suggerite e le soluzioni alternative.

Se hai bisogno di ulteriore aiuto, contatta l'Assistenza Google.

Cloud Audit Logs non viene raccolto

Cloud Audit Logs è abilitato per impostazione predefinita, a meno che non sia impostato un flag disableCloudAuditLogging nella sezione clusterOperations della configurazione del cluster.

Se Cloud Audit Logs è abilitato, le autorizzazioni sono il motivo più comune per cui i log non vengono raccolti. In questo scenario, i messaggi di errore di autorizzazione negata vengono visualizzati nel container proxy di Cloud Audit Logs.

Il container proxy Cloud Audit Logs viene eseguito come DaemonSet in tutti i cluster GKE su Bare Metal.

Se vedi errori di autorizzazione, segui i passaggi per risolvere i problemi relativi alle autorizzazioni.

kube-state-metrics metriche non vengono raccolte

kube-state-metrics (KSM) viene eseguito come deployment di replica singola nel cluster e genera metriche su quasi tutte le risorse nel cluster. Quando KSM e gke-metrics-agent vengono eseguiti sullo stesso nodo, esiste un rischio maggiore di interruzione degli agenti delle metriche su tutti i nodi.

Le metriche KSM hanno nomi che seguono lo schema di kube_<ResourceKind>, ad esempio kube_pod_container_info. Le metriche che iniziano con kube_onpremusercluster_ provengono dal controller del cluster on-premise, non da KSM.

Se mancano metriche KSM, consulta i seguenti passaggi per la risoluzione dei problemi:

  • In Cloud Monitoring, controlla il conteggio di CPU, memoria e riavvii di KSM utilizzando le metriche dell'API di riepilogo come kubernetes.io/anthos/container/... . Questa è una pipeline separata con KSM. Verifica che il pod KSM non sia limitato da risorse insufficienti.
    • Se queste metriche dell'API di riepilogo non sono disponibili per KSM, è probabile che anche gke-metrics-agent sullo stesso nodo presenti lo stesso problema.
  • Nel cluster, controlla lo stato e i log del pod KSM e del pod gke-metrics-agent sullo stesso nodo con KSM.

Loop di arresto anomalo di kube-state-metrics

Sintomo

Nessuna metrica di kube-state-metrics (KSM) è disponibile in Cloud Monitoring.

Causa

Questo scenario è più probabile che si verifichi in cluster di grandi dimensioni o in cluster con grandi quantità di risorse. KSM viene eseguito come un deployment a replica singola ed elenca quasi tutte le risorse nel cluster, come pod, deployment, DaemonSet, oggetti ConfigMap, secret e PersistentVolume. Le metriche vengono generate su ciascuno di questi oggetti delle risorse. Se una delle risorse ha molti oggetti, ad esempio un cluster con oltre 10.000 pod, KSM potrebbe esaurire la memoria.

Versioni interessate

Questo problema potrebbe verificarsi in qualsiasi versione di GKE su Bare Metal.

Il limite predefinito di CPU e memoria è stato aumentato nelle ultime versioni di GKE su Bare Metal, pertanto questi problemi relativi alle risorse dovrebbero essere meno comuni.

Correzione e soluzione alternativa

Per verificare se il problema è dovuto a problemi di memoria esaurita, procedi nel seguente modo:

  • Utilizza kubectl describe pod o kubectl get pod -o yaml e controlla il messaggio di stato di errore.
  • Controlla il consumo e la metrica di utilizzo della memoria per KSM e verifica se sta raggiungendo il limite prima di riavviare.

Se confermi che il problema è l'esaurimento della memoria, utilizza una delle seguenti soluzioni:

  • Aumenta la richiesta e il limite di memoria per KSM.

    Per regolare la CPU e la memoria di KSM, utilizza il valore resourceOverride della risorsa personalizzata Stackdriver per kube-state-metrics.

  • Riduci il numero di metriche di KSM.

    Per GKE su Bare Metal 1.13, KSM espone solo un numero inferiore di metriche denominate metriche principali per impostazione predefinita. Questo comportamento indica che l'utilizzo delle risorse è inferiore rispetto alle versioni precedenti, ma è possibile seguire la stessa procedura per ridurre ulteriormente il numero di metriche KSM.

    Per le versioni di GKE su Bare Metal precedenti alla 1.13, KSM utilizza i flag predefiniti. Questa configurazione espone un numero elevato di metriche.

Loop di arresto anomalo di gke-metrics-agent

Se gke-metrics-agent riscontra problemi di esaurimento della memoria solo sul nodo in cui sono presenti kube-state-metrics, la causa è un numero elevato di metriche kube-state-metrics. Per ridurre questo problema, fare lo scale down di stackdriver-operator e modifica KSM per esporre un piccolo insieme di metriche necessarie, come descritto nella sezione precedente. Ricordati di fare lo scale up di stackdriver-operator dopo l'upgrade del cluster a GKE su Bare Metal 1.13, dove KSM per impostazione predefinita espone un numero inferiore di metriche principali.

Per i problemi non correlati a eventi di esaurimento della memoria, controlla i log dei pod di gke-metric-agent. Puoi regolare la CPU e la memoria per tutti i pod gke-metrics-agent aggiungendo il campo resourceAttrOverride alla risorsa personalizzata Stackdriver.

Loop di arresto anomalo di stackdriver-metadata-agent

Sintomo

Non è disponibile alcuna etichetta dei metadati di sistema quando filtri le metriche in Cloud Monitoring.

Causa

Il caso più comune di arresto anomalo di stackdriver-metadata-agent in loop è dovuto a eventi di esaurimento della memoria. Questo evento è simile a kube-state-metrics. Anche se stackdriver-metadata-agent non elenca tutte le risorse, elenca comunque tutti gli oggetti per i tipi di risorse pertinenti come Pod, Deployment e NetworkPolicy. L'agente viene eseguito come deployment di replica singola, il che aumenta il rischio di eventi di esaurimento della memoria se il numero di oggetti è troppo elevato.

Versione interessata

Questo problema potrebbe verificarsi in qualsiasi versione di GKE su Bare Metal.

Il limite predefinito di CPU e memoria è stato aumentato nelle ultime versioni di GKE su Bare Metal, pertanto questi problemi relativi alle risorse dovrebbero essere meno comuni.

Correzione e soluzione alternativa

Per verificare se il problema è dovuto a problemi di memoria esaurita, procedi nel seguente modo:

  • Utilizza kubectl describe pod o kubectl get pod -o yaml e controlla il messaggio di stato di errore.
  • Controlla la metrica di utilizzo e utilizzo della memoria per stackdriver-metadata-agent e verifica che stia raggiungendo il limite prima di riavviare.
Se confermi che i problemi di memoria insufficiente sono la causa, aumenta il limite di memoria nel campo resourceAttrOverride della risorsa personalizzata Stackdriver.

Loop di arresto anomalo di metrics-server

Sintomo

Horizontal Pod Autoscaler e kubectl top non funzionano nel cluster.

Causa e versioni interessate

Questo problema non è molto comune, ma è causato da errori di memoria insufficiente in cluster di grandi dimensioni o in cluster con un'alta densità di pod.

Questo problema potrebbe verificarsi in qualsiasi versione di GKE su Bare Metal.

Correzione e soluzione alternativa

Aumenta i limiti delle risorse del server delle metriche. In GKE su Bare Metal versione 1.13 e successive, lo spazio dei nomi di metrics-server e la relativa configurazione sono stati spostati da kube-system a gke-managed-metrics-server.

Per GKE su Bare Metal, la modifica della configurazione di nanny viene ripristinata in caso di aggiornamento o upgrade del cluster. Dovrai riapplicare le modifiche alla configurazione. Per ovviare a questo limite, fai lo scale down di metrics-server-operator e modifica manualmente il pod metrics-server.

Passaggi successivi

Se hai bisogno di ulteriore aiuto, contatta l'Assistenza Google.