Risolvi i problemi di osservabilità di GKE su VMware

Questo documento ti aiuta a risolvere i problemi di osservabilità in Google Distributed Cloud Virtual for VMware. 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 di autorizzazione negata 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 in un cluster autonomo.
  • Come container collaterale nel pod kube-apiserver.

Se vengono visualizzati 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 di 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, esiste un rischio maggiore di interruzione degli 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 le metriche KSM non sono presenti, 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 dell'API di riepilogo come kubernetes.io/anthos/container/... . Si tratta di una pipeline separata con KSM. Verifica che il pod di KSM non sia limitato da risorse insufficienti.
    • Se queste metriche dell'API di riepilogo 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 di 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

Questo scenario ha maggiori probabilità di verificarsi in cluster di grandi dimensioni o con grandi quantità di risorse. KSM viene eseguito come un singolo deployment di 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. 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 si può verificare con qualsiasi versione di Google Distributed Cloud Virtual for VMware.

I limiti predefiniti di CPU e memoria sono stati aumentati nelle ultime versioni di Google Distributed Cloud Virtual for VMware, pertanto questi problemi relativi alle risorse dovrebbero essere meno comuni.

Correzione e soluzione alternativa

Per verificare se il problema è dovuto a problemi di esaurimento della memoria, 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 ha raggiunto il limite prima di riavviare.

Se confermi che il problema è l'esaurimento della memoria, utilizza una delle seguenti soluzioni:

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

    Per regolare la CPU e la memoria di KSM:

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

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

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

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

    2. Per Google Distributed Cloud Virtual for VMware versione 1.10.7 o successive, 1.11.3 o successive, 1.12.2 o successive e 1.13 e successive, 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 definizione riportata di seguito. Regola i numeri 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 il ConfigMap, riavvia il deployment KSM eliminando il pod di KSM utilizzando questo comando:

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

  • Riduci il numero di metriche di KSM.

    Per Google Distributed Cloud Virtual for VMware 1.13, KSM espone solo un numero inferiore di metriche chiamate metriche principali per impostazione predefinita. Questo comportamento indica che l'utilizzo delle risorse è inferiore rispetto alle versioni precedenti, ma puoi seguire la stessa procedura per ridurre ulteriormente il numero di metriche KSM.

    Per le versioni Google Distributed Cloud Virtual for VMware 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 verificano problemi di esaurimento della memoria solo nel nodo in cui si trova kube-state-metrics, la causa è un numero elevato di metriche kube-state-metrics. Per limitare questo problema, fare lo scale down di stackdriver-operator e modifica KSM per esporre un piccolo set 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 Virtual for VMware 1.13, dove KSM per impostazione predefinita espone un numero inferiore di metriche principali.

Per problemi non correlati a 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

Quando filtri le metriche in Cloud Monitoring, non è disponibile nessuna etichetta dei metadati di sistema.

Causa

Il caso più comune di arresto anomalo di stackdriver-metadata-agent in loop è 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 singolo deployment di replica, il che aumenta il rischio di eventi di esaurimento della memoria se il numero di oggetti è troppo elevato.

Versione interessata

Questo problema si può verificare con qualsiasi versione di Google Distributed Cloud Virtual for VMware.

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

Correzione e soluzione alternativa

Per verificare se il problema è dovuto a problemi di esaurimento della memoria, 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 della memoria e utilizzo per stackdriver-metadata-agent e verifica se ha raggiunto il limite prima di riavviare.
Se confermi che sono a causa di problemi di memoria insufficiente, 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 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'alta densità di pod.

Questo problema si può verificare con qualsiasi versione di Google Distributed Cloud Virtual for VMware.

Correzione e soluzione alternativa

Aumenta i limiti delle risorse del server delle metriche. In Google Distributed Cloud Virtual for VMware 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.