Kubernetes (4/12) — Rolling updates & rollback

L’idée reçue

« Mettre à jour une appli = tout arrêter, remplacer, redémarrer. »

Ça, c’est la coupure de service. Kubernetes fait un remplacement contrôlé : il crée les nouveaux Pods, attend qu’ils soient prêts, puis retire les anciens — progressivement, sans interruption. Et si la nouvelle version casse, on revient en arrière en une commande.

À la fin de ce module, tu sauras…

Déclencher une mise à jour progressive (rolling update)
L’observer en direct (Pods et ReplicaSets qui basculent)
Prouver quelle version tourne réellement
Revenir à la version précédente (rollback)

01L’état de départ

Expérience 1

La photo avant modification

Manipule

kubectl get deployment demo-deploy
kubectl get pods

Tous les Pods sont Running sur nginx:stable. C’est la référence avant la mise à jour. Pour voir la stratégie employée :

Manipule

kubectl describe deployment demo-deploy

Comprends la stratégie RollingUpdate

Par défaut, un Deployment utilise la stratégie RollingUpdate : il remplace les Pods petit à petit, en gardant l’appli disponible pendant toute l’opération. C’est ce comportement qu’on va observer.

02Déclencher la mise à jour

Expérience 2

Changer la version de l’image

Manipule

kubectl set image deployment/demo-deploy nginx=nginx:1.28

Observe

deployment.apps/demo-deploy image updated

Tu viens de modifier l’état voulu : « je veux désormais l’image 1.28 ». Kubernetes déclenche automatiquement un rolling update.

Comprends pourquoi set image suffit

set image change la spec du Deployment. Comme Kubernetes réconcilie en continu l’état réel vers l’état voulu, ce simple changement déclenche la mise à jour progressive — tu n’as pas à orchestrer quoi que ce soit à la main.

03Regarder le remplacement en direct

Expérience 3

Les Pods et ReplicaSets qui basculent

Manipule

kubectl rollout status deployment/demo-deploy
kubectl get pods
kubectl get rs

Observe

Waiting for deployment "demo-deploy" rollout to finish...
deployment "demo-deploy" successfully rolled out

NAME                     DESIRED   CURRENT   READY
demo-deploy-7c9f8b6d4    0         0         0     # ancien ReplicaSet
demo-deploy-59d8c7f2a    2         2         2     # nouveau ReplicaSet

Pendant l’opération, de nouveaux Pods apparaissent (nouveau hash) et les anciens sont retirés progressivement. Un nouveau ReplicaSet prend le relais, l’ancien tombe à 0.

Comprends le rôle des ReplicaSets ici

Chaque version d’image correspond à un ReplicaSet distinct. Le rolling update fait monter le nouveau (0 → 2) tout en faisant descendre l’ancien (2 → 0), en s’assurant qu’il reste toujours assez de Pods prêts. L’ancien ReplicaSet n’est pas supprimé : il reste à 0, prêt pour un éventuel rollback.

04Prouver quelle version tourne

Expérience 4

Ne jamais se fier au hasard des tags

Manipule

kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"  "}{.spec.containers[*].image}{"\n"}{end}'

Observe

demo-deploy-59d8c7f2a-aaaaa  nginx:1.28
demo-deploy-59d8c7f2a-bbbbb  nginx:1.28

Preuve directe : tous les Pods tournent sur nginx:1.28. On vérifie par les faits, pas par la mémoire.

Comprends cette commande jsonpath

Elle parcourt tous les Pods (range .items[*]) et imprime, pour chacun, son nom et l’image de ses conteneurs. Une seule ligne pour vérifier la version réelle partout — très utile quand les tags prêtent à confusion.

05Le rollback

Expérience 5

Revenir à la version précédente en une commande

Manipule

kubectl rollout undo deployment/demo-deploy
kubectl rollout status deployment/demo-deploy

Observe

Kubernetes rejoue un rolling update en sens inverse : l’ancien ReplicaSet redevient actif, le nouveau retombe à 0. En cas de problème avec une version, c’est ta sortie de secours immédiate.

Comprends undo, et les révisions

rollout undo revient à la révision précédente. Pour choisir une révision précise : kubectl rollout history deployment/demo-deploy liste les révisions, puis kubectl rollout undo deployment/demo-deploy –to-revision=N saute à l’une d’elles. Il n’existe pas de « redo » automatique : pour ré-avancer, on refait un set image.

✓Ce que tu retiens

Un rolling update remplace les Pods progressivement, sans coupure : nouveau ReplicaSet qui monte, ancien qui descend. On le déclenche avec set image, on l’observe avec rollout status et get rs, on prouve la version avec jsonpath. Et rollout undo ramène la version précédente en une commande. Mettre à jour n’est plus risqué.

Mini-projet

Mise à jour maîtrisée

À faire

Note la version de départ, puis passe à nginx:1.28.
Observe le rollout (rollout status, get rs).
Prouve la version avec la commande jsonpath.
Fais un rollout undo et prouve le retour à la version précédente.
Consulte rollout history et note les numéros de révision.
Documente dans BookStack : rolling update, ReplicaSets, rollback.

Fil rouge — Tu maintiens, tu répartis, tu mets à jour sans coupure. Mais tes Pods ont des IP qui changent à chaque recréation — comment les joindre de façon stable ? Au module suivant : le Service.

?Auto-évaluation

1. Comment Kubernetes évite-t-il la coupure pendant une mise à jour ?

Par un remplacement progressif : il crée les nouveaux Pods et attend qu’ils soient prêts avant de retirer les anciens.

2. Que deviennent les anciens ReplicaSets après un rolling update ?

Ils restent à 0 replica (non supprimés), ce qui permet un rollback vers une version précédente.

3. Comment revenir à la version précédente ?

Avec kubectl rollout undo deployment/<nom>, ou –to-revision=N pour une révision précise.