Risolvere i problemi relativi ai workload di cui è stato eseguito il deployment

Questa pagina mostra come risolvere gli errori relativi ai workload di cui hai eseguito il deployment in Google Kubernetes Engine (GKE).

Per consigli più generali sulla risoluzione dei problemi delle applicazioni, consulta Risoluzione dei problemi delle applicazioni nella documentazione di Kubernetes.

Tutti gli errori: controlla lo stato del pod

Se si verificano problemi con i pod di un carico di lavoro, Kubernetes aggiorna lo stato del pod con un messaggio di errore. Visualizza questi errori controllando lo stato di un pod utilizzando la console Cloud de Confiance o lo strumento a riga di comando kubectl.

kubectl get pods

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

kubectl describe pod POD_NAME

kubectl logs POD_NAME

Dopo aver identificato l'errore, utilizza le sezioni seguenti per tentare di risolvere il problema.

Errore: CrashLoopBackOff

Lo stato CrashLoopBackOff non indica un errore specifico, ma che un container si arresta ripetutamente in modo anomalo dopo il riavvio.

Per saperne di più, consulta Risolvi i problemi relativi agli eventi CrashLoopBackOff.

Errori: ImagePullBackOff e ErrImagePull

Uno stato ImagePullBackOff o ErrImagePull indica che l'immagine utilizzata da un container non può essere caricata dal registry delle immagini.

Per indicazioni sulla risoluzione dei problemi relativi a questi stati, consulta Risolvi i problemi relativi ai pull delle immagini.

Errore: OutOfPods

Uno stato OutOfPods indica che un nodo non può eseguire un pod perché il nodo ha raggiunto la capacità massima di pod.

Sintomi

Potresti visualizzare un messaggio negli eventi del pod simile al seguente:

Node didn't have enough resource: pods, requested: 1, used: 32, capacity: 32

Causa

Questo errore si verifica quando viene richiesta la pianificazione di un pod su un nodo che ha già raggiunto la capacità massima. Questa situazione può verificarsi comunemente durante l'avvio del nodo, ad esempio quando il componente kube-scheduler assegna i pod a un nuovo nodo prima che l'agente kubelet abbia segnalato la presenza di pod statici come il componente kube-proxy, che richiedono una propria capacità di pod.

Risoluzione

Per risolvere il problema, prova una delle seguenti soluzioni:

• Aumenta il numero massimo di pod per nodo. Se i nodi raggiungono costantemente il limite di pod, aumenta l'impostazione --max-pods-per-node per i node pool. L'aumento del numero di pod potrebbe richiedere nodi più grandi per gestire l'aumento delle richieste di risorse.

• Abilita il gestore della scalabilità automatica dei cluster e il provisioning automatico dei nodi. Se la capacità dei pod si esaurisce di frequente, l'attivazione del gestore della scalabilità automatica dei cluster e del provisioning automatico dei nodi può contribuire a garantire che il cluster disponga di nodi sufficienti per soddisfare la domanda dei tuoi workload.

• Modifica il profilo di scalabilità automatica. Se utilizzi già lo strumento di scalabilità automatica del cluster, prova a modificare il profilo di scalabilità automatica con il profilo balanced anziché con il profilo optimize-utilization. Il profilo optimize-utilization può aumentare la probabilità di errori OutOfPods perché tenta di posizionare i pod sui nodi più utilizzati.

Errore: Pod non pianificabile

Lo stato PodUnschedulable indica che il pod non può essere pianificato a causa di risorse insufficienti o di un errore di configurazione.

Se hai configurato le metriche del control plane, puoi trovare ulteriori informazioni su questi errori nelle metriche dello scheduler e nelle metriche del server API.

Utilizza il playbook interattivo per i pod non pianificabili

Puoi risolvere i problemi relativi agli errori PodUnschedulable utilizzando il playbook interattivo nella console Cloud de Confiance :

1. Vai al playbook interattivo sui pod non pianificabili:

   Vai alla guida pratica

2. Nell'elenco a discesa Cluster, seleziona il cluster di cui vuoi risolvere i problemi. Se non riesci a trovare il cluster, inseriscine il nome nel campo filter_list Filtro.

