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

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

Gli audit log di Cloud non vengono raccolti

Verifica se gli audit log di Cloud sono abilitati nella sezione cloudAuditLogging della configurazione del cluster. Verifica che l'ID progetto, la posizione e la chiave dell'account di servizio siano configurati correttamente. L'ID progetto deve essere uguale a quello visualizzato in gkeConnect.

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

Il contenitore proxy di Cloud Audit Logs viene eseguito come uno dei seguenti:

  • Un pod statico nel cluster di amministrazione o autonomo.
  • Come container sidecar nel pod kube-apiserver.

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 dei log di controllo di Cloud divulgato.

Le metriche kube-state-metrics 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 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 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 le metriche KSM non sono presenti, 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 dell'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 sullo stesso nodo probabilmente si verifica lo stesso problema.
  • Nel cluster, controlla lo stato e i log del pod KSM e del gke-metrics-agent pod sullo stesso nodo con KSM.

kube-state-metrics loop di arresti anomali

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 ciascuno di questi oggetti risorsa. Se una delle risorse ha molti oggetti, ad esempio un cluster con più di 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 un problema di esaurimento della memoria, esamina i 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 KSM e verifica se sta raggiungendo il limite prima del riavvio.

Se confermi che il problema è correlato alla mancanza di 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:

    • Per le versioni 1.16.0 o successive di Google Distributed Cloud, Google Cloud Observability gestisce KSM. Per aggiornare KSM, consulta Ignorare le richieste e i limiti di CPU e memoria predefiniti per un componente di Stackdriver.

    • Per le versioni di Google Distributed Cloud 1.10.7 o successive, 1.11.3 o successive, 1.12.2 o successive e 1.13 e successive, ma precedenti alla 1.16.0, crea un ConfigMap per regolare la CPU e la memoria:

      1. Crea un ConfigMap denominato kube-state-metrics-resizer-config nello spazio dei nomi kube-system (gke-managed-metrics-server per 1.13 o versioni successive) con la seguente definizione. Modifica i valori di CPU e memoria in base alle tue esigenze:

          apiVersion: v1
  kind: ConfigMap
  metadata:
    name: kube-state-metrics-resizer-config
    namespace: kube-system
  data:
    NannyConfiguration: |-
      apiVersion: nannyconfig/v1alpha1
      kind: NannyConfiguration
      baseCPU: 200m
      baseMemory: 1Gi
      cpuPerNode: 3m
      memoryPerNode: 20Mi
  ```

      2. Dopo aver creato il ConfigMap, riavvia il deployment KSM eliminando il pod KSM utilizzando il seguente comando:

        kubectl -n kube-system rollout restart deployment kube-state-metrics

    • Per le versioni di Google Distributed Cloud 1.9 e precedenti, 1.10.6 o precedenti, 1.11.2 o precedenti e 1.12.1 o precedenti:

      • Nessuna soluzione valida a lungo termine: se modifichi la risorsa relativa al KSM, le modifiche vengono annullate automaticamente da monitoring-operator.
      • Puoi ridurre monitoring-operator a 0 repliche, quindi modificare il deployment KSM per regolare il limite di risorse. Tuttavia, il cluster non riceverà le patch per le vulnerabilità fornite dalle nuove release di patch utilizzando monitoring-operator. Ricorda di eseguire lo scale up di monitoring-operator dopo l'upgrade del cluster a una versione successiva con la correzione.

  • Riduci il numero di metriche del KSM.

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

Se gke-metrics-agent presenta problemi di esaurimento della memoria solo sul nodo in cui è presente kube-state-metrics, la causa è un numero elevato di metriche kube-state-metrics. Per ridurre il problema, riduci le dimensioni di stackdriver-operator e modifica KSM in modo da esporre un piccolo insieme di metriche necessarie, come descritto nella sezione precedente. Ricordati 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 dei pod di gke-metric-agent. Puoi regolare la CPU e la memoria per tutti i gke-metrics-agent pod aggiungendo il campo resourceAttrOverride alla risorsa personalizzata Stackdriver.

stackdriver-metadata-agent loop di arresti anomali

Sintomo

Non è disponibile alcuna etichetta dei metadati di sistema per filtrare le metriche in Cloud Monitoring.

Causa

Il caso più comune di stackdriver-metadata-agent crash looping è 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 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 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 un problema di esaurimento della memoria, esamina i 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 se sta raggiungendo il limite prima di essere riavviata.
Se confermi che i problemi di esaurimento della memoria stanno causando problemi, aumenta il limite di memoria nel campo resourceAttrOverride della risorsa personalizzata 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 sono stati spostati da kube-system a gke-managed-metrics-server.

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

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

Sintomo

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

Per verificare che l'errore del log di controllo 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 tuo progetto.

La risposta restituisce tutti gli account di servizio utilizzati con i log di controllo di Cloud nel progetto, inclusi quelli eliminati.

Causa e versioni interessate

Non tutte le Google Cloud risorse vengono rimosse quando elimini un account di servizio utilizzato per i log di controllo di Cloud e 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 gli account di servizio che vuoi conservare. Racchiudi ogni indirizzo 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 il seguente comando per rimuovere la funzionalità Log di controllo cloud 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 posizione del gruppo di veicoli per i tuoi cluster. Può trattarsi di una regione specifica, ad esempio 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à Audit log di Cloud solo con gli account di servizio 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.