Aller au contenu

Module 4t · Diagnostiquer : la méthode

Objectifs

  • Une checklist universelle pour ne jamais diagnostiquer au hasard.
  • Suivre le chemin d'une requête à l'envers : du pod vers l'extérieur.
  • Les bons outils au bon endroit (describe, logs, endpoints, top).
  • Durée : ~30 min · Pré-requis : Module 4r - Réseau.

Pourquoi une méthode

Au module 3, tu as installé la boucle get → describe → fix. Ici on la systématise en une checklist qui suit le chemin d'une requête (module 4r) à l'envers : on part du plus proche du pod et on remonte vers l'extérieur. Pas de méthode = on tourne en rond ; la méthode garantit qu'on n'oublie aucune couche.

graph RL
    P[Pod Running ?] --> S[Service → endpoints ?]
    S --> I[Ingress host/path/TLS ?]

La checklist universelle

À dérouler toujours dans cet ordre

  1. Pod : Running ? Sinon → describe → Events (la cause y est presque toujours).
  2. Logs : erreur applicative ? (kubectl logs --previous si le conteneur a crashé).
  3. Service : kubectl get endpoints - pointe-t-il sur des pods ? (selector ↔ labels).
  4. Réseau : kubectl port-forward directement sur le pod - ça marche ? (isole le Service du pod).
  5. Ingress : host/path corrects ? Certificat TLS émis ?
  6. Ressources : kubectl top, OOMKilled, quotas atteints ?

Chaque étape isole une couche : si le port-forward sur le pod fonctionne mais pas via le Service, le problème est dans le Service (endpoints), pas dans l'app.

Les réflexes par symptôme

Symptôme Première commande Cause fréquente
Pod Pending describe pod → Events pas de place (requests), PVC non lié, taint
ImagePullBackOff describe pod → Events image introuvable / pull secret manquant
CrashLoopBackOff logs --previous l'app plante au démarrage (config, port)
Requête sans réponse get endpoints Service qui ne pointe sur aucun pod
OOMKilled describe + top limite mémoire trop basse

Pratique

Pas de TP auto-corrigé dédié : on rejoue une panne du module 3 avec la méthode, une fois la checklist en tête.

Exercice 4t.1 - Diagnostic guidé

Reprends une panne du module 3 (tp start 02-debug-service) et annonce à voix haute chaque étape de la checklist avant de taper la commande. L'objectif n'est pas de corriger vite, mais de ne sauter aucune couche.

Ce qu'il faut retenir

  • Le diagnostic suit toujours le chemin Pod → Service → Ingress, du plus proche du pod vers l'extérieur.
  • describe → Events d'abord : la cause d'un pod qui ne démarre pas y est presque toujours.
  • get endpoints tranche entre « problème d'app » et « problème de Service ».
  • --previous pour lire les logs d'un conteneur qui a déjà crashé.

Quiz éclair

Teste-toi : réponds de tête, puis déplie.

1. Une requête n'arrive pas jusqu'au pod. Dans quel ordre diagnostiques-tu ?

Pod (Running ?) → Service (kubectl get endpoints pointe sur des pods ?) → Ingress (host/path, TLS). Toujours du plus proche du pod vers l'extérieur.

2. Comment isoler un problème de Service d'un problème d'application ?

kubectl port-forward directement sur le pod. Si l'app répond ainsi mais pas via le Service, le défaut est dans le Service (endpoints vides, selector faux), pas dans l'app.

3. Un conteneur redémarre en boucle. Comment lire ce qui l'a fait planter ?

kubectl logs <pod> --previous : les logs de l'instance précédente (celle qui a crashé), sinon on ne voit que le conteneur fraîchement relancé.

➡️ Suite : Module 4b - Stockage persistant