Partager via

Pod is stuck in CrashLoopBackOff mode

If a pod has a CrashLoopBackOff status, then the pod probably failed or exited unexpectedly, and the log contains an exit code that isn't zero. Voici plusieurs raisons possibles pour lesquelles votre pod est bloqué en CrashLoopBackOff mode :

  1. Échec de l’application : l’application à l’intérieur du conteneur se bloque peu après le démarrage, souvent en raison de configurations incorrectes, de dépendances manquantes ou de variables d’environnement incorrectes.
  2. Limites de ressources incorrectes : si le pod dépasse ses limites de ressources processeur ou mémoire, Kubernetes peut tuer le conteneur. Ce problème peut se produire si les demandes de ressources ou les limites sont trop faibles.
  3. ConfigMaps/Secrets manquants ou mal configurés : si l’application s’appuie sur des fichiers de configuration ou des variables d’environnement stockés dans ConfigMaps ou Secrets, mais qu’elles sont manquantes ou mal configurées, l’application peut se bloquer.
  4. Problèmes d’extraction d’image : s’il existe un problème avec l’image (par exemple, il est endommagé ou a une balise incorrecte), le conteneur peut ne pas démarrer correctement et échouer à plusieurs reprises.
  5. Échec des conteneurs Init : si le pod a des conteneurs Init et que l’un ou plusieurs ne fonctionnent pas correctement, le pod redémarre.
  6. Échecs des sondes de vivacité et de préparation : si les sondes liveness et readiness sont mal configurées, Kubernetes peut détecter que le conteneur n'est pas sain et le redémarrer.
  7. Dépendances d’application non prêtes : l’application peut dépendre des services qui ne sont pas encore prêts, tels que les bases de données, les files d’attente de messages ou d’autres API.
  8. Problèmes de mise en réseau : les mauvaises configurations réseau peuvent empêcher l’application de communiquer avec les services nécessaires, ce qui entraîne son échec.
  9. Invalid commands or arguments: The container might be started with an invalid ENTRYPOINT, command, or argument, leading to a crash.

Pour plus d’informations sur l’état du conteneur, consultez Cycle de vie des pods - États du conteneur.

Tenez compte des options suivantes et de leurs commandes kubectl associées.

Option kubectl command
Debug the pod itself kubectl describe pod <pod-name>
Déboguer les contrôleurs de réplication kubectl describe replicationcontroller <controller-name>
Lire le message d’arrêt kubectl get pod <pod-name> --output=yaml
Examiner les journaux d’activité kubectl logs <pod-name>

Note

Un pod peut également avoir un CrashLoopBackOff état s’il a terminé le déploiement, mais il est configuré pour continuer à redémarrer même si le code de sortie est égal à zéro. Par exemple, si vous déployez une image busybox sans spécifier d’arguments, l’image démarre, s’exécute, se termine, puis redémarre dans une boucle :

$ 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

Si vous ne reconnaissez pas le problème après avoir créé d’autres pods sur le nœud, exécutez un pod sur un nœud unique pour déterminer le nombre de ressources que le pod utilise réellement.

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.