Module 3c · Observabilité

Objectifs

• Distinguer les 3 piliers : métriques, logs, événements (et un mot des traces).
• Lire la consommation CPU/mémoire des pods et nœuds (metrics-server + k9s).
• Exploiter logs et events pour diagnostiquer — le réflexe debug.
• Durée : ~2 h · Pré-requis : Module 3b.

1. Observer quoi ?

Pilier	Question	Outil de base
Métriques	« combien ? » (CPU, mémoire, nb de pods)	metrics-server, kubectl top, :pulses
Logs	« qu'a dit l'application ? »	kubectl logs, k9s l
Événements	« qu'a fait Kubernetes ? »	kubectl get events, describe
Traces	« par où est passée la requête ? »	(hors socle : Jaeger/Tempo)

2. Métriques — metrics-server

metrics-server collecte CPU/mémoire et alimente kubectl top + l'autoscaling.

bash kubectl top nodes kubectl top pods -A

Si top renvoie une erreur

metrics-server n'est peut-être pas installé sur le cluster. Sur la sandbox il l'est en général ; sinon : kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml (en lab, on ajoute parfois --kubelet-insecure-tls).

Dans k9s : la vue :pods affiche des colonnes CPU/MEM en temps réel, et :pulses donne un tableau de bord global (santé du cluster en un coup d'œil).

3. Logs

text l ← logs du pod (k9s) f ← plein écran 0/1/2… ← fenêtre temporelle (depuis le début / dernières minutes) /erreur ← filtre les lignes contenant "erreur"

bash kubectl logs <pod> -f # suivi kubectl logs <pod> -c <conteneur> # pod multi-conteneurs kubectl logs <pod> --previous # logs du conteneur AVANT son dernier crash (essentiel !)

--previous sauve la vie

Un pod en CrashLoopBackOff a déjà redémarré : ses logs actuels sont vides ou inutiles. --previous montre ce qui s'est passé juste avant le crash.

4. Événements — la mémoire du cluster

Les events racontent les décisions de Kubernetes (scheduling, pull d'image, probes…).

bash kubectl get events --sort-by=.lastTimestamp kubectl describe pod <pod> # events en bas (k9s : touche d)

C'est le premier endroit où regarder quand un pod ne démarre pas : FailedScheduling, ImagePullBackOff, Unhealthy (probe qui échoue)… tout est là.

5. Probes : rendre l'état observable

Une app peut tourner sans être prête. Les probes informent Kubernetes :

yaml livenessProbe: # redémarre le conteneur s'il est bloqué httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 5 periodSeconds: 10 readinessProbe: # retire le pod du Service tant qu'il n'est pas prêt httpGet: { path: /ready, port: 8080 }

Une readinessProbe qui échoue = pod exclu du load balancing, sans crash : invisible sans observabilité. D'où l'importance d'describe + events.

6. Exercices

Exercice 3c.1 — Qui consomme ?

1. kubectl top pods -A : repère le pod le plus gourmand en mémoire.
2. Dans k9s, retrouve-le et lis son describe : a-t-il des limits ?
3. Discute : que se passerait-il s'il dépassait sa limite mémoire ? (OOMKill)

Exercice 3c.2 — Debug par les events

1. kubectl run cassé --image=nginx:tag-bidon
2. Sans lire les logs, trouve la cause via describe / events.
3. Puis crée un pod avec une readinessProbe qui échoue : il tourne mais n'est jamais READY. Constate dans k9s.

7. Ce qu'il faut retenir

• 3 piliers : métriques (combien), logs (ce que dit l'app), events (ce que fait k8s).
• Pod qui crashe → kubectl logs --previous + describe/events avant tout.
• kubectl top / :pulses pour la consommation ; metrics-server doit être présent.
• Les probes rendent l'état réel d'une app observable (et pilotent liveness/readiness).

➡️ Suite : Module 3d — Sécurité