Mise à jour progressive Rolling update
La stratégie par défaut pour mettre à jour un déploiement Kubernetes : remplacer les anciens pods peu à peu, quelques-uns à la fois, plutôt que de tout arrêter puis de tout relancer. Mise à jour sans interruption, sans environnement parallèle complet.
Le mécanisme : Kubernetes démarre un (ou quelques) nouveaux pods, attend qu'ils soient prêts (readiness probe), retire autant d'anciens, et recommence jusqu'à ce que tout le déploiement soit remplacé. Deux réglages fixent la cadence : maxSurge (combien de pods EN PLUS du nombre voulu peuvent exister temporairement) et maxUnavailable (combien peuvent manquer pendant la transition). Avantage : le service reste disponible en permanence (des pods prêts reçoivent toujours le trafic) et il n'y a pas d'environnement complet à doubler, contrairement au blue-green. Retour arrière : on rétablit l'ancienne version et Kubernetes déroule dans l'autre sens. Contrepartie : pendant le déploiement, deux versions coexistent (elles doivent être compatibles), et une nouvelle version défectueuse se révèle progressivement, pas d'un coup comme lors d'une bascule blue-green — d'où le complément fréquent d'un canari ou d'une livraison progressive. Stratégie de déploiement par défaut de Kubernetes ; à rapprocher du déploiement bleu-vert et de la progressive delivery.