Panne / symptôme

Un Pod Kubernetes reste en CrashLoopBackOff

Le conteneur démarre puis s’arrête en boucle et Kubernetes augmente progressivement le délai entre les redémarrages.

⌚ Environ 4 min de lecture
Voir mes favoris
Problème réel · V2

Vue diagnostic rapide

Ce que vous observez

Le conteneur démarre puis s’arrête en boucle et Kubernetes augmente progressivement le délai entre les redémarrages.

Causes probables
  1. Erreur applicative au démarrage
  2. Secret, variable ou volume manquant
  3. Probe trop agressive
Premiers contrôles
  1. kubectl describe pod pour les événements
  2. kubectl logs --previous pour le crash précédent
  3. Contrôle des probes et limites
Actions recommandées
  1. Corriger uniquement le composant confirmé par les contrôles
  2. Rejouer le symptôme initial après la correction
  3. Escalader avec les preuves collectées si la cause reste indéterminée
Lancer Symptôme → Cause →
+
Afficher le guide détaillé completExplications détaillées et contenu de dépannage original.

Le conteneur démarre puis s’arrête en boucle et Kubernetes augmente progressivement le délai entre les redémarrages.

Causes probables

  • Erreur applicative au démarrage
  • Secret, variable ou volume manquant
  • Probe trop agressive
  • Limite mémoire atteinte

Contrôles par ordre de priorité

  1. kubectl describe pod pour les événements
  2. kubectl logs –previous pour le crash précédent
  3. Contrôle des probes et limites
  4. Vérification de la configuration du Deployment

Quand escalader

Escaladez lorsque la panne touche plusieurs utilisateurs, qu’une dépendance de production est indisponible ou que les journaux pointent vers un composant hors de votre contrôle. Joignez les horodatages, le périmètre, les tests déjà réalisés et le dernier état fonctionnel connu.

Validation du diagnostic

Pour « Un Pod Kubernetes reste en CrashLoopBackOff », capturez namespace, nom du Pod, image, nombre de redémarrages, Last State, Exit Code et événements récents. Consultez les logs courants et précédents ; CrashLoopBackOff décrit une boucle de redémarrage, mais la cause réelle se trouve souvent dans le processus, la configuration ou une dépendance.

Test discriminant

Utilisez describe et les logs du conteneur, puis vérifiez probes, ConfigMaps, Secrets, ressources et dépendances réseau. Comparez la spécification avec une révision fonctionnelle. Si le conteneur termine trop vite, utilisez les mécanismes de debug Kubernetes plutôt que de supprimer la ressource à répétition sans conserver les événements.

Critère de résolution

La résolution est confirmée lorsque le Pod reste Ready sans nouveau restart pendant une période représentative et que les probes réussissent. Contrôlez aussi le ReplicaSet ou le Deployment afin de vérifier que le correctif survit à une recréation du Pod et ne dépend pas d’un objet modifié manuellement.

Concepts liés

Référence primaire : Kubernetes — Debug Running Pods.

♡ 0