3. Nell'elenco a discesa Spazio dei nomi, seleziona lo spazio dei nomi per cui vuoi risolvere i problemi. Se non riesci a trovare il tuo spazio dei nomi, inseriscilo nel campo filter_list Filtro.

4. Per aiutarti a identificare la causa, esamina ogni sezione del playbook:

   1. Esamina CPU e memoria
   2. Esamina il numero massimo di pod per nodo
   3. Esamina il comportamento del gestore della scalabilità automatica
   4. Esamina altre modalità di errore
   5. Correla eventi di modifica

5. (Facoltativo) Per ricevere notifiche sugli errori futuri di PodUnschedulable, nella sezione Suggerimenti per la mitigazione futura, seleziona Crea un avviso.

Errore: risorse insufficienti

Lo stato PodUnschedulable può verificarsi se non sono disponibili CPU, memoria o altre risorse sufficienti per soddisfare le richieste del pod.

Sintomi

Potresti riscontrare un errore che indica una mancanza di CPU, memoria o un'altra risorsa. Ad esempio: No nodes are available that match all of the predicates: Insufficient cpu (2). Questo messaggio indica che su due nodi non è disponibile una quantità di CPU sufficiente per soddisfare le richieste di un pod.

Causa

Se le richieste di risorse del pod superano quelle di un singolo nodo di uno dei pool di nodi idonei, GKE non pianifica il pod e non attiva lo scale up per aggiungere un nuovo nodo.

Il cluster esegue i container di sistema nello spazio dei nomi kube-system. Anche questi container utilizzano le risorse del cluster.

Risoluzione

Prova le seguenti soluzioni:

• Modifica la richiesta di risorse del pod specificando un valore inferiore nel campo spec: containers: resources: requests. La richiesta di CPU predefinita è 100 m o il 10% di una CPU (o un core).

• Crea un nuovo pool di nodi con nodi che dispongono di risorse sufficienti per soddisfare le richieste del pod.

• Attiva il provisioning automatico dei nodi in modo che GKE possa creare automaticamente i pool di nodi con i nodi in cui possono essere eseguiti i pod non pianificati.

Errore: MatchNodeSelector

Un errore MatchNodeSelector indica che non esistono nodi che corrispondono al selettore di etichette del pod.

Sintomi

Lo stato o gli eventi del pod mostrano un errore MatchNodeSelector.

Causa

Le etichette specificate nel campo nodeSelector del manifest del pod non esistono in nessun nodo del cluster.

Risoluzione

Per risolvere questo errore, assicurati che le etichette specificate nel campo nodeSelector del pod corrispondano alle etichette di almeno un nodo del cluster:

1. Identifica i requisiti dell'etichetta che il pod sta cercando controllando il campo spec: nodeSelector.

2. Per verificare se le etichette corrispondono ai requisiti del pod, visualizza le etichette effettive assegnate ai nodi del cluster:

   kubectl get nodes --show-labels
   

3. Se un nodo è destinato a eseguire questo pod, aggiungi l'etichetta necessaria:

   kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE
   

   Sostituisci quanto segue:

   • NODE_NAME: il nodo a cui vuoi aggiungere un'etichetta.
   • LABEL_KEY: la chiave dell'etichetta.
   • LABEL_VALUE: il valore dell'etichetta.

Per saperne di più, consulta la sezione Assegnazione di pod ai nodi nella documentazione di Kubernetes.

Errore: PodToleratesNodeTaints

Un errore PodToleratesNodeTaints indica che non è possibile pianificare il pod su nessun nodo perché il pod non ha tolleranze corrispondenti alle incompatibilità dei nodi esistenti.

Sintomi

Lo stato o gli eventi del pod mostrano un errore PodToleratesNodeTaints.

Causa

Il pod non può essere pianificato su alcun nodo perché non dispone di tolleranze che corrispondono alle incompatibilità dei nodi esistenti.

Risoluzione

1. Controlla i taint sul nodo:

   kubectl describe nodes NODE_NAME
   

   Nell'output, controlla il campo Taints, che elenca le coppie chiave-valore e gli effetti di pianificazione. Se l'effetto elencato è NoSchedule, non è possibile pianificare alcun pod su quel nodo, a meno che non abbia una tolleranza corrispondente.

