Kubernetes 019 – Debug : kubectl exec et run

TL;DR

kubectl exec lance une commande dans un conteneur existant. kubectl run permet de creer un pod temporaire pour tester le DNS, le reseau, un Service ou une image. Ces commandes sont tres utiles, mais doivent rester controlees.

La video de reference

Video: https://www.youtube.com/watch?v=naLtWR6uEWY

Elle montre comment investiguer sans modifier durablement l’application.

kubectl exec

kubectl exec -it <pod> -- sh
kubectl exec <pod> -- env
kubectl exec <pod> -- cat /etc/resolv.conf

Avec plusieurs conteneurs dans un pod, on precise le conteneur:

kubectl exec -it <pod> -c <container> -- sh

kubectl run pour debug

kubectl run debug --image=busybox:1.36 -it --rm --restart=Never -- sh
kubectl run curl --image=curlimages/curl -it --rm --restart=Never -- curl http://web

--rm supprime le pod a la fin. --restart=Never cree un pod simple plutot qu’un workload controle.

Tester un Service

kubectl run curl --image=curlimages/curl -it --rm --restart=Never -- curl -v http://web:80
kubectl get svc web
kubectl get endpoints web

Si le DNS resout mais que la connexion echoue, il faut regarder les endpoints, ports et NetworkPolicies eventuelles.

Lire avant d’entrer

Avant d’ouvrir un shell, il est souvent plus propre de lire les informations disponibles:

kubectl logs <pod>
kubectl describe pod <pod>
kubectl get pod <pod> -o wide
kubectl get events --sort-by=.lastTimestamp

Limites de exec

Beaucoup d’images modernes sont minimales et ne contiennent ni shell, ni curl, ni ping. Ce n’est pas un bug. C’est souvent une bonne pratique de securite.

Liens utiles

• Video: https://www.youtube.com/watch?v=naLtWR6uEWY
• Debugging applications: https://kubernetes.io/docs/tasks/debug/debug-application/
• kubectl exec: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_exec/
• kubectl run: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_run/

FAQ

exec modifie-t-il le conteneur ?

La commande peut modifier le conteneur si elle ecrit des fichiers ou change l’etat. Il faut rester prudent.

Pourquoi sh n’existe pas dans mon image ?

Parce que certaines images sont distroless ou tres minimales.

Faut-il installer curl dans l’image applicative ?

Pas forcement. Un pod temporaire de debug est souvent preferable.

Erreurs frequentes

• Faire du debug manuel puis oublier de corriger le manifest.
• Lancer un pod temporaire sans --rm et polluer le namespace.
• Tester depuis son poste alors que le probleme est interne au cluster.
• Confondre probleme DNS, Service et application.

Pour pratiquer

kubectl create deployment web --image=nginx
kubectl expose deployment web --port=80
kubectl run curl --image=curlimages/curl -it --rm --restart=Never -- curl http://web
kubectl exec deploy/web -- nginx -v

Notions et definitions

• Pod: plus petite unite deployable dans Kubernetes.
• Controleur: objet qui maintient un etat attendu, comme Deployment, ReplicaSet, DaemonSet ou StatefulSet.
• Reconciliation: boucle permanente qui compare l’etat reel et l’etat desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un Deployment a trois replicas recree automatiquement un pod supprime afin de revenir a l’etat attendu declare dans sa specification.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Declarer le workload avec un manifest YAML ou une commande kubectl.
• Observer les pods crees et leurs labels.
• Lire les events pour comprendre scheduling, pulls d’images et redemarrages.
• Modifier le controleur plutot que les pods generes directement.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le passage d’un conteneur isole a un workload controle par Kubernetes. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pods -o wide --show-labels
• kubectl describe pod <pod> pour lire scheduling, events et conditions
• kubectl rollout history deployment/<name> quand un Deployment est concerne

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• modifier un pod gere par un controleur au lieu de modifier le controleur lui-meme
• ignorer les events alors qu’ils expliquent souvent le probleme
• oublier que les labels sont le lien entre controleurs, pods et Services

Exercice conseille

Lancez un Deployment nginx a trois replicas, supprimez un pod manuellement, puis observez comment le controleur reconcilie l’etat attendu.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 020 – Services : ClusterIP, principes, schema et demo.

Conclusion

exec et run sont des outils simples mais puissants. Bien utilises, ils permettent de diagnostiquer vite sans transformer le cluster en environnement de bricolage.