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

Questa pagina mostra come risolvere gli errori relativi ai carichi di lavoro di cui è stato 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 Trusted Cloud 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 in modo anomalo ripetutamente dopo il riavvio. Quando un container si arresta in modo anomalo o esce poco dopo l'avvio (CrashLoop), Kubernetes tenta di riavviarlo. A ogni riavvio non riuscito, il ritardo (BackOff) prima del tentativo successivo aumenta in modo esponenziale (10 s, 20 s, 40 s e così via), fino a un massimo di 5 minuti.

Le sezioni seguenti ti aiutano a identificare il motivo per cui il container potrebbe arrestarsi in modo anomalo.

Utilizzare il playbook interattivo per i pod con arresto anomalo in loop

Inizia a risolvere i problemi che causano lo stato CrashLoopBackOff utilizzando il playbook interattivo nella console Trusted Cloud :

1. Vai al playbook interattivo sui pod con arresto anomalo in loop:

   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, inserisci il nome del cluster nel campo filter_list Filtra.

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 Filtra.

4. Esamina ogni sezione per identificare la causa:

   1. Identifica gli errori dell'applicazione
   2. Esamina i problemi di memoria
   3. Analisi delle interruzioni del nodo
   4. Esamina gli errori dei probe di attività
   5. Correla eventi di modifica

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

Ispezionare i log

Un container potrebbe arrestarsi in modo anomalo per diversi motivi e il controllo dei log di un pod può aiutarti a risolvere il problema alla radice.

Puoi controllare i log con la console Trusted Cloud o lo strumento a riga di comandokubectl.

Controlla il codice di uscita del container arrestato in modo anomalo

Per capire meglio perché il container è andato in arresto anomalo, trova il codice di uscita:

1. Descrivi il pod:

   kubectl describe pod POD_NAME
   

   Sostituisci POD_NAME con il nome del pod problematico.

2. Controlla il valore nel campo containers: CONTAINER_NAME: last state: exit code:

   • Se il codice di uscita è 1, il container si è arrestato in modo anomalo perché l'applicazione si è arrestata in modo anomalo.
   • Se il codice di uscita è 0, controlla per quanto tempo è stata eseguita l'app. I container terminano quando il processo principale dell'applicazione termina. Se l'esecuzione dell'app termina molto rapidamente, il container potrebbe continuare a riavviarsi. Se si verifica questo errore, una soluzione è impostare il campo restartPolicy su OnFailure. Dopo aver apportato questa modifica, l'app viene riavviata solo quando il codice di uscita non è 0.

Connettersi a un container in esecuzione

Per eseguire comandi bash dal container in modo da poter testare la rete o verificare se hai accesso ai file o ai database utilizzati dalla tua applicazione, apri una shell per il pod:

kubectl exec -it POD_NAME -- /bin/bash

Se nel pod è presente più di un container, aggiungi -c CONTAINER_NAME.

Errori: ImagePullBackOff ed ErrImagePull

Uno 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 al pull delle immagini.

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 maggiori 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 Trusted Cloud :

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, inserisci il nome del cluster nel campo filter_list Filtra.

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

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), che indica che su due nodi non è disponibile CPU sufficiente per soddisfare le richieste di un pod.

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. Affinché GKE pianifichi il pod, devi richiedere meno risorse per il pod o creare un nuovo pool di nodi con risorse sufficienti.

Puoi anche abilitare 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.

La richiesta di CPU predefinita è 100 m o il 10% di una CPU (o un core). Se vuoi richiedere più o meno risorse, specifica il valore nella specifica del pod in spec: containers: resources: requests.

Errore: MatchNodeSelector

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

Per verificarlo, controlla le etichette specificate nel campo nodeSelector della specifica del pod, in spec: nodeSelector.

Per vedere come vengono etichettati i nodi del cluster, esegui questo comando:

kubectl get nodes --show-labels

Per collegare un'etichetta a un nodo, esegui questo comando:

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

PodToleratesNodeTaints indica che il pod non può essere pianificato su alcun nodo perché non dispone di tolleranze corrispondenti alle incompatibilità dei nodi esistenti.

Per verificare che sia effettivamente così, esegui questo comando:

kubectl describe nodes NODE_NAME

Nell'output, controlla il campo Taints, che elenca le coppie chiave-valore e gli effetti della pianificazione.