2. Rimuovi il taint dal nodo. Ad esempio, per rimuovere un taint NoSchedule, esegui questo comando:

   kubectl taint nodes NODE_NAME key:NoSchedule-
   

Errore: PodFitsHostPorts

L'errore PodFitsHostPorts indica che un nodo sta tentando di utilizzare una porta già occupata.

Sintomi

Lo stato del pod mostra un errore PodFitsHostPorts.

Causa

Un pod richiede una porta host già in uso da un altro pod o processo sul nodo di destinazione.

Risoluzione

Per risolvere il problema, valuta la possibilità di seguire le best practice di Kubernetes e utilizza un servizio NodePort anziché l'impostazione hostPort.

Se devi utilizzare una porta host, controlla i manifest dei pod e assicurati che tutti i pod sullo stesso nodo abbiano valori univoci definiti per l'impostazione hostPort.

Errore: non ha disponibilità minima

Questo errore può verificarsi se un nodo dispone di risorse adeguate, ma non è disponibile per la pianificazione.

Sintomi

• Visualizzi l'errore Does not have minimum availability.

• Lo stato del nodo mostra uno stato SchedulingDisabled o Cordoned.

Causa

Lo stato di isolamento del nodo impedisce la pianificazione di nuovi pod.

Risoluzione

Per rendere nuovamente disponibile il nodo per la pianificazione dei pod, annulla l'isolamento:

kubectl get nodes

kubectl uncordon NODE_NAME

Errore: è stato raggiunto il limite massimo di pod per nodo

Un errore Too many pods indica che un pod non può essere pianificato perché il nodo di destinazione ha raggiunto la capacità massima di pod configurata.

Sintomi

• I pod sono bloccati nello stato Unschedulable.
• Viene visualizzato un messaggio che include la frase Too many pods.

Causa

Il limite di Numero massimo di pod per nodo è raggiunto da tutti i nodi del cluster.

Risoluzione

Per risolvere questo errore, completa i seguenti passaggi:

1. Controlla la configurazione di Maximum pods per node dalla scheda Nodi nei dettagli del cluster GKE nella console Cloud de Confiance .

2. Ottieni un elenco di nodi:

   kubectl get nodes
   

3. Per ogni nodo, verifica il numero di pod in esecuzione sul nodo:

   kubectl get pods -o wide | grep NODE_NAME | wc -l
   

4. Se viene raggiunto il limite, aggiungi un nuovo pool di nodi o nodi aggiuntivi al pool di nodi esistente.

Problema: è stata raggiunta la dimensione massima del pool di nodi con il gestore della scalabilità automatica del cluster abilitato

Questo problema si verifica quando un pool di nodi ha raggiunto le dimensioni massime configurate nel gestore della scalabilità automatica del cluster.

Sintomi

GKE non attiva lo scale up per un pod che altrimenti verrebbe pianificato con questo pool di nodi. Il pod rimane invece nello stato Pending.

Causa

Il pool di nodi ha raggiunto la dimensione massima in base alla configurazione del gestore della scalabilità automatica del cluster.

Risoluzione

Aumenta le dimensioni massime del pool di nodi modificando la configurazione del gestore della scalabilità automatica dei cluster.

Problema: è stata raggiunta la dimensione massima del pool di nodi con il gestore della scalabilità automatica del cluster disabilitato

Questo problema si verifica quando un pool di nodi ha raggiunto le dimensioni massime e lo scalatore automatico del cluster è disabilitato.

Sintomi

GKE non può pianificare il pod con il pool di nodi.

Causa

Il pool di nodi ha raggiunto il numero massimo di nodi e il gestore della scalabilità automatica del cluster è disabilitato.

Risoluzione

Per risolvere il problema, prova una delle seguenti soluzioni:

• Aumenta le dimensioni del tuo node pool.
• Abilita il gestore della scalabilità automatica dei cluster per ridimensionare automaticamente il cluster.

Errore: PersistentVolumeClaim non associati

