Leçon 7 : mises à jour progressives et retour en arrière (rollback)
On a déjà un Deployment qui maintient plusieurs copies (Pods) de l'appli. Mais que se passe-t-il quand on veut livrer une nouvelle version — par exemple remplacer l'image nginx:1.27 par nginx:1.28 ? La méthode naïve serait de tout démolir et tout reconstruire, mais alors le service tombe pendant que
C'est comme changer les roues d'une voiture sans l'arrêter — tu remplaces une roue à la fois, donc la voiture continue de rouler. Et si la nouvelle roue est voilée, tu remets simplement l'ancienne.
- Rolling Update
- Une façon de mettre à jour un Deployment sans temps d'arrêt : Kubernetes remplace progressivement les anciens Pods par des nouveaux, quelques-uns à la fois, de sorte qu'il reste toujours assez de copies actives pour répondre aux requêtes.
- Rollback
- Ramener le Deployment à la révision précédente qui fonctionnait, quand la nouvelle version s'avère défaillante. La commande kubectl rollout undo fait cela en une étape.
- Statut du rollout
- Suivi en direct de la progression d'une mise à jour : combien de Pods sont déjà mis à jour sur le total, jusqu'à ce qu'un message confirme que la mise à jour est terminée avec succès.
- maxUnavailable
- Combien de Pods peuvent être indisponibles simultanément pendant une mise à jour progressive. Une valeur basse garde plus de copies actives à chaque instant, mais ralentit la mise à jour.
- maxSurge
- Combien de Pods supplémentaires au-delà de l'objectif peuvent être créés temporairement pendant une mise à jour, pour que de nouvelles copies soient prêtes avant que les anciennes ne soient retirées.
- Revision
- Une version sauvegardée du Deployment. Chaque mise à jour crée une nouvelle révision, et Kubernetes se souvient des précédentes pour qu'on puisse y revenir.
