Risolvere i problemi di osservabilità di Google Distributed Cloud

Per ripristinare audit log, metriche o etichette dei metadati mancanti nei cluster Google Distributed Cloud, puoi utilizzare le seguenti correzioni per i problemi comuni di osservabilità. La maggior parte di questi problemi è causata da errori di autorizzazione o da arresti anomali per memoria insufficiente in componenti come kube-state-metrics in cluster di grandi dimensioni. Alcuni problemi riguardano anche Horizontal Pod Autoscaler e kubectl top.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare Assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

  • Requisiti per l'apertura di una richiesta di assistenza.
  • Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
  • Componenti supportati.

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 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.

Un'altra possibile causa è che il progetto potrebbe aver raggiunto il limite di account di servizio supportati. Consulta Fuga di dati account di servizio di Cloud Audit Logs.

kube-state-metrics metrica non viene raccolta

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

Le metriche KSM hanno nomi che seguono il pattern 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, consulta i seguenti passaggi per la risoluzione dei problemi:

  • In Cloud Monitoring, controlla la CPU, la memoria e il conteggio dei 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 API di riepilogo non sono disponibili per KSM, probabilmente anche gke-metrics-agent sullo stesso nodo ha 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 arresti anomali di kube-state-metrics

Sintomo

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

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 ciascuno di questi oggetti risorsa. 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 Google Distributed Cloud.

Il limite predefinito di CPU e memoria è stato aumentato nelle ultime versioni di Google Distributed Cloud, quindi questi problemi relativi alle risorse dovrebbero essere meno comuni.

Correzione e soluzione alternativa

Per verificare se il problema è dovuto a problemi di out of memory, segui questi 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 KSM e verifica se raggiunge il limite prima del riavvio.

Se confermi che i problemi di out of memory sono la causa, utilizza una delle seguenti soluzioni:

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

  • Riduci il numero di metriche da KSM.

    Per Google Distributed Cloud 1.13, KSM espone per impostazione predefinita solo un numero ridotto di metriche, chiamate metriche principali. Questo comportamento significa 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 Google Distributed Cloud precedenti alla 1.13, KSM utilizza i flag predefiniti. Questa configurazione espone un numero elevato di metriche.

Loop di arresti anomali di gke-metrics-agent

Se gke-metrics-agent riscontra problemi di out of memory solo sul nodo in cui esiste kube-state-metrics, la causa è un numero elevato di metriche kube-state-metrics. Per mitigare questo problema, fare lo scale down di stackdriver-operator e modifica KSM in modo da esporre un piccolo insieme di metriche necessarie, come descritto nella sezione precedente. Ricorda di fare lo scale up di stackdriver-operator dopo l'upgrade del cluster a Google Distributed Cloud 1.13, dove KSM espone per impostazione predefinita un numero inferiore di metriche principali.

Per i problemi non correlati a eventi di out of memory, 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 arresti anomali di stackdriver-metadata-agent

Sintomo

Nessuna etichetta dei metadati di sistema è disponibile quando si filtrano le metriche in Cloud Monitoring.

Causa

Il caso più comune di loop di arresto anomalo di stackdriver-metadata-agent è dovuto a eventi di out of memory. 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 una singola replica, il che aumenta il rischio di eventi di out of memory 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 nelle ultime versioni di Google Distributed Cloud, quindi questi problemi relativi alle risorse dovrebbero essere meno comuni.

Correzione e soluzione alternativa

Per verificare se il problema è dovuto a problemi di out of memory, segui questi 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 se raggiunge il limite prima del riavvio.
Se confermi che i problemi di out of memory stanno causando problemi, aumenta il limite di memoria nel campo resourceAttrOverride della risorsa personalizzata Stackdriver.

Loop di arresti anomali di metrics-server

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 out of memory in cluster di grandi dimensioni o in cluster con un'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 sono stati spostati da kube-system a gke-managed-metrics-server.

Per Google Distributed Cloud, la modifica della configurazione di Nanny verrà annullata in caso di aggiornamento o upgrade del cluster. Dovresti applicare nuovamente le modifiche alla configurazione. Per ovviare a questo limite, fai lo scale down di metrics-server-operator e modifica manualmente il pod metrics-server.

Non tutte le risorse vengono rimosse durante l'eliminazione del account di servizio di Cloud Audit Logs

Quando elimini un account di servizio utilizzato per Cloud Audit Logs, non tutte le risorse Google Cloudvengono eliminate. Se elimini e ricrei regolarmente i service account utilizzati per Cloud Audit Logs, alla fine l'audit logging inizia a non riuscire.

Sintomo

I messaggi di errore di autorizzazione negata vengono visualizzati nel container proxy di Cloud Audit Logs.

Per verificare che l'errore dell'audit log sia causato da questo problema, esegui il seguente comando:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging

Sostituisci PROJECT_NUMBER con il numero del progetto.

La risposta restituisce tutti i service account utilizzati con Cloud Audit Logs nel progetto, inclusi quelli che sono stati eliminati.

Causa e versioni interessate

Non tutte le risorse Google Cloud vengono rimosse quando elimini un account di servizio utilizzato per Cloud Audit Logs e, alla fine, raggiungi il limite di 1000 account di servizio per il progetto.

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

Correzione e soluzione alternativa

  1. Crea una variabile di ambiente contenente un elenco separato da virgole di tutti i service account che vuoi conservare. Racchiudi ogni indirizzo email del account di servizio tra virgolette singole e l'intero elenco tra virgolette doppie. Puoi utilizzare quanto segue come punto di partenza:

    SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto.
    • SERVICE_ACCOUNT_NAME: il nome del account di servizio.

    L'elenco completato dovrebbe essere simile all'esempio seguente:

    "'sa_name1@example-project-12345.iam.gserviceaccount.com','sa_name2@example-project-12345.iam.gserviceaccount.com','sa_name3@example-project-12345.iam.gserviceaccount.com'"

  2. Esegui questo comando per rimuovere la funzionalità Cloud Audit Logs dal progetto:

    curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging

    Sostituisci quanto segue:

    • PROJECT_NUMBER: il numero del progetto.
    • FLEET_REGION: la località di appartenenza al parco risorse per i tuoi cluster. Potrebbe essere una regione specifica, ad esempio us-central1 o global. Puoi eseguire il comando gcloud container fleet memberships list per ottenere la località dell'appartenenza.

    Questo comando elimina completamente tutti i service account.

  3. Ricrea la funzionalità Cloud Audit Logs solo con i service account che vuoi conservare:

    curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \
    -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'

Le etichette dei metadati scompaiono dalle metriche

Sintomo

Le etichette dei metadati, ad esempio node_name, non vengono compilate in Cloud Monitoring.

Causa e versioni interessate

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

Correzione e soluzione alternativa

Qualsiasi modifica al pod ripristinerà le etichette dei metadati. Ad esempio, l'esecuzione di comandi come kubectl rollout restart deployment <workload_name>.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare Assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

  • Requisiti per l'apertura di una richiesta di assistenza.
  • Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
  • Componenti supportati.