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.

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 località e la chiave dell'account di servizio siano configurate correttamente. L'ID progetto deve essere uguale all'ID progetto sotto 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 relativi all'autorizzazione negata vengono visualizzati nel contenitore proxy di Cloud Audit Logs.

Il container proxy di Cloud Audit Logs viene eseguito in uno dei seguenti modi:

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

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 lo schema 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 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 un 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, gke-metrics-agent sullo stesso nodo probabilmente si verifica lo stesso problema.
  • Nel cluster, controlla lo stato e i log del pod KSM e gke-metrics-agent pod sullo stesso nodo con KSM.

kube-state-metrics loop di arresti anomali

Sintomo

Nessuna metrica di kube-state-metrics (KSM) disponibile da e configurazione in 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 una singola replica di deployment ed elenca quasi a tutte le risorse nel 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 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 un problema di esaurimento della memoria, segui i 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.

    Per regolare la CPU e la memoria di KSM:

    • Per Google Distributed Cloud versioni 1.16.0 o successive, 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 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 fare lo scale down di monitoring-operator a 0 repliche, quindi modificare Deployment KSM per adeguare il limite di risorse. Tuttavia, il cluster ricevere patch di vulnerabilità distribuite da nuove release utilizzando monitoring-operator. Ricordati di scalare monitoring-operator di backup dopo l'upgrade del cluster a una versione successiva con la correzione.

  • Riduci il numero di metriche di KSM.

    Per Google Distributed Cloud 1.13, per impostazione predefinita KSM espone 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 Google Distributed Cloud precedenti alla 1.13, KSM utilizza il valore predefinito e i flag facoltativi. 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 ridurre il problema, riduci stackdriver-operator e modifica KSM in modo da esporre un piccolo insieme di metriche necessarie, come descritto nella sezione precedente. Ricorda di eseguire il ridimensionamento verso l'alto 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 Metrics.

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 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 un deployment di replica singola, il che aumenta il rischio di eventi di memoria insufficiente 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 un problema di esaurimento della memoria, segui i 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 stackdriver-metadata-agent e verifica prima se stai raggiungendo il limite per eseguire il riavvio.
Se confermi che i problemi di esaurimento della memoria stanno causando problemi, aumenta il limite di memoria nel campo resourceAttrOverride della risorsa personalizzata Stackdriver.

Loop arresto anomalo 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 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.

Passaggi successivi

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