Risolvere i problemi di contesa delle risorse

Questa pagina descrive come identificare e risolvere i problemi di contesa delle risorse nel tuo ambiente Google Distributed Cloud.

Panoramica

A volte Google Distributed Cloud potrebbe riscontrare una contesa delle risorse, causando il rallentamento, il rendimento insufficiente o l'interruzione dei container. Ciò può accadere a causa dell'elevato consumo di CPU o memoria da parte dei container.

Come funziona la gestione di CPU e memoria

  • CPU:

    • Un pod viene pianificato su un nodo in base alle richieste di CPU specificate dai container nel pod.
    • Un container in un pod non può utilizzare più CPU del limite specificato dal container
    • L'utilizzo della CPU del container viene limitato al limite della CPU.
    • Se l'utilizzo della CPU viene 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 nel pod.
    • Un container non può utilizzare più memoria del limite specificato dal container.
    • Se non viene specificato alcun limite di memoria, un container potrebbe consumare tutta la memoria disponibile su un nodo. Il sistema potrebbe quindi attivare OOM-Killer (Out Of Memory Killer) ed eliminare i pod a bassa priorità.

Per ulteriori informazioni, consulta le seguenti risorse:

Problemi

Il container diventa lento

I problemi di contesa della CPU possono rallentare i container. Di seguito sono riportati alcuni dei possibili motivi:

Utilizzo elevato della CPU sul container:

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

In Google Cloud console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui la seguente 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 e utilizzo della CPU non è elevato per nessun singolo container del pod, è possibile che il nodo non disponga di cicli CPU sufficienti da allocare al set di container in esecuzione sul nodo. Per controllare il rapporto tra l'utilizzo effettivo della CPU e le CPU allocabili sul nodo, segui questi passaggi:

  1. Recupera il nodo per il 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 è elevato (>=0,8), significa che il nodo non ha cicli di CPU sufficienti ed è in oversubscription. Quindi, segui questi passaggi per controllare l'utilizzo della CPU per tutti gli altri pod su quel nodo e verifica se esiste un altro container 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 container:
    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 sul nodo è presente un altro container che utilizza una quantità elevata di CPU, aumenta le richieste e i limiti di CPU sul container che funziona lentamente. In questo modo, il pod verrà ricreato su un altro nodo per ottenere i cicli di CPU necessari.

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

Sovrascrizione della CPU a livello di vSphere

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

Segui questi passaggi per verificare se la VM è in oversubscription. Se viene rilevata una sovrascrizione, prova a procedere nel seguente modo:

  • Sposta alcune VM su altri host.
  • Valuta e riduci il numero di vCPU per VM per l'host.
  • Alloca più risorse alle VM del cluster.
  • Aumenta le richieste e i limiti di CPU sul container. In questo modo, il pod verrà ricreato su un altro nodo per ottenere i cicli di CPU necessari.

Il pod viene terminato per esaurimento della memoria (Out of Memory-Killed)

I pod possono essere terminati a causa di perdite di memoria o di una configurazione errata delle richieste e dei limiti di memoria sui container. Di seguito sono riportati alcuni dei possibili motivi:

Utilizzo elevato della memoria sul container

Un pod può essere terminato con errore OOM se un container in un pod consuma eccessivamente la memoria totale allocata. Controlla quindi il rapporto tra le richieste di memoria e i limiti di memoria sul container.

In Google Cloud console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui la seguente 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 della memoria sul nodo

Un pod può essere terminato per errore OOM se l'utilizzo di memoria 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 ha memoria sufficiente da allocare al pod, probabilmente a causa di alcuni processi o altri pod che consumano molta memoria.

  3. In Google Cloud console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui la seguente query per controllare l'utilizzo della memoria per i container 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 è presente un container che utilizza molta memoria, esamina il funzionamento del container o aumenta la richiesta di memoria per il container, se necessario.

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

Inoltre, puoi attivare la funzionalità di scalabilità automatica in Google Distributed Cloud per aumentare e ridurre automaticamente i node pool in base alle esigenze dei tuoi carichi di lavoro.

