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 e le soluzioni alternative suggerite.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare la sezione Richiedere 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 sono abilitati per impostazione predefinita, a meno che non sia impostato un flag disableCloudAuditLogging nella sezione clusterOperations della configurazione del cluster.

Se i log di controllo 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 di autorizzazione negata vengono visualizzati nel contenitore proxy di Cloud Audit Logs.

Il container proxy 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 tuo progetto potrebbe aver raggiunto il limite di account di servizio supportati. Consulta Account di servizio di Cloud Audit Logs compromesso.

Le metriche kube-state-metrics non vengono raccolte

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, il rischio di interruzione tra gli agenti delle metriche su tutti i nodi è maggiore.

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 mancano le metriche KSM, esamina 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 API di riepilogo 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 dell'API di riepilogo non sono disponibili per KSM, gke-metrics-agent probabilmente anche lo stesso nodo presenta lo stesso problema.
  • Nel cluster, controlla lo stato e i log del pod KSM e del pod gke-metrics-agent sullo stesso nodo di KSM.

kube-state-metrics loop di arresto anomalo

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 in cluster con grandi quantità di risorse. KSM viene eseguito come Deployment con una sola 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 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 può essere riscontrato 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 di risorse dovrebbero essere meno comuni.

Correzione e soluzione alternativa

Per verificare se il problema è dovuto a problemi di memoria insufficiente, segui i seguenti passaggi:

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

Se confermi che il problema è dovuto a memoria insufficiente, utilizza una delle seguenti soluzioni:

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

  • Riduci il numero di metriche di KSM.

    Per Google Distributed Cloud 1.13, KSM espone solo un numero inferiore di metriche chiamate Metriche principali per impostazione predefinita. 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.

gke-metrics-agent loop di arresto anomalo

Se gke-metrics-agent riscontra problemi di memoria insufficiente solo sul nodo in cui esiste kube-state-metrics, la causa è un numero elevato di metriche kube-state-metrics. Per risolvere 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. Ricordati di eseguire lo scale up di stackdriver-operator dopo l'upgrade del cluster a Google Distributed Cloud 1.13, in cui KSM espone per impostazione predefinita un numero inferiore di metriche principali.

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

stackdriver-metadata-agent loop di arresto anomalo

Sintomo

Nessuna etichetta di metadati di sistema è disponibile durante il filtraggio delle metriche in Cloud Monitoring.

Causa

Il caso più comune di loop di arresto anomalo di stackdriver-metadata-agent è dovuto a eventi di esaurimento della memoria. Questo evento è simile a kube-state-metrics. Sebbene stackdriver-metadata-agent non elenchi 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 esaurimento della memoria se il numero di oggetti è troppo elevato.

Versione interessata

Questo problema può essere riscontrato 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 di risorse dovrebbero essere meno comuni.

Correzione e soluzione alternativa

Per verificare se il problema è dovuto a problemi di memoria insufficiente, segui i seguenti passaggi:

  • Utilizza kubectl describe pod o kubectl get pod -o yaml e controlla il messaggio di stato di errore.
  • Controlla la metrica relativa al consumo e all'utilizzo della memoria per stackdriver-metadata-agent e verifica se sta raggiungendo il limite prima di essere riavviato.
Se confermi che i problemi di memoria insufficiente causano problemi, aumenta il limite di memoria nel campo resourceAttrOverride della risorsa personalizzata Stackdriver.

metrics-server loop di arresto anomalo

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 un'elevata densità di pod.

Questo problema può essere riscontrato 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 nanny verrà ripristinata in caso di aggiornamento o upgrade del cluster. Dovrai applicare nuovamente le modifiche alla configurazione. Per ovviare a questa limitazione, riduci lo scale down metrics-server-operator e modifica manualmente il metrics-server pod.

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

Quando elimini un account di servizio utilizzato per Cloud Audit Logs, non tutte le risorse Google Cloud vengono eliminate. Se elimini e ricrei regolarmente gli account di servizio utilizzati per Cloud Audit Logs, alla fine il logging di controllo inizia a non funzionare.

Sintomo

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

Per verificare che l'errore del log di controllo sia causato da questo problema, esegui questo 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 tuo progetto.

La risposta restituisce tutti i service account utilizzati con Cloud Audit Logs nel progetto, inclusi quelli 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 può essere riscontrato 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. Raccolgono ogni email dell'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 dell'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 di progetto.
    • FLEET_REGION: la posizione dell'appartenenza al parco per i tuoi cluster. Può trattarsi di una regione specifica come us-central1 o global. Puoi eseguire il comando gcloud container fleet memberships list per ottenere la posizione dell'abbonamento.

    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]}}}'

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare la sezione Richiedere 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.