Kubernetes CrashLoopBackOff

Diagnostiquer les pods qui redémarrent en boucle.

CrashLoopBackOff signifie que Kubernetes essaie de redémarrer un pod qui crash continuellement. Chaque tentative est espacée exponentiellement. Voici comment résoudre ce problÚme.

SymptĂŽmes

  • Pod en status CrashLoopBackOff
  • Restart count qui augmente
  • Service inaccessible
  • Events montrant des redĂ©marrages rĂ©pĂ©tĂ©s

Causes Fréquentes

  • Application qui crash : Le processus principal retourne une erreur ou une exception.
  • Liveness probe qui Ă©choue : K8s tue le container car la probe ne rĂ©pond pas.
  • Ressources insuffisantes : OOMKilled car les limits sont trop basses.

Étapes de Diagnostic

  1. Décrivez le pod : kubectl describe pod [name]
  2. Examinez les logs : kubectl logs [pod] --previous
  3. Vérifiez les events du namespace
  4. Analysez les ressources (CPU, RAM)

Automatiser avec MoniTao

MoniTao surveille vos services Kubernetes :

  • Monitoring HTTP de vos Ingress/Services
  • Alertes quand le service ne rĂ©pond plus
  • Heartbeat pour les CronJobs K8s

Bonnes Pratiques

  • Configurez des probes avec des timeouts rĂ©alistes
  • Utilisez des resource requests et limits
  • ImplĂ©mentez un graceful shutdown
  • Centralisez les logs pour le debugging

Questions Fréquentes

Différence entre liveness et readiness probe ?

Liveness : est-ce que le container fonctionne ? Readiness : est-il prĂȘt Ă  recevoir du trafic ?

Que signifie OOMKilled ?

Le container a dépassé sa limite mémoire et a été tué.

Comment voir les logs d'un container crashé ?

kubectl logs [pod] --previous montre les logs de l'instance précédente.

MoniTao peut-il surveiller K8s directement ?

Il surveille vos services via HTTP. Pour les métriques K8s, utilisez Prometheus.

PrĂȘt Ă  dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.