Rolling deployment (déploiement progressif)

Un rolling deployment (déploiement progressif) remplace les instances d’une application par vagues : les nouvelles versions démarrent pendant que les anciennes continuent de servir, et le trafic bascule au fur et à mesure. À aucun moment le service n’est entièrement arrêté — par opposition au déploiement « big bang » où l’on coupe, on remplace, on redémarre.

La mécanique sur Kubernetes

C’est la stratégie par défaut d’un Deployment Kubernetes. Deux paramètres la pilotent : maxSurge (combien de pods supplémentaires peuvent exister pendant la transition) et maxUnavailable (combien de pods peuvent manquer). Avec les valeurs par défaut (25 % chacun), un déploiement de quatre replicas avance pod par pod : un nouveau démarre, il est déclaré prêt, un ancien s’arrête, et ainsi de suite. Si la nouvelle version ne devient jamais prête, le déploiement se fige au lieu de propager la panne — les anciens pods restent en place.

Le zéro interruption ne vient pas gratuitement

L’orchestrateur ne fait que la moitié du travail. Pour qu’aucune requête ne soit perdue, l’application doit coopérer sur plusieurs points documentés mais souvent négligés. La readiness probe doit refléter la capacité réelle à servir, pas seulement « le process a démarré » : c’est elle qui décide quand le trafic arrive. À l’arrêt, le pod reçoit un SIGTERM et dispose d’un délai de grâce (30 secondes par défaut) pour finir les requêtes en cours ; une application qui ignore SIGTERM est tuée en plein traitement. Enfin, le retrait du pod de la liste des endpoints et l’arrêt du process sont deux opérations asynchrones : sans une courte attente avant l’arrêt effectif (le classique preStop avec un sleep de quelques secondes), des requêtes peuvent encore arriver sur un pod qui s’éteint.

La contrainte structurante : N et N+1 coexistent

Pendant toute la transition, deux versions tournent en même temps et se partagent le trafic — et souvent la même base de données. C’est la vraie contrainte du rolling deployment : chaque changement de schéma doit être compatible avec les deux versions (on ajoute une colonne avant de l’utiliser, on ne la supprime qu’une version plus tard). L’erreur classique consiste à tester la version N+1 isolément et à découvrir en production que N ne survit pas à la migration déjà appliquée. Un rolling deployment sans cette discipline de compatibilité est une interruption de service en plusieurs actes.