La méthode : du symptôme à la cause

Le dépannage compte pour 30 % de l'examen CKA, et pour bien plus que ça dans la vraie vie. Face à une panne, le débutant tape des commandes au hasard ; l'expérimenté suit une méthode. Elle tient en une idée : partir du symptôme observé par l'utilisateur, et descendre couche par couche jusqu'à la cause, en vérifiant chaque hypothèse au lieu de la deviner.

Ce que vous saurez à la fin : appliquer une démarche de diagnostic en couches, lire l'état d'un pod comme un indice, choisir le bon outil pour chaque question, et éviter les pièges classiques (corriger le symptôme, changer trois choses à la fois, oublier de vérifier).

1. Les cinq temps d'un diagnostic

1. Décrire le symptôme précisément. « Le site ne marche pas » ne suffit pas. Préférez « https://boutique.example.com/panier répond 502 depuis 14 h, pour tous les utilisateurs ». Qui est touché ? Depuis quand ? Tout, ou une partie ?
2. Chercher ce qui a changé. Neuf pannes sur dix suivent un changement : un déploiement, une configuration, un certificat qui expire, un quota, une mise à jour de nœud. kubectl rollout history, les événements, le journal des livraisons.
3. Descendre les couches, de l'utilisateur vers l'infrastructure (voir plus bas), en vérifiant chaque étage avant de passer au suivant.
4. Corriger une seule chose à la fois, et noter ce que vous faites. Si vous changez trois paramètres et que ça remarche, vous ne savez pas lequel était en cause.
5. Vérifier la correction du point de vue de l'utilisateur, puis rédiger un court compte rendu : symptôme, cause, correction, comment éviter que ça recommence (le postmortem).

2. Les couches, de l'utilisateur au nœud

Utilisateur
  └─ DNS public, certificat, Ingress / LoadBalancer       → 404, 502, erreurs TLS
      └─ Service (sélecteur, ports, endpoints)              → connexion refusée, délai dépassé
          └─ Pods (état, sondes, redémarrages)              → CrashLoopBackOff, pas prêt
              └─ Conteneur (journaux, configuration)       → l'application dit pourquoi
                  └─ Nœud et cluster (ressources, réseau, stockage, plan de contrôle)

Sautez directement à la bonne couche quand l'indice est clair. Un CrashLoopBackOff vous emmène tout de suite aux journaux du conteneur.

3. L'état d'un pod est un indice

État affiché	Ce que ça veut dire	Première commande
Pending	aucun nœud ne peut l'accueillir (ressources, sélecteur, taints, volume)	kubectl describe pod → FailedScheduling
ContainerCreating (qui dure)	volume ou réseau impossible à préparer	kubectl describe pod → FailedMount, FailedCreatePodSandBox
ImagePullBackOff, ErrImagePull	image introuvable, tag faux, registre privé sans accès	kubectl describe pod → message du pull
CreateContainerConfigError	ConfigMap, Secret ou clé référencés absents	kubectl describe pod
CrashLoopBackOff	le processus démarre puis s'arrête	kubectl logs --previous
OOMKilled (dernier état)	dépassement de la limite mémoire	kubectl describe pod → Last State
Running, mais 0/1 prêt	la sonde de disponibilité échoue	kubectl describe pod → Unhealthy
Terminating (qui dure)	un finalizer ou un nœud injoignable retient le pod	kubectl get pod -o yaml → finalizers

Et quand un Deployment affiche 0/3 sans aucun pod ? Le problème est en amont des pods : regardez les événements du ReplicaSet (kubectl describe rs). Un quota dépassé ou un refus d'admission y apparaissent.

4. La boîte à outils, question par question

Question	Outil
Qu'est-ce qui ne va pas, globalement ?	kubectl get pods,deploy,svc · kubectl get events --sort-by=.lastTimestamp
Pourquoi cet objet est-il dans cet état ?	kubectl describe <type> <nom> (les événements en bas)
Que dit l'application ?	kubectl logs · --previous · -c <conteneur>
Que voit l'application de l'intérieur ?	kubectl exec · kubectl debug
Qu'est-ce qui a changé ?	kubectl rollout history · kubectl diff -f · l'historique Git
Le Service trouve-t-il ses pods ?	kubectl get endpointslices -l kubernetes.io/service-name=<svc>
Le réseau passe-t-il ?	un pod de test : kubectl run test --rm -it --image=busybox -- wget -qO- http://<svc>
Qui consomme trop ?	kubectl top pods · kubectl describe resourcequota
Ai-je le droit ?	kubectl auth can-i

5. Les pièges

• Corriger le symptôme, pas la cause. Redémarrer le pod fait disparaître l'erreur… jusqu'à la prochaine fois. Le redémarrage est un pansement, pas un diagnostic.
• Supposer au lieu de vérifier. « Le Service est bon, je l'ai écrit hier. » Vérifiez les endpoints : ça prend cinq secondes.
• Lire le mauvais journal. Après un redémarrage, les journaux utiles sont ceux du conteneur précédent (--previous).
• Tout changer d'un coup, puis ne plus savoir ce qui a réparé.
• Oublier les événements, qui disparaissent au bout d'environ une heure : regardez-les tôt, notez-les.
• Ignorer les messages d'erreur. Ils sont souvent très précis. Lisez-les en entier, jusqu'au bout de la ligne.

6. Un exemple déroulé

« Depuis la livraison de 15 h, la page panier renvoie une erreur 503. »

1. kubectl get deploy panier → 2/3 prêts. Un pod ne l'est pas.
2. kubectl get pods -l app=panier → le pod le plus récent est Running, 0/1.
3. kubectl describe pod <pod> → Readiness probe failed: HTTP probe failed with statuscode: 404.
4. kubectl rollout history deploy/panier puis kubectl diff → la nouvelle version a renommé /health en /sante, mais la sonde vise toujours /health.
5. Correction : soit on aligne la sonde, soit on revient en arrière (kubectl rollout undo) le temps de corriger. On vérifie que les 3 pods sont prêts et que la page répond.
6. Compte rendu : « sonde non mise à jour avec le chemin de santé ; ajouter la sonde aux tests de livraison ».

Les trois leçons suivantes vous mettent face à de vraies pannes à résoudre. Celle-ci se valide par le QCM de passage.