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

Se hai bisogno di ulteriore aiuto, contatta l'Assistenza Google.

Cloud Audit Logs non vengono raccolti

Controlla se Cloud Audit Logs sono abilitati nella sezione cloudAuditLogging della configurazione del cluster. Verifica che l'ID progetto, la località e la chiave dell'account di servizio siano configurati correttamente. L'ID progetto deve essere uguale all'ID progetto in gkeConnect.

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 relativi a autorizzazioni negate vengono visualizzati nel container 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 collaterale nel pod kube-apiserver.

Se riscontri errori di autorizzazione, segui i passaggi per la risoluzione dei problemi relativi alle autorizzazioni.

kube-state-metrics metriche non vengono raccolte

kube-state-metrics (KSM) viene eseguito come deployment a replica singola nel cluster e genera metriche su quasi tutte le risorse nel cluster. Quando KSM e gke-metrics-agent vengono eseguiti 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_ provengono 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/... . Questa è 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, è probabile che anche gke-metrics-agent sullo stesso nodo presenti 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 arresto anomalo di kube-state-metrics

Sintomo

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

Causa

È più probabile che questo scenario si verifichi in cluster di grandi dimensioni o con grandi quantità di risorse. KSM viene eseguito come deployment a replica singola 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 delle risorse. 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 con 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, procedi nel seguente modo:

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

Se confermi che il problema è l'esaurimento della 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:

    1. Per Google Distributed Cloud versioni 1.9 e precedenti, 1.10.6 o precedenti, 1.11.2 o precedenti e 1.12.1 o precedenti:

      1. Nessuna soluzione valida a lungo termine: se modifichi la risorsa correlata a KSM, le modifiche vengono annullate automaticamente da monitoring-operator.

      2. Puoi fare lo scale down di monitoring-operator a 0 repliche, quindi modificare il deployment KSM per adeguarne il limite di risorse. Tuttavia, il cluster non riceverà le patch di vulnerabilità distribuite da nuove release utilizzando monitoring-operator.

        Ricordati di fare lo scale up di monitoring-operator dopo l'upgrade del cluster a una versione successiva con la correzione.

    2. Per Google Distributed Cloud versioni 1.10.7 o successive, 1.11.3 o successive, 1.12.2 o successive e 1.13 e successive, crea un elemento 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 come preferisci:

      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

      1. Dopo aver creato l'oggetto ConfigMap, riavvia il deployment KSM eliminando il pod KSM utilizzando il seguente comando:

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

  • Riduci il numero di metriche di KSM.

    Per Google Distributed Cloud 1.13, KSM espone per impostazione predefinita solo un numero inferiore di metriche chiamate metriche principali. Questo comportamento indica 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 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 è presente kube-state-metrics, la causa è un numero elevato di metriche kube-state-metrics. Per mitigare il problema, fare lo scale down stackdriver-operator e modifica KSM per esporre un piccolo insieme di metriche necessarie, come descritto nella sezione precedente. Ricordati di fare lo scale up di stackdriver-operator dopo l'upgrade del cluster a Google Distributed Cloud 1.13, dove KSM per impostazione predefinita espone un numero inferiore di metriche principali.

Per 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 pod gke-metrics-agent aggiungendo il 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 sta elencando 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 a replica singola, il che aumenta il rischio di eventi di esaurimento della memoria se il numero di oggetti è troppo elevato.

Versione interessata

Questo problema potrebbe verificarsi con 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, procedi nel seguente modo:

  • 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 stackdriver-metadata-agent e verifica se sta raggiungendo il limite prima di riavviare.
Se confermi che i problemi di memoria esaurita causano problemi, aumenta il limite di memoria nel campo resourceAttrOverride della risorsa personalizzata di 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 memoria insufficiente in cluster di grandi dimensioni o in cluster con un'alta densità di pod.

Questo problema potrebbe verificarsi con 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.

Passaggi successivi

Se hai bisogno di ulteriore aiuto, contatta l'Assistenza Google.