Mon pod est en erreur

Votre pod apparaît dans kubectl get pods, mais son statut n’est pas Running (ou il redémarre en boucle). Cette page couvre les trois cas les plus fréquents, avec les causes propres à Kontainers qu’un habitué d’un autre cluster ne devinerait pas.

Commencez toujours par :

kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous

CrashLoopBackOff

Le conteneur démarre puis s’arrête, en boucle. Kubernetes espace les redémarrages (back-off), d’où des périodes d’attente croissantes.

C’est presque toujours votre application qui se termine : configuration manquante, dépendance injoignable, erreur au boot. Les logs de l’exécution précédente (--previous) contiennent la vraie erreur.

Vérifiez notamment :

• une variable d’environnement ou un secret manquant (ConfigMaps et Secrets) ;
• une dépendance pas encore prête (base de données…) — ajoutez une readinessProbe et laissez le pod redémarrer, ou un initContainer d’attente ;
• une dépendance dans un namespace d’une autre organisation : bloquée par design (isolation réseau).

ImagePullBackOff

L’image ne peut pas être téléchargée.

kubectl describe pod <pod> -n <namespace> | grep -A3 "Failed"

Causes classiques : nom d’image mal orthographié, tag inexistant, registre privé sans pull secret.

Spécificité Kontainers

imagePullPolicy est forcé à Always : l’image est re-vérifiée auprès du registre à chaque démarrage, même si elle est déjà sur le nœud. Conséquence : un token de registre expiré ou un registre en panne empêche vos pods de redémarrer — y compris ceux qui tournaient très bien jusque-là. Si un pod qui n’a pas changé tombe en ImagePullBackOff, vérifiez d’abord votre registre et la validité de votre pull secret.

OOMKilled

Le conteneur a dépassé sa mémoire allouée et a été tué. Repérable dans describe pod :

Last State:  Terminated
  Reason:    OOMKilled

Spécificité Kontainers — lisez avant d’augmenter la limite

Sur Kontainers, la limite mémoire est toujours égale à la request. Le réflexe habituel « j’augmente limits.memory » ne fonctionne pas : la limite serait ramenée à la request. Pour donner plus de mémoire à votre conteneur, augmentez requests.memory :

resources:
  requests:
    memory: 512Mi   # ← c'est cette valeur qui fait foi (et qui est facturée)

Dimensionnez la request sur le pic réel de consommation, visible dans votre monitoring ou via :

kubectl top pods -n <namespace>

Ce n’est pas l’un de ces trois cas ?

• Aucun pod ne se crée du tout → Checklist de diagnostic ;
• Le pod tourne mais l’application est injoignable → Checklist : site injoignable ;
• Toujours bloqué → contactez le support avec la sortie de kubectl describe pod et les logs.