Un errore Unbound PersistentVolumeClaims indica che il pod fa riferimento a un PersistentVolumeClaim non associato.

Sintomi

Lo stato o gli eventi del pod mostrano un errore Unbound PersistentVolumeClaims.

Causa

Questo errore può verificarsi per uno dei seguenti motivi:

• Il provisioning di PersistentVolume non è riuscito.
• Si è verificato un errore di configurazione durante il pre-provisioning manuale di un PersistentVolume e della relativa associazione a un PersistentVolumeClaim.

Risoluzione

1. Verifica se il provisioning non è riuscito recuperando gli eventi per il tuo PersistentVolumeClaim:

   kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0
   

   Sostituisci quanto segue:

   • STATEFULSET_NAME: il nome dell'oggetto StatefulSet.
   • PVC_NAME: il nome dell'oggetto PersistentVolumeClaim.

2. Prova a eseguire di nuovo il provisioning preventivo del volume.

Errore: quota insufficiente

Se GKE tenta di scalare il cluster per pianificare un pod, ma riscontra vincoli di quota, lo scale up non va a buon fine.

Sintomi

Ricevi il messaggio di errore scale.up.error.quota.exceeded negli eventi del pod.

Causa

Lo scale up del cluster supererebbe la quota disponibile del progetto.

Risoluzione

Verifica che il tuo progetto disponga di una quota Compute Engine sufficiente per consentire a GKE di scalare il cluster. Per saperne di più, consulta Errori di scale up.

Problema: API deprecate

L'utilizzo di API non più supportate nei manifest può impedire il deployment del workload.

Sintomi

I workload non vengono sottoposti a deployment o non vengono eseguiti a causa dell'utilizzo di API ritirate.

Causa

I tuoi manifest utilizzano API deprecate che vengono rimosse nella versione secondaria del cluster.

Risoluzione

Assicurati di non utilizzare API ritirate. Aggiorna i manifest per utilizzare le API supportate. Per saperne di più, vedi Ritiri di funzionalità e API.

Errore: non sono disponibili porte libere per le porte del pod richieste

L'associazione di un pod a una porta host limita i punti in cui GKE può pianificare il pod, perché ogni combinazione di indirizzo hostIP, impostazione hostPort e valore protocol deve essere univoca.

Sintomi

Viene visualizzato un errore simile al seguente:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

Causa

Più pod sullo stesso nodo specificano lo stesso valore definito nel campo hostPort.

Risoluzione

Per risolvere il problema, prova una delle seguenti soluzioni:

• Segui le best practice di Kubernetes e utilizza un servizio NodePort anziché una porta host.
• Se devi utilizzare una porta host, controlla i manifest dei pod e assicurati che tutti i pod sullo stesso nodo abbiano valori univoci definiti per il campo hostPort.

Problema: errori dell'applicazione e dei probe nei pod

Questo problema si verifica quando esegui applicazioni che utilizzano HTTPS per comunicare con un server.

Sintomi

Gli errori in queste applicazioni sono simili ai seguenti:

• I pod non vengono avviati e i container si arrestano in modo anomalo con il codice di uscita 137.

• I probe di attività o di idoneità non riescono con un messaggio di errore simile al seguente:

  probeResult="failure" output="Get "https://example.com/healthy": EOF"
  

• I pod vengono eseguiti come previsto, ma i log delle applicazioni mostrano errori di connessione.

Causa

Le versioni di Kubernetes 1.30 e successive utilizzano versioni di Golang che disattivano le seguenti suite di crittografia TLS:

• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA

Risoluzione

Utilizza le suite di cifrari supportate da TLS 1.2 e versioni successive.

Passaggi successivi

• Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta Richiedere assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:

  • Aprire una richiesta di assistenza contattando l'assistenza clienti Google Cloud.
  • Ricevere assistenza dalla community ponendo domande su Stack Overflow e utilizzando il tag google-kubernetes-engine per cercare problemi simili. Puoi anche unirti al canale Slack #kubernetes-engine per assistenza dalla community.
  • Apertura di problemi o richieste di funzionalità utilizzando l'Issue Tracker pubblico.