Risolvere i problemi di osservabilità di Google Distributed Cloud

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

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

Cloud Audit Logs non vengono raccolti

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

Se i log di audit di Cloud sono abilitati, le autorizzazioni sono il motivo più comune per cui i log non vengono raccolti. In questo scenario, i messaggi di errore relativi all'autorizzazione negata vengono visualizzati nel contenitore proxy di Cloud Audit Logs.

Il container proxy di Cloud Audit Logs viene eseguito come DaemonSet in tutti i cluster Google Distributed Cloud.

Se visualizzi errori di autorizzazione, segui i passaggi per risolvere i problemi di autorizzazione.

kube-state-metrics metriche non vengono raccolte

kube-state-metrics (KSM) viene eseguito come deployment a singola replica nel cluster e genera metriche su quasi tutte le risorse del cluster. Quando KSM e gke-metrics-agent viene eseguito sullo stesso nodo, c'è un rischio maggiore di interruzione tra gli agenti delle metriche su tutti i nodi.

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

Se mancano metriche KSM, 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 di riepilogo dell'API come kubernetes.io/anthos/container/... . Si tratta di una pipeline separata con KSM. Verifica che il pod KSM non sia limitato da risorse insufficienti.
    • Se queste metriche di riepilogo dell'API non sono disponibili per KSM, gke-metrics-agent sullo stesso nodo probabilmente presenta lo stesso problema.
  • Nel cluster, controlla lo stato e i log del pod KSM e gke-metrics-agent pod sullo stesso nodo con KSM.

Loop arresto anomalo di kube-state-metrics

Sintomo

Cloud Monitoring non fornisce metriche di kube-state-metrics (KSM).

Causa

Questo scenario è più probabile che si verifichi in cluster di grandi dimensioni o con grandi quantità di risorse. KSM viene eseguito come deployment con una singola replica ed elenca quasi tutte le risorse del cluster, come pod, deployment, DaemonSet, ConfigMap, secret e PersistentVolume. Le metriche vengono generate su ciascuna di queste risorse di oggetti strutturati. Se una delle risorse contiene 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 Google Distributed Cloud.

Il limite predefinito di CPU e memoria è stato aumentato nelle ultime versioni di Google Distributed Cloud, 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, rivedi le seguenti passaggi:

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

Se confermi che il problema è l'esaurimento della memoria, utilizza uno dei seguenti metodi le seguenti soluzioni:

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

  • Riduci il numero di metriche del KSM.

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

    Per le versioni di Google Distributed Cloud 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 verifica solo problemi di memoria insufficiente sul nodo in cui kube-state-metrics esiste, la causa è un numero elevato di kube-state-metrics metriche di valutazione. Per limitare il problema, fare lo scale down di stackdriver-operator e modifica KSM per esporre un piccolo insieme di metriche necessarie, come descritto nella sezione precedente. Ricorda di eseguire il ridimensionamento verso il basso stackdriver-operator dopo l'upgrade del cluster a Google Distributed Cloud 1.13, in cui KSM per impostazione predefinita espone un numero minore di Core Metric.

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

Loop arresto anomalo di stackdriver-metadata-agent

Sintomo

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

Causa

Il caso più comune di loop di arresto anomalo di stackdriver-metadata-agent è dovuto a eventi di memoria esaurita. 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 con una singola replica, 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 Google Distributed Cloud.

Il limite predefinito di CPU e memoria è stato aumentato negli ultimi Google Distributed Cloud, 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, rivedi le seguenti passaggi:

  • Utilizza kubectl describe pod o kubectl get pod -o yaml e controlla il messaggio di stato dell'errore.
  • Controlla la metrica di consumo e utilizzo della memoria per stackdriver-metadata-agent e verifica prima se stai raggiungendo il limite per eseguire il riavvio.
Se confermi che i problemi di memoria esaurita stanno causando problemi, aumenta il il limite di memoria Campo resourceAttrOverride della risorsa personalizzata di Stackdriver.

metrics-server loop di arresti anomali

Sintomo

Horizontal Pod Autoscaler e kubectl top non funzionano nel tuo 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 elevata densità di pod.

Questo problema potrebbe verificarsi in qualsiasi versione di Google Distributed Cloud.

Correzione e soluzione alternativa

Aumenta i limiti delle risorse del server delle metriche. In Google Distributed Cloud versione 1.13 e successive, lo spazio dei nomi di metrics-server e la relativa configurazione è stata spostata da kube-system a gke-managed-metrics-server.

Per Google Distributed Cloud, la modifica della configurazione della funzionalità di monitoraggio verrà annullata in caso di aggiornamento o upgrade del cluster. Dovrai applicare nuovamente le modifiche alla configurazione. Per ovviare a questo limite, riduci metrics-server-operator e modifica manualmente il pod metrics-server.

Passaggi successivi

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