Risoluzione dei problemi relativi ai conflitti delle risorse

Questa pagina descrive come identificare e risolvere i problemi di conflitto delle risorse nell'ambiente Google Distributed Cloud.

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

Panoramica

A volte Google Distributed Cloud potrebbe riscontrare una contesa delle risorse, causando il rallentamento dei container, il loro rendimento inferiore alle aspettative o la loro terminazione. Ciò può accadere a causa di un consumo elevato di CPU o memoria da parte dei container.

Come funziona la gestione della CPU e della memoria

  • CPU:

    • Un pod viene pianificato su un nodo in base alle richieste di CPU specificate dai container al suo interno.
    • Un container in un pod non può utilizzare più CPU del limite specificato dal container
    • L'utilizzo della CPU del contenitore viene limitato al limite della CPU.
    • Se l'utilizzo della CPU è limitato a livello di nodo, ai container vengono assegnati automaticamente i cicli della CPU proporzionali alle richieste.

    Scopri di più su come vengono pianificati i pod con richieste di risorse.

  • Memoria:

    • Un pod viene pianificato su un nodo in base alle richieste di memoria specificate dai container al suo interno.
    • Un container non può utilizzare più memoria del limite specificato dal container.
    • Se non viene specificato alcun limite di memoria, un contenitore potrebbe consumare tutta la memoria disponibile su un nodo. Il sistema potrebbe quindi attivare OOM-Killer (Out Of Memory Killer) ed espellere i pod con priorità bassa.

Per ulteriori informazioni, vedi Assegnare risorse CPU, Assegnare risorse di memoria in Kubernetes e Metriche di GKE Enterprise.

Problemi

Il container diventa lento

I problemi di contesa della CPU possono causare il rallentamento dei container. Di seguito sono riportati alcuni dei potenziali motivi:

Utilizzo elevato della CPU sul container:

Un container può diventare lento se non ottiene cicli della CPU proporzionali alle richieste di CPU o se le richieste di CPU sono state impostate su un valore troppo basso rispetto a quello di cui ha bisogno il container. Controlla quindi il rapporto tra il limite della CPU e l'utilizzo della CPU per il container.

In Google Cloud Console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui questa query:

  fetch k8s_container
  | metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
  | group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
  | filter resource.cluster_name == 'CLUSTER_NAME'
  | filter resource.container_name == 'CONTAINER_NAME'
  | filter resource.pod_name == 'POD_NAME'
  | filter resource.namespace_name == 'NAMESPACE_NAME'
  | every 1m

Scegli una delle seguenti opzioni:

Utilizzo elevato della CPU sul nodo

Se il rapporto tra limite di CPU e utilizzo non è elevato per alcun singolo container del pod, è possibile che il nodo non abbia un numero sufficiente di cicli di CPU da allocare al set di container in esecuzione sul nodo. Per verificare il rapporto tra l'utilizzo effettivo della CPU e le CPU allocabili sul nodo, segui questi passaggi:

  1. Ottieni il nodo del pod che funziona lentamente:

    kubectl get pod –kubeconfig CLUSTER_KUBECONFIG --namespace NAMESPACE POD --output wide

  2. In Google Cloud Console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui la seguente query:

    fetch k8s_node
| metric 'kubernetes.io/anthos/node/cpu/allocatable_utilization'
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| every 1m

    Se questo rapporto è alto (>=0,8), significa che il nodo non ha abbastanza cicli di CPU ed è sottoscritto in eccesso. Segui questi passaggi per controllare l'utilizzo della CPU per tutti gli altri pod sul nodo e controlla se è presente un altro contenitore che utilizza più CPU.

    1. Recupera tutti i pod sul nodo:
    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
    1. Controlla l'utilizzo della CPU su ogni contenitore:
    fetch k8s_container
| metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

    Se è presente un altro container che utilizza una CPU elevata sul nodo, aumenta le richieste e i limiti di CPU sul container che funziona lentamente. Il pod verrà ricreato su un altro nodo per ottenere i cicli di CPU richiesti.

