Comment déboguez-vous un Pod qui se comporte mal ?

Une échelle, pas une collection de commandes. L’intervieweur veut l’ordre. exec en premier est le réflexe qui dit que vous déboguez encore comme sur une VM.

1. Situer

kubectl get pod <nom> -o wide
kubectl get events --field-selector involvedObject.name=<nom> --sort-by=.lastTimestamp

Phase, READY, nœud, âge, redémarrages. Un 0/1 Running, un Pending, un CrashLoopBackOff n’ouvrent pas le même tiroir.

2. Demander au cluster ce qu’il a tenté

kubectl describe pod <nom>

Les Events en bas sont la source. FailedScheduling, FailedMount, Pulling, Unhealthy, Killing : c’est le récit du kubelet et du scheduler, pas celui de l’appli. Beaucoup de pannes se ferment ici, sans ouvrir un shell.

3. Demander au process ce qu’il a dit

kubectl logs <nom> -c <conteneur>
kubectl logs <nom> -c <conteneur> --previous

Plusieurs conteneurs : on nomme -c. --previous après un crash. Sans logs, on ne « restart » pas pour voir : on a déjà perdu une occurrence.

4. Confirmer, seulement si le Pod tourne

kubectl exec : le filesystem, une variable, un curl vers le voisin. kubectl port-forward : reproduire depuis votre machine. kubectl debug / un conteneur éphémère : quand l’image n’a pas de shell — de plus en plus fréquent, et c’est une bonne chose.

On n’installe pas tcpdump dans l’image de prod « au cas où ». On apporte l’outil le temps du debug.

Ce que l’intervieweur vérifie

Que vous reliez l’outil à la question. Readiness qui échoue : describe, pas les logs applicatifs d’abord. Mauvaise config : logs. Disque : Events de volume. Et que vous savez où regarder ensuite : nœud (describe node), Service (get endpoints), namespace (quota). Le Pod est le symptôme ; la cause est souvent à côté.

La relance probable

« Les logs sont vides et ça crash. »

--previous, puis le code de sortie dans describe. 137 : mémoire. 139 : segmentation. 1 : l’appli. Une command qui pointe vers un binaire absent sort immédiatement, parfois sans une ligne. Ensuite seulement, on compare le manifeste à ce que le controller a vraiment instancié — un mauvais overlay Kustomize se voit au kubectl get pod -o yaml, pas au fichier Git qu’on croit avoir appliqué.

Les deux commandes qui règlent la majorité des cas du petit projet démo sont les mêmes : déployer une application, pas à pas.