Se l'effetto elencato è NoSchedule, nessun pod può essere pianificato su quel nodo a meno che non abbia una tolleranza corrispondente.

Un modo per risolvere il problema è rimuovere il taint. 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.

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

Se devi utilizzare un hostPort, controlla i manifest dei pod e assicurati che tutti i pod sullo stesso nodo abbiano valori univoci definiti per hostPort.

Errore: Non ha disponibilità minima

Se un nodo dispone di risorse adeguate, ma visualizzi ancora il messaggio Does not have minimum availability, controlla lo stato del pod. Se lo stato è SchedulingDisabled o Cordoned, il nodo non può pianificare nuovi pod. Puoi controllare lo stato di un nodo utilizzando la console Trusted Cloud o lo strumento a riga di comando kubectl.

kubectl get nodes

kubectl uncordon NODE_NAME

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

Se il limite Numero massimo di pod per nodo viene raggiunto da tutti i nodi del cluster, i pod rimarranno nello stato Non pianificabile. Nella scheda Eventi del pod, viene visualizzato un messaggio che include la frase Too many pods.

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 Trusted Cloud .

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 la scalabilità automatica del cluster abilitata

Se il pool di nodi ha raggiunto le dimensioni massime in base alla configurazione dello strumento di scalabilità automatica del cluster, GKE non attiva lo scale up per il pod che altrimenti verrebbe pianificato con questo node pool. Se vuoi che il pod venga pianificato con questo pool di nodi, modifica la configurazione del gestore della scalabilità automatica del cluster.

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

Se il pool di nodi ha raggiunto il numero massimo di nodi e il gestore della scalabilità automatica dei cluster è disabilitato, GKE non può pianificare il pod con il pool di nodi. Aumenta le dimensioni del node pool o attiva la scalabilità automatica del cluster per consentire a GKE di ridimensionare automaticamente il cluster.

Errore: PersistentVolumeClaim non associati

Unbound PersistentVolumeClaims indica che il pod fa riferimento a un PersistentVolumeClaim non vincolato. Questo errore può verificarsi se il provisioning di PersistentVolume non è riuscito. Puoi verificare che il provisioning non sia riuscito recuperando gli eventi per il tuo PersistentVolumeClaim ed esaminandoli per individuare gli errori.

Per ottenere gli eventi, esegui questo comando:

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.

Ciò può verificarsi anche se si è verificato un errore di configurazione durante il pre-provisioning manuale di un PersistentVolume e il relativo binding a un PersistentVolumeClaim.

Per risolvere questo errore, prova a eseguire di nuovo il provisioning preventivo del volume.

Errore: quota insufficiente

Verifica che il tuo progetto disponga di una quota Compute Engine sufficiente per GKE per scalare il cluster. Se GKE tenta di aggiungere un nodo al cluster per pianificare il pod e lo scale up supererebbe la quota disponibile del progetto, viene visualizzato il messaggio di errore scale.up.error.quota.exceeded.

Per saperne di più, consulta Errori di ScaleUp.

Problema: API deprecate

Assicurati di non utilizzare API ritirate che vengono rimosse con la versione secondaria del cluster. Per saperne di più, consulta la sezione Deprecazione di funzionalità e API.

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

Se visualizzi un errore simile al seguente, probabilmente hai più pod sullo stesso nodo con lo stesso valore definito nel campo hostPort:

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.

Il binding di un pod a un hostPort limita la posizione in cui GKE può pianificare il pod, perché ogni combinazione di hostIP, hostPort e protocol deve essere univoca.

Per risolvere il problema, valuta la possibilità di seguire le best practice di Kubernetes e di utilizzare un NodePort anziché un hostPort.

Se devi utilizzare un hostPort, controlla i manifest dei pod e assicurati che tutti i pod sullo stesso nodo abbiano valori univoci definiti per hostPort.

Passaggi successivi

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

  • Aprire una richiesta di assistenza contattando l'assistenza clienti cloud.
  • Ricevere assistenza dalla community ponendo domande su StackOverflow e utilizzando il tag google-kubernetes-engine per cercare problemi simili. Puoi anche unirti al canale Slack #kubernetes-engine per ulteriore assistenza della community.
  • Apertura di bug o richieste di funzionalità utilizzando lo strumento di monitoraggio dei problemi pubblico.