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 aiuto, contatta l'assistenza clienti Google Cloud.

Panoramica

A volte Google Distributed Cloud potrebbe riscontrare conflitti tra le risorse, che causano il rallentamento, le prestazioni inferiori o l'arresto dei container. Ciò può accadere a causa di un consumo elevato 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 è limitato al limite della CPU.
  • Se l'utilizzo della CPU è limitato a livello di nodo, ai container vengono assegnati automaticamente i cicli di 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 è specificato alcun limite di memoria, un container potrebbe consumare tutta la memoria disponibile su un nodo. Successivamente, il sistema potrebbe attivare l'eliminazione definitiva dell'OOM (Out Of Memory Killer) ed eliminare i pod a bassa priorità.

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 necessario al container. Controlla quindi il rapporto tra il limite di CPU e l'utilizzo della CPU per il container.

In Console Google Cloud > Monitoring > 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:

• Se questo rapporto è alto (>=0,8), significa che il limite della CPU sul container è basso e Kubernetes sta limitando i cicli della CPU del container per mantenere l'utilizzo della CPU entro i limiti. Per risolvere il problema, aumenta il limite di CPU sul container.
• Se questo rapporto non è elevato (< 0,8), controlla se l'utilizzo della CPU è elevato sul nodo.

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. Quindi segui questi passaggi per verificare il rapporto tra l'utilizzo effettivo della CPU e le CPU allocabili sul nodo:

1. Ottieni il nodo per il pod che funziona lentamente:

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

2. In Console Google Cloud > Monitoring > Esplora metriche, nell'editor MQL, esegui questa 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 quindi questi passaggi per verificare l'utilizzo della CPU per tutti gli altri pod su quel nodo e verifica se c'è un altro container che usa 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 è presente un altro container che utilizza una CPU elevata sul nodo, 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 richiesti.

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

Oversubscription della CPU a livello di vSphere

Se il consumo della CPU non è elevato né sul nodo né sul pod e il container è ancora lento, la VM potrebbe avere una sottoscrizione eccessiva 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 ha un abbonamento in eccesso. Se viene rilevato un abbonamento eccessivo, prova a procedere nel seguente modo:

• Spostare alcune VM su altri host.
• Valutare e diminuire il numero di vCPU per VM per l'host.
• Alloca più risorse alle VM GKE Enterprise.
• 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 richiesti.

Il pod viene eliminato definitivamente (esaurimento della memoria)

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

Memoria utilizzata elevata nel container

Un pod può essere interrotto se un container in un pod consuma in eccesso la memoria allocata totale. Controlla quindi il rapporto tra richieste di memoria e limiti di memoria nel container.

In Console Google Cloud > Monitoring > 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:

• Se questo rapporto è elevato (>= 0,8), aumenta il limite di memoria nel container.
• Se questo rapporto non è elevato (< 0,8), controlla se l'utilizzo della memoria sul nodo è elevato.

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. Controlla quindi 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 utilizzano memoria elevata.

3. In Console Google Cloud > Monitoring > Esplora metriche, nell'editor MQL, esegui questa 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 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 relativi all'ETC

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 ripetuti del server API 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 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 un conflitto di CPU sul pod del server ectd o sul 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 - OOM ucciso

Il pod etcd 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 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 la lettura/scrittura 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 pattern seguente 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 precedenti vengono visualizzati spesso nei log etcd, significa che il disco è lento. Quindi controlla le prestazioni del datastore e dei dischi.

• Per controllare le metriche etcd:

  1. Recupera le latenze di sincronizzazione wal etcd:

     In Console Google Cloud > Monitoring > 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 Console Google Cloud > Monitoring > 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 supera di continuo i 10 ms e/o p99 per etcd_disk_backend_commit_duration_seconds supera di continuo i 25 ms, indica una lentezza del disco. Quindi controlla le prestazioni 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 Monitor > Performance (Prestazioni) > Advanced (Avanzate) e seleziona Virtual Disk (Disco virtuale) dalla sezione View (Visualizza) 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 sul datastore per verificare l'utilizzo elevato di operazioni di I/O al secondo (IOPS). Se una VM mostra dei picchi nelle IOPS, valutane il funzionamento.
   • Consulta il team del laboratorio o dell'infrastruttura per assicurarti che la larghezza di banda in lettura e scrittura non sia limitata o limitata in nessun momento.
   • Consulta il team del tuo 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 relativi al server API

Se i container della latenza Google Distributed Cloud riscontrano durante la comunicazione con il server API o se i comandi Kubectl non riescono 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 essere lento a rispondere se la frequenza e il volume delle richieste sono troppo elevati. Il tempo di risposta lento potrebbe persistere anche dopo che il server API ha avviato la limitazione delle richieste. Controlla quindi la frequenza delle richieste API sul server API.

In Console Google Cloud > Monitoring > 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 l'audit logging di Cloud per identificare il pod che potrebbe eseguire query troppo frequenti sul server API.

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

Limitazione CPU

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

Fai riferimento alla sezione Il container diventa lento per verificare la presenza di problemi di contesa della CPU con il pod e/o il nodo.

OOM del pod del server API eliminato

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 gestire 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 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 esaminare i conflitti delle risorse. Ecco alcuni comandi che puoi eseguire sulla 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 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:

• Sulla workstation di amministrazione, esegui kubectl exec per inserire una shell nel container. Esegui il comando nella shell.

• Ottieni una connessione SSH a un nodo. Quindi utilizza docker exec per inserire una shell nel container. Esegui il comando nella shell.

Passaggi successivi

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