Se si tratta di un pod di sistema che funziona lentamente, contatta l'Assistenza Google.

Sovrabbondanza della CPU a livello di vSphere

Se il consumo della CPU non è elevato sul nodo o sul pod e il contenitore è ancora lento, la VM potrebbe essere sovrascritta a livello di vSphere. Di conseguenza, il nodo non è in grado di ottenere i cicli della CPU previsti dalla virtualizzazione sottostante.

Segui questi passaggi per verificare se la VM è sovrascritta. Se viene rilevato un abbonamento eccessivo, prova a procedere nel seguente modo:

Il pod viene terminato per OOM (Out of Memory)

I pod possono essere uccisi per OOM a causa di perdite di memoria o di una configurazione scadente delle richieste e dei limiti di memoria nei container. Di seguito sono riportati alcuni dei potenziali motivi:

Utilizzo elevato della memoria nel container

Un pod può essere ucciso da OOM se un container in un pod consuma più della memoria totale allocata. Controlla quindi il rapporto tra richieste di memoria e limiti di memoria nel container.

In Google Cloud Console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui questa query:

fetch k8s_container
| metric 'kubernetes.io/anthos/container/memory/limit_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

Scegli una delle seguenti opzioni:

Utilizzo elevato di memoria sul nodo

Un pod può essere interrotto se la memoria utilizzata di tutti i pod in esecuzione sul nodo supera la memoria disponibile. Quindi, controlla se la condizione MemoryPressure sul nodo è True.

  1. Esegui questo comando ed esamina la sezione Conditions:

    kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME

  2. Se la condizione MemoryPressure è True, controlla l'utilizzo della memoria sul nodo:

    fetch k8s_node
| metric 'kubernetes.io/anthos/node/memory/allocatable_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name = 'NODE_NAME'
| every 1m

    Se questo rapporto è elevato (>= 0,8), significa che il nodo non dispone di memoria sufficiente da allocare al pod, probabilmente a causa di alcuni processi o altri pod che consumano molta memoria.

  3. In Console Google Cloud > Monitoraggio > Esplora metriche, nell'editor MQL, esegui la seguente query per controllare l'utilizzo della memoria per i contenitori sul nodo:

    fetch k8s_node
| metric 'kubernetes.io/anthos/container_memory_usage_bytes'
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| group_by 1m,
    [value_container_memory_usage_bytes_mean:
      mean(value.container_memory_usage_bytes)]
| every 1m

    Se esiste un container che utilizza una memoria elevata, esamina il funzionamento del container o, se necessario, aumenta la richiesta di memoria per il container.

Se si tratta di un pod di sistema che consuma molta memoria, contatta l'Assistenza Google.

Inoltre, puoi abilitare la funzionalità di scalabilità automatica in Google Distributed Cloud per fare automaticamente lo scale up e lo scale down dei pool di nodi in base alle esigenze dei tuoi carichi di lavoro.

Scopri come attivare il gestore della scalabilità automatica.

Problemi con Etcd

A volte i tuoi Cluster Anthos su VMware potrebbero riscontrare errori dei container a causa di problemi del server etcd. Potresti osservare quanto segue:

  • Log del server API ripetuti del seguente tipo:

    etcdserver: request timed out e etcdserver: leader changed

  • Log etcd ripetuti del modulo:

    W | wal: sync duration of 2.466870869s, expected less than 1s e W | etcdserver: read-only range request * took too long

Di seguito sono riportati alcuni dei potenziali motivi:

Limitazione CPU

Il server etcd potrebbe essere lento a causa della limitazione della CPU sul pod del server etcd e/o sul nodo su cui è in esecuzione il server etcd. Fai riferimento ai passaggi nella sezione Il container diventa lento per verificare la presenza di problemi di contesa della CPU.

Se rilevi una contesa della CPU nel pod del server ectd o nel nodo, aggiungi CPU al nodo del piano di controllo del cluster utente. Utilizza gkectl update per modificare il campo cpus nel file di configurazione del cluster utente.

Pod Etcd ucciso da OOM

Il pod etcd potrebbe essere ucciso per OOM a causa di problemi di contesa delle risorse. Fai riferimento ai passaggi nella sezione I pod vengono terminati (esaurita la memoria) per verificare la presenza di eventuali problemi di conflitto di memoria con il pod del server etcd e/o il nodo su cui è in esecuzione il server etcd.

Se rilevi eventi OOM per il pod etcd, aumenta la memoria disponibile per il nodo del piano di controllo del cluster utente. Utilizza gkectl update per modificare il campo memoryMB nel file di configurazione del cluster utente.

Lentezza del disco

Se non si verificano problemi di consumo di CPU o memoria nel pod o nel nodo del server etcd, etcd potrebbe essere lento se il datastore sottostante è lento o limitato.

Verifica che non si siano verificati i seguenti problemi:

  • Per verificare se il server etcd impiega troppo tempo per leggere/scrivere sul disco sottostante:

    1. Recupera i log di etcd:

      kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n ETCD_POD_NAMESPACE ETCD_POD

    2. Cerca le voci del seguente pattern per rilevare se etcd sta impiegando troppo tempo a leggere dal disco:

      W | etcdserver: read-only range request "key:\"/registry/configmaps/default/clusterapi-vsphere-controller-manager-leader-election\" " with result "range_response_count:1 size:685" took too long (6.893127339s) to execute

    3. Cerca le voci del seguente pattern per rilevare se etcd sta impiegando troppo tempo per scrivere sul disco:

      W | wal: sync duration of 2.466870869s, expected less than 1s

    Se uno o entrambi i pattern di log sopra indicati vengono visualizzati di frequente nei log etcd, significa che il disco è lento. Poi controlla il rendimento del datastore e dei dischi.

  • Per controllare le metriche etcd:

    1. Recupera le latenze di sincronizzazione WAL di etcd:

      In Google Cloud Console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui questa query:

      fetch k8s_container::kubernetes.io/anthos/etcd_disk_wal_fsync_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99

    2. Recupera le latenze di scrittura etcd:

      In Google Cloud Console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui questa query:

      fetch k8s_container::kubernetes.io/anthos/etcd_disk_backend_commit_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99

    Se p99 per etcd_disk_wal_fsync_duration_seconds è costantemente superiore a 10 ms e/o p99 per etcd_disk_backend_commit_duration_seconds è costantemente superiore a 25 ms, indica la lentezza del disco. Poi controlla il rendimento del datastore e dei dischi.

Latenze di lettura/scrittura sul disco della VM

Segui questi passaggi per verificare le latenze di lettura/scrittura sul disco virtuale della VM

  1. Identifica il nodo del pod etcd lento:

    kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods -n ETCD_POD_NAMESPACE ETCD_POD -owide

  2. Accedi a vSphere e seleziona la VM identificata nel passaggio precedente: In vSphere, vai a Monitor > Rendimento > Avanzata e seleziona Disco virtuale dalla sezione Vista per identificare le latenze di lettura e scrittura per i dischi virtuali.

    Se la latenza di lettura/scrittura sul disco virtuale è elevata:

    • Esamina le altre VM in esecuzione nel data store per verificare l'utilizzo elevato delle operazioni di input/output al secondo (IOPS). Se una VM mostra dei picchi nelle IOPS, valutane il funzionamento.
    • Rivolgiti al team di laboratorio/infrastruttura per assicurarti che la larghezza di banda in lettura e scrittura non venga limitata o ridotta in nessun momento.
    • Consulta il team del lab/dell'infrastruttura per identificare eventuali problemi di prestazioni del disco e prestazioni di archiviazione.

Per saperne di più, consulta le best practice per la scalabilità delle risorse.

Problemi con il server API

Se i contenitori in Google Distributed Cloud presentano latenza durante la comunicazione con il server API o i comandi Kubectl non vanno a buon fine o impiegano troppo tempo per rispondere, potrebbero esserci problemi con il server API.

Di seguito sono riportati alcuni dei potenziali motivi:

Volume elevato di richieste API

Il server API potrebbe rispondere lentamente se la frequenza e il volume delle richieste sono troppo elevati. Il tempo di risposta lento potrebbe persistere anche dopo che il server API inizia a limitare le richieste. Controlla quindi la frequenza delle richieste API sul server API.

In Google Cloud Console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui questa query:

fetch k8s_container::kubernetes.io/anthos/apiserver_request_total
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'APISERVER_POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| align rate(1m)
| every 1m
| group_by [metric.verb]

Se si verifica un aumento imprevisto delle richieste API, utilizza i log di controllo di Cloud per identificare il pod che potrebbe eseguire query sul server API troppo spesso.

  • Se si tratta di un pod di sistema, contatta l'Assistenza Google.
  • Se si tratta di un pod utente, esamina ulteriormente la questione per determinare se le richieste API sono previste.

Limitazione CPU

Un'elevata tasso di richieste sul server API può causare una limitazione della CPU. Il server API potrebbe diventare lento a causa della contesa della CPU nel pod del server API e/o nel nodo.

Consulta la sezione Il contenitore diventa lento per verificare la presenza di problemi di contesa della CPU con il pod e/o il nodo.

Pod del server API ucciso per OOM

Il pod del server API potrebbe essere interrotto a causa di problemi di contesa delle risorse. Fai riferimento ai passaggi nella sezione I pod vengono terminati (esaurita la memoria) per verificare la presenza di eventuali problemi di conflitto di memoria con il pod e/o il nodo.

Risposte etcd lente

Il server API si basa sulla comunicazione con il cluster etcd per inviare richieste di lettura/scrittura ai client. Se etcd è lento o non risponde, anche il server API diventa lento.

Recupera i log del server API per verificare se il server API è lento a causa dei problemi etcd:

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Se noti log ricorrenti come etcdserver: request timedout o etcdserver: leader changed, segui i passaggi descritti in Problemi Etcd per risolvere eventuali problemi relativi al disco.

Se il cluster non esporta le metriche

Le tecniche mostrate in precedenza in questo documento si basano sulle metriche esportate dal cluster a un progetto Google Cloud.

Se il cluster non esporta le metriche, puoi utilizzare la riga di comando per esaminare la contesa delle risorse. Ecco alcuni comandi che puoi eseguire alla workstation di amministrazione.

Visualizza le metriche per un nodo:

kubectl --kubeconfig CLUSTER_KUBECONFIG get --raw \
    /apis/metrics.k8s.io/v1beta1/nodes/NODE_NAME | jq

Sostituisci quanto segue:

  • CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster
  • NODE_NAME: il nome del nodo

Visualizza le metriche per un pod:

kubectl --kubeconfig CLUSTER_KUBECONFIG get --raw \
    /apis/metrics.k8s.io/v1beta1/namespaces/NAMESPACE/pods/POD_NAME | jq

Sostituisci quanto segue:

  • NAMESPACE: lo spazio dei nomi del pod
  • POD_NAME: il nome del pod

Visualizza le metriche per tutti i nodi:

kubectl --kubeconfig CLUSTER_KUBECONFIG top node

Visualizza le metriche per tutti i pod in uno spazio dei nomi:

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --namespace NAMESPACE

Visualizza le metriche per i container in tutti i pod in uno spazio dei nomi:

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --containers --namespace NAMESPACE

Per ulteriori informazioni, consulta kubectl top pod e kubectl top node.

Puoi anche eseguire in alto dall'interno di un container in esecuzione su un nodo.

Ecco due modi per eseguire un comando all'interno di un container:

Passaggi successivi

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