Scopri come attivare il gestore della scalabilità automatica.

Problemi relativi a etcd

A volte, i cluster Anthos su VMware potrebbero riscontrare errori dei container a causa di problemi del server etcd e potresti notare quanto segue:

  • Log del server API ripetuti nel formato:

    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 possibili motivi:

Limitazione CPU

Il server etcd potrebbe essere lento a causa della limitazione della CPU nel pod server etcd e/o nel nodo su cui è in esecuzione. Consulta i passaggi nella sezione Il contenitore diventa lento per verificare la presenza di problemi di contesa della CPU.

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

Etcd Pod OOMkilled

Il pod etcd potrebbe essere terminato a causa di problemi di contesa delle risorse. Fai riferimento ai passaggi nella sezione Pod interrotto per esaurimento della memoria (Out of Memory-Killed) per verificare la presenza di problemi di contesa della memoria con il pod del server etcd e/o il nodo su cui è in esecuzione il server etcd.

Se rilevi OOMkill per il pod etcd, aumenta la memoria disponibile per il nodo del control plane del cluster utente. Utilizza gkectl update per modificare il campo memoryMB nel file di configurazione del cluster utente.

Lentezza del disco

Se non ci sono problemi con il 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 la presenza dei seguenti problemi:

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

    1. Recupera i log etcd:

      kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n ETCD_POD_NAMESPACE ETCD_POD

    2. Cerca le voci del seguente pattern per rilevare se etcd impiega troppo tempo per 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 impiega 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 precedenti vengono visualizzati spesso 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 di etcd wal:

      In Google Cloud console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui la seguente 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 di etcd:

      In Google Cloud console > Monitoraggio > Esplora metriche, nell'editor MQL, esegui la seguente 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 supera continuamente i 10 ms e/o p99 per etcd_disk_backend_commit_duration_seconds supera continuamente i 25 ms, indica una 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 per il 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 Monitora > Rendimento > Avanzate e seleziona Disco virtuale dalla sezione Visualizza per identificare le latenze di lettura e scrittura per i dischi virtuali.

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

    • Esamina altre VM in esecuzione sul datastore per verificare l'utilizzo elevato di operazioni di I/O al secondo (IOPS). Se una VM mostra picchi nelle IOPS, valuta il funzionamento della VM.
    • Consulta il team di laboratorio/infrastruttura per assicurarti che la larghezza di banda di lettura e scrittura non venga limitata in nessun momento.
    • Consulta il team del laboratorio/dell'infrastruttura per identificare i problemi di rendimento del disco e di rendimento dello spazio di archiviazione, se presenti.

Per saperne di più, consulta le best practice per scalare le risorse.

Problemi con il server API

Se i container nella tua esperienza Google Distributed Cloud riscontrano latenza durante la comunicazione con il server API o se 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 possibili 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 la seguente 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 Cloud Audit Logs per identificare il pod che potrebbe interrogare il 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 per determinare se le richieste API sono previste.

Limitazione CPU

Una tasso di richieste elevata sul server API può causare la limitazione della CPU. A questo punto, il server API potrebbe rallentare a causa della contesa della CPU nel pod 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 OOMkilled

Il pod del server API potrebbe essere terminato a causa di problemi di contesa delle risorse. Consulta i passaggi nella sezione Pod gets OOMkilled (Out of Memory-Killed) per verificare la presenza di problemi di contesa della memoria con il pod e/o il nodo.

Risposte etcd lente

Il server API si basa sulla comunicazione con il cluster etcd per gestire le 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 di problemi di etcd:

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Se osservi log ricorrenti come etcdserver: request timedout o etcdserver: leader changed, segui i passaggi descritti in Problemi di 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 sull'esportazione delle metriche dal cluster a un progetto Google Cloud .

Se il cluster non esporta le metriche, puoi utilizzare la riga di comando per analizzare la contesa delle risorse. Ecco alcuni comandi che puoi eseguire sulla tua workstation amministrativa per visualizzare le metriche.

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

Visualizzare 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 di uno spazio dei nomi:

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

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

Puoi anche eseguire il comando top 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.

Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui: