Kubernetes 009 – Premiers Pods : kubectl run, describe, delete

TL;DR

kubectl run permet de creer rapidement un pod pour apprendre. kubectl describe donne le detail de l’objet et ses evenements. kubectl delete supprime la ressource. Ces commandes sont parfaites pour debuter avant de passer aux manifests declaratifs.

La video de reference

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

Elle met en pratique les notions vues dans les episodes precedents.

Creer un premier pod

kubectl run nginx --image=nginx
kubectl get pods
kubectl get pods -o wide

La premiere commande demande a Kubernetes de creer un pod utilisant l’image nginx. Les commandes suivantes permettent de voir son etat et le noeud sur lequel il tourne.

Observer avec describe

kubectl describe pod nginx

describe affiche la specification, l’etat, les conteneurs, les conditions et les evenements. C’est souvent la premiere commande a utiliser quand un pod reste en Pending, ImagePullBackOff ou CrashLoopBackOff.

Supprimer proprement

kubectl delete pod nginx

La suppression montre aussi une limite importante: un pod cree directement n’est pas automatiquement recree par un controleur applicatif.

Liens utiles

• Video: https://www.youtube.com/watch?v=ElVwAByDkf4
• Pods: https://kubernetes.io/docs/concepts/workloads/pods/
• Kubectl run: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_run/
• Debug des applications: https://kubernetes.io/docs/tasks/debug/debug-application/

FAQ

kubectl run cree-t-il toujours un Deployment ?

Non. Dans les versions modernes, il cree typiquement un pod lorsqu’on l’utilise simplement avec une image.

Que regarder dans describe ?

Les events en bas de sortie sont souvent les plus utiles pour comprendre un probleme.

Pourquoi supprimer le pod apres le test ?

Pour garder un environnement propre et eviter de confondre les essais avec les ressources suivies.

Lire la sortie de get pods

La commande kubectl get pods affiche plusieurs colonnes qui doivent devenir naturelles. READY indique combien de conteneurs du pod sont prets. STATUS donne l’etat global. RESTARTS indique combien de redemarrages ont eu lieu. AGE donne l’anciennete.

Avec -o wide, on obtient aussi le noeud et l’IP du pod:

kubectl get pods -o wide

Cette sortie est souvent le premier indice pour savoir si le probleme est applicatif, reseau, scheduling ou image.

describe comme reflexe de debug

kubectl describe pod est plus bavard que get. Il affiche les containers, les images, les ports, les volumes, les conditions et surtout les events. Pour un debutant, les events sont tres utiles car Kubernetes y raconte ce qu’il a essaye de faire.

Exemples d’informations visibles:

• image tiree avec succes ou en erreur;
• noeud choisi par le scheduler;
• redemarrages du conteneur;
• probleme de montage de volume;
• erreur de policy ou de quota.

Nettoyer ses essais

Dans un lab, on cree beaucoup de ressources. Prendre l’habitude de nettoyer evite les confusions:

kubectl get pods
kubectl delete pod nginx
kubectl get pods

Si un pod revient apres suppression, c’est qu’il est probablement gere par un controleur. Ce sera une bonne transition vers ReplicaSet et Deployment.

Erreurs frequentes

• Oublier le namespace courant.
• Lire uniquement le status sans regarder les events.
• Croire qu’un pod supprime doit toujours revenir.
• Garder des pods de test qui brouillent les exercices suivants.

Pour pratiquer

Essayez trois variantes:

kubectl run nginx --image=nginx
kubectl run shell --image=busybox --command -- sleep 3600
kubectl run erreur --image=nginx:tag-inexistant

Comparez ensuite get, describe et logs pour chaque cas.

Ajouter des options a kubectl run

kubectl run peut aussi servir a generer rapidement des variantes pour apprendre:

kubectl run web --image=nginx --port=80
kubectl run shell --image=busybox --command -- sleep 3600
kubectl run test --image=curlimages/curl --command -- sleep 3600

Ces commandes restent pratiques en lab, mais elles ne remplacent pas les manifests pour un projet suivi. Elles permettent surtout de creer vite un objet, de l’observer, puis de comprendre ce qu’il faudrait ecrire proprement en YAML.

Recuperer le YAML genere

Une bonne transition vers le declaratif consiste a demander a kubectl de produire le YAML sans creer l’objet:

kubectl run web --image=nginx --port=80 --dry-run=client -o yaml
kubectl run web --image=nginx --port=80 --dry-run=client -o yaml > pod.yaml

Le fichier obtenu n’est pas toujours parfait, mais il donne une base. On peut ensuite ajouter des labels, verifier le nom du conteneur, ajuster les ports et versionner le manifest.

Savoir quand passer a autre chose

Les pods lances directement sont excellents pour apprendre, tester une image ou reproduire rapidement un probleme. Pour une application qui doit rester disponible, il faudra passer a un controleur. C’est une limite volontaire: Kubernetes ne suppose pas qu’un pod isole doit vivre eternellement.

Cette limite est pedagogique. Elle force a comprendre pourquoi les ReplicaSets et Deployments existent: maintenir un nombre d’instances, recreer les pods perdus et organiser les mises a jour.

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 010 – Pods : manifests et outputs.

Conclusion

Ces trois commandes forment le premier cycle pratique: creer, observer, supprimer. Elles donnent les reflexes indispensables avant de passer a des manifests plus reproductibles.