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 reviennent dans 80% des cas en production Kubernetes : le CrashLoopBackOff, le Pod Pending et l’ImagePullBackOff. Chacun signale un problème différent — respectivement problème applicatif, problème de scheduling, problème d’accès au registre.

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

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

À 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

Prochaines étapes

Hub — Opérer Kubernetes Vue d'ensemble du parcours exploitation et tous les blocs thématiques.

Maintenance et changements Cordon, drain, mise à jour de cluster : intervenir sans casser la production.