Leçon 14 : Diagnostic des pannes — la leçon de synthèse
Tu es arrivé·e à la dernière leçon, et on y relie tout en un seul outil que tu utiliseras encore et encore : un flux de diagnostic ordonné — un runbook. Quand quelque chose ne fonctionne pas dans le cluster, il est facile de paniquer et de deviner. À la place, on travaille comme des détectives : d'a
Le diagnostic de pannes, c'est comme être détective : on n'accuse personne avant d'avoir rassemblé des preuves. On regarde d'abord qui est suspect (get), on lit les témoignages (describe et logs), et c'est seulement ensuite qu'on détermine qui est coupable et qu'on corrige.
- Diagnostic des pannes
- Un processus ordonné pour trouver la cause d'une panne : rassembler des preuves (get, describe, logs), formuler une hypothèse, corriger, et vérifier que le problème a disparu — au lieu de deviner.
- Runbook
- Une liste fixe et reproductible d'étapes à suivre quand une panne survient. Elle permet à toute l'équipe de diagnostiquer dans le même ordre et de ne pas sauter une étape critique sous pression.
- CrashLoopBackOff
- Un état de Pod où le conteneur démarre, plante, et Kubernetes réessaie sans arrêt avec un délai croissant entre les tentatives. La cause est presque toujours dans le code ou la configuration de l'application — on la lit avec logs --previous.
- ImagePullBackOff
- Un état où Kubernetes n'a pas réussi à télécharger (pull) l'image du conteneur : un nom ou un tag erroné, l'image absente du registry, ou des permissions manquantes. On voit la cause dans les Events de describe.
- Pending
- Un état où le Pod a été accepté mais n'a pas encore été planifié pour tourner sur aucun node — le plus souvent parce qu'il n'y a pas assez de ressources (CPU/mémoire) libres, ou qu'aucun node ne correspond à ses exigences.
- Events
- Un journal court de ce que Kubernetes a essayé de faire au Pod (planifié, téléchargé l'image, démarré, échoué). Il apparaît en bas de la sortie de kubectl describe pod et c'est en général le premier indice de la cause de la panne.
