Kubernetes 012 – Pods : les status, CrashLoopBackOff, Running, Completed

TL;DR

Le status d’un pod ne suffit pas toujours, mais il oriente le diagnostic. Pending indique souvent un probleme de scheduling ou d’image en attente, Running signifie qu’au moins un conteneur tourne, Completed concerne les taches terminees, CrashLoopBackOff indique des redemarrages repetes.

La video de reference

Video: https://www.youtube.com/watch?v=3iyMOfgZqAo

Elle donne les reflexes de lecture indispensables pour depanner les premiers workloads.

Les status les plus courants

| Status | Lecture rapide |

|---|---|

| Pending | pas encore execute correctement sur un noeud |

| Running | pod assigne et conteneur actif |

| Succeeded / Completed | execution terminee avec succes |

| Failed | execution terminee en erreur |

| CrashLoopBackOff | conteneur qui crashe en boucle |

Commandes de diagnostic

kubectl get pods
kubectl describe pod <pod>
kubectl logs <pod>
kubectl logs <pod> --previous
kubectl get events --sort-by=.lastTimestamp

--previous est utile quand le conteneur redemarre trop vite: il permet de lire les logs de l’instance precedente.

Ne pas s’arreter au premier mot

Un pod Running peut ne pas etre pret. Il faut regarder les conditions, les probes, les logs et parfois les evenements. De meme, CrashLoopBackOff n’est pas la cause mais le symptome: l’application sort en erreur, Kubernetes attend puis relance.

Liens utiles

• Video: https://www.youtube.com/watch?v=3iyMOfgZqAo
• Cycle de vie des pods: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
• Debug pods: https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/
• Logs Kubernetes: https://kubernetes.io/docs/concepts/cluster-administration/logging/

FAQ

Que faire en premier face a CrashLoopBackOff ?

Lire kubectl logs <pod> --previous, puis kubectl describe pod <pod>.

Running veut-il dire que l’application marche ?

Pas forcement. Cela indique que le conteneur tourne, pas que le service repond correctement.

Pourquoi regarder les events ?

Ils indiquent les decisions et erreurs vues par Kubernetes: scheduling, pull d’image, montage de volume, redemarrages.

Differencier phase, conditions et container status

Le status d’un pod ne se resume pas a un seul mot. La phase donne une vue globale: Pending, Running, Succeeded, Failed, Unknown. Les conditions indiquent des aspects comme Initialized, Ready ou ContainersReady. Les containerStatuses donnent le detail par conteneur: etat courant, dernier etat, nombre de redemarrages, image et readiness.

Pour voir ces informations:

kubectl get pod <pod> -o yaml
kubectl describe pod <pod>

Cette lecture evite les conclusions trop rapides. Un pod peut etre Running mais pas Ready, donc non disponible pour le trafic.

Comprendre CrashLoopBackOff

CrashLoopBackOff signifie que le conteneur demarre, s’arrete, puis Kubernetes attend avant de relancer. Le delai augmente progressivement pour eviter une boucle trop agressive. La cause est souvent dans l’application: commande incorrecte, variable manquante, configuration invalide, dependance inaccessible.

Le reflexe:

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

--previous est souvent la cle, car le conteneur actuel peut etre deja reparti ou en attente.

ImagePullBackOff et ErrImagePull

Ces status concernent la recuperation d’image. Les causes classiques sont: nom d’image incorrect, tag inexistant, registry privee sans secret, probleme reseau ou limite de pull. Dans ce cas, les logs applicatifs ne servent a rien car l’application n’a jamais demarre.

Erreurs frequentes

• Chercher des logs alors que l’image n’a pas ete tiree.
• Confondre Completed avec une erreur pour un job ou une commande courte.
• Ne pas regarder le nombre de redemarrages.
• Oublier les probes readiness/liveness dans l’analyse.

Pour pratiquer

kubectl run ok --image=nginx
kubectl run bad-image --image=nginx:tag-inexistant
kubectl run crash --image=busybox --command -- sh -c 'exit 1'
kubectl get pods
kubectl describe pod bad-image
kubectl logs crash --previous

Ces trois cas montrent trois lectures differentes du status.

Pending: plusieurs causes possibles

Un pod en Pending n’a pas encore atteint une execution normale. La cause peut etre simple ou plus structurelle: aucun noeud disponible, ressources insuffisantes, contrainte de placement impossible, volume non monte, image en attente ou probleme de scheduler.

Le bon reflexe est de lire les events:

kubectl describe pod <pod>
kubectl get events --sort-by=.lastTimestamp

Si les events mentionnent Insufficient cpu ou Insufficient memory, le probleme vient des ressources demandees ou de la capacite du cluster. Si les events parlent d’un volume, il faut regarder le stockage. Si le pod reste en attente sans evenement clair, il faut verifier le scheduler et l’etat des noeuds.

Running mais pas Ready

Running signifie que le pod est assigne a un noeud et qu’au moins un conteneur est en cours d’execution. Cela ne veut pas dire que l’application est utilisable. La colonne READY et les conditions sont plus precises pour savoir si le pod peut recevoir du trafic.

Exemple de verification:

kubectl get pod <pod>
kubectl get pod <pod> -o jsonpath='{.status.conditions}'

Avec des readiness probes, un conteneur peut tourner mais rester non pret si l’application ne repond pas correctement. Cette nuance est importante pour comprendre pourquoi un Service peut ne pas envoyer de trafic vers un pod pourtant Running.

Construire une checklist de debug

Pour eviter de partir dans tous les sens, on peut suivre une sequence stable:

• kubectl get pods -o wide pour voir status, noeud et IP;
• kubectl describe pod pour lire conditions et events;
• kubectl logs puis kubectl logs --previous si redemarrage;
• kubectl get pod -o yaml pour regarder status en detail;
• verifier les ressources liees: ConfigMap, Secret, volume, ServiceAccount.

Cette checklist ne resout pas tout, mais elle couvre une grande partie des problemes rencontres au debut.

Notions et definitions

• Pod: plus petite unite deployable dans Kubernetes.
• Controleur: objet qui maintient un etat attendu, comme Deployment, ReplicaSet, DaemonSet ou StatefulSet.
• Reconciliation: boucle permanente qui compare l’etat reel et l’etat desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un Deployment a trois replicas recree automatiquement un pod supprime afin de revenir a l’etat attendu declare dans sa specification.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Declarer le workload avec un manifest YAML ou une commande kubectl.
• Observer les pods crees et leurs labels.
• Lire les events pour comprendre scheduling, pulls d’images et redemarrages.
• Modifier le controleur plutot que les pods generes directement.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le passage d’un conteneur isole a un workload controle par Kubernetes. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pods -o wide --show-labels
• kubectl describe pod <pod> pour lire scheduling, events et conditions
• kubectl rollout history deployment/<name> quand un Deployment est concerne

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• modifier un pod gere par un controleur au lieu de modifier le controleur lui-meme
• ignorer les events alors qu’ils expliquent souvent le probleme
• oublier que les labels sont le lien entre controleurs, pods et Services

Exercice conseille

Lancez un Deployment nginx a trois replicas, supprimez un pod manuellement, puis observez comment le controleur reconcilie l’etat attendu.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 013 – ReplicaSet : c’est quoi et pourquoi ?.

Conclusion

Lire les status est un savoir-faire de base. Kubernetes donne beaucoup d’indices, mais il faut croiser status, conditions, logs et events pour trouver la vraie cause.