Kubernetes (2/12) — Du Pod nu au Deployment

L’idée reçue

« J’ai un Pod qui tourne, mon appli est déployée. »

Un Pod créé à la main est unique et fragile : s’il disparaît, rien ne le ramène. En production, on ne déploie jamais de « Pod nu ». On va le prouver en le cassant, puis découvrir l’objet qui change tout : le Deployment.

À la fin de ce module, tu sauras…

Expliquer pourquoi un Pod nu n’est pas prêt pour la production
Distinguer impératif et déclaratif
Créer un Deployment et comprendre la chaîne Deployment → ReplicaSet → Pods
Observer le self-healing en direct

01Prouver la fragilité

Expérience 1

Supprime le Pod, et regarde : rien ne revient

Manipule

kubectl delete pod demo-pod
kubectl get pods

Observe

pod "demo-pod" deleted
No resources found in lab-soria namespace.

Le Pod a disparu, et rien ne le recrée. Aucun mécanisme ne veille sur lui. C’est exactement le problème du Pod nu : pas d’auto-réparation.

Comprends pourquoi un Pod nu est fragile

Un Pod lancé avec kubectl run est créé une fois. S’il plante, si son nœud tombe, ou si on le supprime, aucun contrôleur ne garantit son retour. Pour 3 instances, il faudrait les créer à la main. Pour une nouvelle version, tout refaire manuellement. Ingérable en production.

02Impératif vs déclaratif

La commande kubectl run demo-pod … était impérative : « crée ce Pod maintenant » — et Kubernetes l’a fait une fois, sans mémoriser que tu le veux en permanence.

Comprends le changement de paradigme

Avec un Deployment, tu dis : « je veux toujours 2 Pods avec cette image ». C’est déclaratif : tu décris l’état voulu, et Kubernetes l’applique en continu. C’est le cœur de sa philosophie — la même idée que tu as entrevue avec Docker Compose (Phase 3), mais ici appliquée en permanence par un contrôleur.

03Créer un Deployment (2 replicas)

Expérience 2

Déclarer l’état voulu

Manipule

kubectl create deployment demo-deploy --image=nginx:stable --replicas=2
kubectl get deployments
kubectl get pods

Observe

NAME          READY   UP-TO-DATE   AVAILABLE   AGE
demo-deploy   2/2     2            2           15s

NAME                           READY   STATUS    RESTARTS   AGE
demo-deploy-7c9f8b6d4-abcde    1/1     Running   0          15s
demo-deploy-7c9f8b6d4-fghij    1/1     Running   0          15s

Un Deployment, et deux Pods nommés demo-deploy-xxxxx. Ces Pods sont désormais gérés : le self-healing commence.

Comprends la chaîne Deployment → ReplicaSet → Pods

Un Deployment décrit l’image, le nombre de replicas, les labels, la stratégie de mise à jour. Mais sa vraie puissance : il crée et gère un ReplicaSet, qui garantit que le nombre exact de Pods existe. La chaîne réelle est Deployment → ReplicaSet → Pods. C’est l’architecture de production.

04Le self-healing, en direct

Expérience 3

Supprime un Pod géré — et regarde-le renaître

Note le nom d’un des deux Pods, supprime-le, puis liste immédiatement :

Manipule

kubectl delete pod demo-deploy-7c9f8b6d4-abcde
kubectl get pods

Observe

NAME                           READY   STATUS              AGE
demo-deploy-7c9f8b6d4-fghij    1/1     Running             3m
demo-deploy-7c9f8b6d4-klmno    0/1     ContainerCreating   2s

À peine supprimé, un nouveau Pod apparaît pour maintenir le compte à 2. Tu n’as rien fait : Kubernetes a réconcilié tout seul.

Comprends la réconciliation automatique

Quand un Pod géré meurt, le ReplicaSet détecte qu’il y a moins de Pods que voulu, et en recrée un immédiatement. C’est la réconciliation automatique : l’état réel est ramené vers l’état voulu, sans intervention. C’est le cœur battant de Kubernetes.

→Docker vs Kubernetes, en un modèle mental

	Pod nu	Deployment
Si supprimé	disparaît définitivement	recréé automatiquement
Mise à l’échelle	manuelle, Pod par Pod	un seul champ : replicas
Mise à jour	tout refaire à la main	rolling update
Retour arrière	impossible proprement	rollback

✓Ce que tu retiens

Un Pod nu est fragile et jetable ; on ne l’utilise pas en production. Le Deployment déclare un état voulu (N replicas d’une image) et le maintient via un ReplicaSet, avec self-healing automatique. Déclaratif, pas impératif : tu décris le but, Kubernetes s’en charge en continu.

Mini-projet

Deployment & auto-réparation

À faire

Supprime le Pod nu restant, prouve que rien ne le recrée.
Crée demo-deploy avec 2 replicas.
Supprime un des Pods gérés et capture la renaissance immédiate.
Explique en 3 lignes la chaîne Deployment → ReplicaSet → Pods.
Documente le self-healing dans BookStack.

Fil rouge — Tes Pods sont recréés automatiquement… mais où tournent-ils exactement ? Sur le master ? Le worker ? Au module suivant, on regarde les nodes et comment Kubernetes décide où placer chaque Pod.

?Auto-évaluation

1. Pourquoi ne déploie-t-on jamais de Pod nu en production ?

Parce qu’il n’a pas d’auto-réparation : s’il disparaît, rien ne le recrée. Pas de scaling, ni de rolling update, ni de rollback.

2. Quelle est la chaîne d’objets derrière un Deployment ?

Deployment → ReplicaSet → Pods. Le ReplicaSet garantit le nombre exact de Pods.

3. Qu’est-ce que la réconciliation automatique ?

Kubernetes compare en continu l’état réel à l’état voulu et corrige les écarts — par exemple en recréant un Pod supprimé.