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

Autopilot Standard

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

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

Tutti gli errori: controlla lo stato del pod

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

Console

Segui questi passaggi:

1. Nella Google Cloud console, vai alla pagina Workload.

   Vai a Carichi di lavoro

2. Seleziona il workload che vuoi esaminare. La scheda Panoramica mostra lo stato del workload.

3. Nella sezione Pod gestiti, fai clic su un messaggio di stato di errore.

kubectl

Per visualizzare tutti i pod in esecuzione nel cluster, esegui questo comando:

kubectl get pods

L'output è simile al seguente:

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

I potenziali errori sono elencati nella colonna Status.

Per ulteriori informazioni su un pod specifico, esegui questo comando:

kubectl describe pod POD_NAME

Sostituisci POD_NAME con il nome del pod che vuoi esaminare.

Nell'output, il campo Events mostra ulteriori informazioni sugli errori.

Per ulteriori informazioni, visualizza i log dei container:

kubectl logs POD_NAME

Questi log possono aiutarti a identificare se un comando o un codice nel container ha causato l'arresto anomalo del pod.

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

Errore: CrashLoopBackOff

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

Per ulteriori informazioni, consulta Risolvere i problemi relativi agli eventi CrashLoopBackOff.

Errori: ImagePullBackOff e ErrImagePull

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

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

Errore: OutOfPods

Lo stato OutOfPods indica che un nodo non può eseguire un pod perché 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 le maggiori richieste di risorse.

• Abilita il gestore della scalabilità automatica dei cluster e il provisioning automatico dei nodi. Se spesso esaurisci la capacità dei pod, l'abilitazione 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à il gestore della scalabilità automatica dei cluster, prova a modificare il profilo di scalabilità automatica in balanced anziché in optimize-utilization. Il profilo optimize-utilization può aumentare la probabilità di errori OutOfPods perché tenta di inserire 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 Google Cloud console:

1. Vai al playbook interattivo per i pod non pianificabili:

   Vai al playbook

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

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

4. Per aiutarti a identificare la causa, esamina ciascuna delle sezioni 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 sui futuri errori 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 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 node pool 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.

• Abilita il provisioning automatico dei nodi in modo che GKE possa creare automaticamente node pool con 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 su 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 delle etichette 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, collega 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 ulteriori informazioni, consulta Assegnare pod ai nodi nella documentazione di Kubernetes.

Errore: PodToleratesNodeTaints

Un errore PodToleratesNodeTaints indica che il pod non può essere pianificato su nessun nodo perché non ha tolleranze che corrispondono 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 nessun nodo perché non ha tolleranze che corrispondono alle incompatibilità dei nodi esistenti.

Risoluzione

1. Controlla le incompatibilità del 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, nessun pod può essere pianificato su quel nodo a meno che non abbia una tolleranza corrispondente .

2. Rimuovi l'incompatibilità dal nodo. Ad esempio, per rimuovere un'incompatibilità NoSchedule, esegui questo comando:

   kubectl taint nodes NODE_NAME key:NoSchedule-
   

Errore: PodFitsHostPorts

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

Sintomi

Lo stato del pod mostra un errore PodFitsHostPorts.

Causa

Un pod sta richiedendo 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 utilizzare 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

• Viene visualizzato l'errore Does not have minimum availability.

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

Causa

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

Risoluzione

Per rendere di nuovo disponibile il nodo per la pianificazione dei pod, rimuovi l'isolamento:

Console

Segui questi passaggi:

1. Vai alla pagina Google Kubernetes Engine nella Google Cloud console.

   Vai a Google Kubernetes Engine

2. Seleziona il cluster che vuoi esaminare. La scheda Nodi mostra i nodi e il relativo stato.

Per abilitare la pianificazione sul nodo, segui questi passaggi:

1. Nell'elenco, fai clic sul nodo che vuoi esaminare.

2. Nella sezione Dettagli nodo, fai clic su Rimuovi isolamento.

kubectl

Per ottenere lo stato dei nodi, esegui questo comando:

kubectl get nodes

Per abilitare la pianificazione sul nodo, esegui:

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 in uno stato Unschedulable.
• Viene visualizzato un messaggio che include la frase Too many pods.

Causa

Il limite 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 Maximum pods per node nella scheda Nodi dei dettagli del cluster GKE nella Google Cloud console.

2. Recupera 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 il limite è raggiunto, aggiungi un nuovo pool di nodi o altri nodi al pool di nodi esistente.

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

Questo problema si verifica quando un pool di nodi ha raggiunto la dimensione massima configurata nel gestore della scalabilità automatica dei cluster.

Sintomi

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

Causa

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

Risoluzione

Aumenta la dimensione massima del pool di nodi modificando la configurazione del gestore della scalabilità automatica dei cluster.

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

Questo problema si verifica quando un pool di nodi ha raggiunto la dimensione massima e il gestore della scalabilità automatica dei 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 dei cluster è disabilitato.

Risoluzione

Per risolvere il problema, prova una delle seguenti soluzioni:

• Aumenta le dimensioni del node pool.
• Abilita il gestore della scalabilità automatica dei clusterper 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 provisioning preventivo manuale di un PersistentVolume e il relativo binding a un PersistentVolumeClaim.

Risoluzione

1. Verifica se il provisioning non è riuscito recuperando gli eventi per 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 eseguire lo scale up del cluster per pianificare un pod, ma riscontra vincoli di quota, lo scale up non riesce.

Sintomi

Viene visualizzato 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 progetto disponga di una quota di Compute Engine sufficiente per consentire a GKE di eseguire lo scale up del cluster. Per ulteriori informazioni, consulta Errori di scale up.

Problema: API obsolete

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

Sintomi

Il deployment o l'esecuzione dei workload non riesce a causa dell'utilizzo di API obsolete.

Causa

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

Risoluzione

Assicurati di non utilizzare API obsolete. Aggiorna i manifest in modo che utilizzino le API supportate. Per ulteriori informazioni, consulta Deprecazioni di funzionalità e API.

Errore: Didn't have free ports for the requested Pod ports

L'associazione di un pod a una porta host limita la posizione 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 di applicazione e 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 a essere eseguiti e viene visualizzato 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 disabilitano 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 crittografia 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.
  • Ottenere assistenza dalla community ponendo domande su Stack Overflow e utilizzando il tag google-kubernetes-engine per cercare problemi simili. Puoi anche unirti al #kubernetes-engine canale Slack per ulteriore assistenza dalla community.
  • Aprire richieste di funzionalità o problemi utilizzando il monitoraggio pubblico dei problemi.