3. Troubleshooting

Formation suivie via le blog de Stéphane Robert : parcours Kubernetes.

Le Deployment reste à 0/1

Commandes à exécuter :

kubectl describe deployment nginx -n demo-app
kubectl get events -n demo-app

Ce que vous voyez	Ce que ça veut dire	Par quoi commencer
ErrImagePull, puis ImagePullBackOff	le nœud n’arrive pas à récupérer l’image	relire le nom et le tag : une faute de frappe donne exactement cette erreur. Ensuite seulement : image privée sans identifiants, ou registry injoignable
Pending sans événement d’image	aucun nœud ne peut accueillir le Pod	ressources insuffisantes, ou contrainte de placement

Note

ImagePullBackOff est un symptôme, pas une cause : il dit que le téléchargement a échoué et que Kubernetes réessaie en espaçant. La cause se lit dans les événements, et la plus fréquente reste la plus bête.

Le Pod est en CrashLoopBackOff

CrashLoopBackOff signifie que le conteneur démarre puis s’arrête, en boucle. Le délai entre deux redémarrages double à chaque échec (10 s, 20 s, 40 s…) et plafonne à 5 minutes.

Le piège

Au moment où vous tapez kubectl logs, le conteneur vient de redémarrer et n’a encore rien écrit. Les logs qui vous intéressent sont ceux de l’exécution précédente, celle qui a planté.

kubectl logs <nom-du-pod> -n demo-app --previous

C’est le rôle du flag --previous. S’il répond unable to retrieve container logs, aucune exécution précédente n’est disponible : relancez sans le flag, le conteneur courant a peut-être eu le temps d’écrire.

Le Service ne répond pas

Un Service qui ne répond pas n’est presque jamais cassé : il fonctionne, mais il ne pointe vers rien.

kubectl get pods --show-labels
kubectl describe service nginx -n demo-app

Vérifiez que Endpoints n’est pas vide et que les labels correspondent bien.

Le namespace reste en Terminating

Si ça dure trop longtemps, cherchez au niveau des Finalizers, qui peuvent bloquer la suppression.