Risolvere i problemi di osservabilità di GDCV per Bare Metal

Questo documento ti aiuta a risolvere i problemi di osservabilità in Google Distributed Cloud Virtual for Bare Metal. Se riscontri uno di questi problemi, esamina le correzioni e le soluzioni suggerite.

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

Cloud Audit Logs non vengono raccolti

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 Google Distributed Cloud Virtual for Bare Metal.

Se vengono visualizzati errori di autorizzazione, segui i passaggi per la risoluzione dei 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 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 le metriche KSM non sono presenti, rivedi 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/... . Si tratta di una pipeline separata con KSM. Verifica che il pod di 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 di KSM e del pod gke-metrics-agent sullo stesso nodo con KSM.

Loop arresto anomalo di kube-state-metrics

Sintomo

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

Causa

Questo scenario ha maggiori probabilità di verificarsi in cluster di grandi dimensioni o con grandi quantità di risorse. KSM viene eseguito come un singolo deployment di replica ed elenca quasi tutte le risorse nel cluster come pod, deployment, DaemonSet, ConfigMap, secret e PersistentVolume. Le metriche vengono generate su ciascuno di questi oggetti. 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 si può verificare in qualsiasi versione di Google Distributed Cloud Virtual for Bare Metal.

I limiti predefiniti di CPU e memoria sono stati aumentati nelle ultime versioni di Google Distributed Cloud Virtual for 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 esaurimento della memoria, 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 consumo della memoria per KSM e verifica se ha raggiunto il limite prima di riavviare.

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

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

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

  • Riduci il numero di metriche di KSM.

    Per Google Distributed Cloud Virtual for Bare Metal 1.13, KSM espone solo un numero inferiore di metriche chiamate metriche principali per impostazione predefinita. Questo comportamento indica che l'utilizzo delle risorse è inferiore rispetto alle versioni precedenti, ma puoi seguire la stessa procedura per ridurre ulteriormente il numero di metriche KSM.

    Per le versioni Google Distributed Cloud Virtual for Bare Metal precedenti alla 1.13, KSM utilizza i flag predefiniti. Questa configurazione espone un numero elevato di metriche.

Loop arresto anomalo di gke-metrics-agent

Se gke-metrics-agent si verificano problemi di esaurimento della memoria solo nel nodo in cui si trova kube-state-metrics, la causa è un numero elevato di metriche kube-state-metrics. Per limitare questo problema, fare lo scale down di stackdriver-operator e modifica KSM per esporre un piccolo set di metriche necessarie, come descritto nella sezione precedente. Ricordati di fare lo scale up di stackdriver-operator dopo l'upgrade del cluster a Google Distributed Cloud Virtual for Bare Metal 1.13, dove KSM per impostazione predefinita espone un numero inferiore di metriche principali.

Per 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 di Stackdriver.

Loop arresto anomalo di stackdriver-metadata-agent

Sintomo

Quando filtri le metriche in Cloud Monitoring, non è disponibile nessuna etichetta dei metadati di sistema.

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 un singolo deployment di replica, il che aumenta il rischio di eventi di esaurimento della memoria se il numero di oggetti è troppo elevato.

Versione interessata

Questo problema si può verificare in qualsiasi versione di Google Distributed Cloud Virtual for Bare Metal.

Il limite predefinito di CPU e memoria è stato aumentato nelle ultime versioni di Google Distributed Cloud Virtual for 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 esaurimento della memoria, 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 della memoria e utilizzo per stackdriver-metadata-agent e verifica se ha raggiunto il limite prima di riavviare.
Se confermi che sono a causa di problemi di memoria insufficiente, aumenta il limite di memoria nel campo resourceAttrOverride della risorsa personalizzata di Stackdriver.

Loop 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 esaurimento della memoria in cluster di grandi dimensioni o in cluster con un'alta densità di pod.

Questo problema si può verificare in qualsiasi versione di Google Distributed Cloud Virtual for Bare Metal.

Correzione e soluzione alternativa

Aumenta i limiti delle risorse del server delle metriche. In Google Distributed Cloud Virtual for 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 Google Distributed Cloud Virtual for Bare Metal, la modifica della configurazione di tata veniva ripristinata in caso di aggiornamento o upgrade del cluster. Dovrai riapplicare le modifiche alla configurazione. Per aggirare 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.