Il pod è bloccato in modalità CrashLoopBackOff

Se un pod ha uno stato di CrashLoopBackOff, il pod probabilmente è fallito oppure è stato chiuso in modo imprevisto e il log contiene un codice di uscita diverso da zero. Ecco alcuni possibili motivi per cui il pod è bloccato in modalità CrashLoopBackOff.

1. Errore dell'applicazione: l'applicazione all'interno del contenitore si arresta in modo anomalo poco dopo l'avvio, spesso a causa di errori di configurazione, dipendenze mancanti o variabili di ambiente non corrette.
2. Limiti di risorse non corretti: se il pod supera i limiti delle risorse di CPU o memoria, Kubernetes potrebbe terminare il contenitore. Questo problema può verificarsi se le richieste o i limiti delle risorse sono impostati troppo bassi.
3. ConfigMaps/Secrets mancanti o non configurati correttamente: se l'applicazione si basa su file di configurazione o variabili di ambiente archiviate in ConfigMaps o Secrets, ma questi sono mancanti o mal configurati, l'applicazione potrebbe andare in crash.
4. Problemi di pull dell'immagine: se si verifica un problema con l'immagine (ad esempio, è danneggiata o ha un tag errato), il contenitore potrebbe non avviarsi correttamente e fallire ripetutamente.
5. Errore dei contenitori di inizializzazione: Se il pod ha contenitori di inizializzazione e uno o più contenitori non vengono eseguiti correttamente, il pod verrà riavviato.
6. Errori di probe di vivacità/prontezza: Se il probe di vivacità o prontezza non è configurato correttamente, Kubernetes potrebbe rilevare il contenitore come non sano e riavviarlo.
7. Dipendenze dell'applicazione non pronte: l'applicazione potrebbe dipendere da servizi non ancora pronti, ad esempio database, code di messaggi o altre API.
8. Problemi di rete: le configurazioni di rete possono impedire all'applicazione di comunicare con i servizi necessari, causando un errore.
9. Comandi o argomenti non validi: il contenitore potrebbe essere avviato con un comando , o un argomento non valido ENTRYPOINT, causando un arresto anomalo.

Per altre informazioni sullo stato del contenitore, vedere Ciclo di vita dei pod - Stati del contenitore.

Prendere in considerazione le opzioni seguenti e i relativi comandi kubectl.

Opzione	Comando kubectl
Eseguire il debug del pod stesso	kubectl describe pod <pod-name>
Eseguire il debug dei controller di replica	kubectl describe replicationcontroller <controller-name>
Leggere il messaggio di terminazione	kubectl get pod <pod-name> --output=yaml
Esaminare i registri	kubectl logs <pod-name>

Note

Un pod può anche avere uno CrashLoopBackOff stato se ha terminato la distribuzione, ma è configurato per mantenere il riavvio anche se il codice di uscita è zero. Ad esempio, se si distribuisce un'immagine busybox senza specificare argomenti, l'immagine viene avviata, eseguita, completata e quindi riavviata in un ciclo:

$ kubectl run nginx --image nginx
pod/nginx created

$ kubectl run busybox --image busybox
pod/busybox created

$ kubectl get pods --watch
NAME     READY  STATUS             RESTARTS  AGE
busybox  0/1    ContainerCreating  0         3s
nginx    1/1    Running            0         11s
busybox  0/1    Completed          0         3s
busybox  0/1    Completed          1         4s
busybox  0/1    CrashLoopBackOff   1         5s

$ kubectl describe pod busybox
Name:         busybox
Namespace:    default
Priority:     0
Node:         aks-nodepool<number>-<resource-group-hash-number>-vmss<number>/<ip-address-1>
Start Time:   Wed, 16 Aug 2023 09:56:19 +0000
Labels:       run=busybox
Annotations:  <none>
Status:       Running
IP:           <ip-address-2>
IPs:
  IP:  <ip-address-2>
Containers:
  busybox:
    Container ID:   containerd://<64-digit-hexadecimal-value-1>
    Image:          busybox
    Image ID:       docker.io/library/busybox@sha256:<64-digit-hexadecimal-value-2>
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 16 Aug 2023 09:56:37 +0000
      Finished:     Wed, 16 Aug 2023 09:56:37 +0000
    Ready:          False
    Restart Count:  2

Se non si riconosce il problema dopo aver creato più pod sul nodo, eseguire un pod su un singolo nodo per determinare quante risorse il pod utilizza effettivamente.

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.