Diagnostiquer les incidents applicatifs Kubernetes

Quand un pod ne démarre pas, une même erreur peut avoir dix causes différentes. La clé n'est pas de connaître toutes les causes par cœur, c'est d'avoir une méthode reproductible qui descend du plus global (cluster, nœud) au plus précis (pod, conteneur, image).

Trois types d'incidents applicatifs couvrent la grande majorité des cas en production : le CrashLoopBackOff, le Pod Pending et l'ImagePullBackOff. Chacun désigne une couche différente : respectivement l'application, la planification, et l'accès au registre.

Méthode avant tout

Commencez par la méthode de diagnostic, avant les guides spécifiques. Elle apprend à qualifier n'importe quel incident en moins de cinq minutes, ce qui change complètement le rendement des guides suivants : vous savez lequel ouvrir.

Diagnostiquer en 3 commandes

Quelle que soit l'erreur affichée, ces trois commandes donnent le contexte initial :

# 1. État du pod et derniers événements
kubectl describe pod <nom-du-pod> -n <namespace>

# 2. Logs du conteneur en erreur (ou du précédent conteneur s'il a crashé)
kubectl logs <nom-du-pod> -n <namespace> --previous

# 3. Événements du namespace triés par timestamp
kubectl get events -n <namespace> --sort-by='.lastTimestamp'

Le champ Events: de describe et la sortie des logs suffisent à identifier la cause dans la majorité des cas.

Ce que chaque erreur signifie

Erreur	Signifie	Premier réflexe
CrashLoopBackOff	Le conteneur démarre puis se termine avec un code > 0	kubectl logs --previous
Pending	Le scheduler ne trouve pas de nœud compatible	kubectl describe pod → Events
ImagePullBackOff / ErrImagePull	Impossible de télécharger l'image	Vérifier le nom, le tag et les credentials

Glissez pour voir

Guides de cette section

Méthode de diagnostic d'un incident Kubernetes Approche systématique en 4 niveaux : cluster, nœud, pod, réseau.

Diagnostiquer un CrashLoopBackOff Backoff exponentiel, 6 causes fréquentes, méthodologie en 4 étapes avec kubectl.

Diagnostiquer un Pod Pending Resources insuffisantes, taints, affinité, PVC non lié : trouver pourquoi un pod ne démarre pas.

Diagnostiquer un ImagePullBackOff Registre inaccessible, tag introuvable, imagePullSecret manquant : débloquer en 5 minutes.

4 guides publiés

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Ne diagnostiquez pas à l'aveugle : kubectl describe et kubectl logs --previous répondent à 80% des cas
• CrashLoopBackOff = problème dans le conteneur lui-même (config, permissions, dépendance manquante)
• Pod Pending = problème de scheduling (ressources, taints, affinité, PVC)
• ImagePullBackOff = problème d'accès à l'image (nom, tag, credentials, réseau)
• Le backoff exponentiel de Kubernetes (10s → 20s → 40s… jusqu'à 5 min) est une protection, pas un bug

Pour aller plus loin

• Diagnostiquer un Pod Pending : Le Pod jamais planifié, faute de ressources ou de volume disponible.
• Diagnostiquer un ImagePullBackOff : Le Pod bloqué au téléchargement de son image, registre ou credentials en cause.
• Maintenance et changements : Les interventions planifiées, une fois les incidents subis maîtrisés.

×

📖 Voir la documentation →