Parce que c’est le prix de l’absence de coupure. Le Deployment ne tue pas les trois réplicas pour en créer trois autres. Il en crée un (ou plus, selon maxSurge), attend qu’il soit ready, puis en retire un (maxUnavailable). Pendant des secondes ou des minutes, v1 et v2 répondent toutes les deux, sur les mêmes Services, souvent sur la même base.
Vous ne choisissez pas quelle requête atterrit où. Un utilisateur peut frapper v2 puis v1. Un job interne aussi.
Toute migration de schéma, tout contrat d’API, tout message dans une file, doit être compatible avec les deux binaires pendant toute la durée du rollout — et du rollback, qui est le même phénomène dans l’autre sens.
La méthode, pas le slogan « expand/contract » :
Inverser 1 et 2, c’est la panne de vendredi soir : v2 écrit une colonne que v1 ne sait pas lire, le rolling update est « réussi » au sens Kubernetes, le service est cassé une requête sur deux.
Il garantit que vous ne descendez pas sous replicas - maxUnavailable de Pods ready, si la readiness dit vrai. Il ne garantit pas que v1 et v2 sont compatibles. kubectl rollout status vert n’est pas une migration de base réussie.
Recreate existe : tout couper, tout relancer. Zéro overlap, une coupure. On le choisit quand l’overlap est impossible (un processus unique, un verrou global), pas par défaut.
« Comment vous protégez un rollback ? »
Le rollback rejoue l’overlap. Si v2 a migré les données dans un format que v1 ne lit plus, kubectl rollout undo empire. D’où l’ordre ci-dessus, et d’où une readiness qui échoue si v2 ne peut vraiment pas servir — plutôt qu’une liveness cosmétique. Un canary (maxSurge faible, un ReplicaSet à 1, un Service séparé, Flagger, Argo) réduit la part de trafic, il ne supprime pas la contrainte de compatibilité.
Le déroulé avec une base au milieu est dans rolling update : migrer la base sans coupure.