Un rollback fonctionne quasi instantanément, sans jamais recréer d’images ni retélécharger quoi que ce soit. Ce n’est pas un hasard : un Deployment ne modifie jamais un ReplicaSet existant quand son template change, il en crée un nouveau et réduit progressivement l’ancien à zéro replica, sans jamais le supprimer. Le rollback ne fait qu’inverser cette réduction.

Ce qu’un Deployment gère réellement

Un Deployment ne crée jamais de pods directement : il crée et gère des ReplicaSet, chacun responsable de maintenir un nombre donné de pods conformes à un template précis. Un changement de template (nouvelle image, nouvelle variable d’environnement) ne modifie jamais le ReplicaSet existant : il en crée un nouveau, avec le nouveau template, puis orchestre la transition entre les deux selon la stratégie de rolling update.

# Chaque changement de template crée un nouveau ReplicaSet,
# l'ancien reste visible, juste réduit à zéro replica
kubectl get replicasets -l app=my-app
# my-app-7d9f8c8b4d   0         0         0
# my-app-5f6b9c7d3a   3         3         3

Le pod-template-hash, la clé qui relie tout

Chaque ReplicaSet reçoit un label pod-template-hash, calculé à partir du contenu exact de son template de pod : deux templates identiques produisent le même hash, deux templates différents produisent des hash différents. Ce label permet au Deployment de reconnaître instantanément si un ReplicaSet existant correspond déjà au template demandé, sans avoir à comparer champ par champ à chaque réconciliation.

metadata:
  labels:
    pod-template-hash: 7d9f8c8b4d

Pourquoi les anciens ReplicaSets ne disparaissent pas

Réduire un ancien ReplicaSet à zéro replica plutôt que de le supprimer préserve son historique de configuration exact, prêt à être réactivé instantanément. C’est précisément ce que kubectl rollout undo exploite : la commande ne recrée rien depuis zéro, elle identifie le ReplicaSet précédent (déjà présent, à zéro replica) et inverse simplement les compteurs de replicas entre l’ancien et le nouveau.

# Le rollback est instantané parce qu'il ne fait
# que réajuster des compteurs de replicas déjà existants
kubectl rollout undo deployment/my-app

revisionHistoryLimit : combien d’anciens ReplicaSets garder

Garder indéfiniment tous les anciens ReplicaSets accumulerait un historique sans limite : revisionHistoryLimit (10 par défaut) fixe combien de révisions précédentes restent disponibles pour un rollback, les plus anciennes au-delà de cette limite étant définitivement supprimées.

spec:
  revisionHistoryLimit: 10

Une valeur trop basse limite la profondeur de rollback possible (revenir à une version vieille de 15 déploiements devient impossible si la limite est fixée à 10) ; une valeur trop haute accumule des ReplicaSets inertes qui alourdissent légèrement l’API sans bénéfice réel au-delà d’un historique raisonnable.

À retenir

Un Deployment ne modifie jamais un ReplicaSet existant : il en crée un nouveau à chaque changement de template et réduit l’ancien à zéro replica plutôt que de le supprimer, un mécanisme identifiable via le label pod-template-hash qui relie chaque ReplicaSet à son template exact. Ce choix architectural est précisément ce qui rend un rollback instantané : la commande ne fait que réajuster des compteurs de replicas entre deux ReplicaSets déjà présents, jamais recréer quoi que ce soit depuis zéro. revisionHistoryLimit détermine combien de révisions restent disponibles pour ce rollback, un réglage à ajuster selon la profondeur d’historique réellement utile, central pour toute industrialisation CI/CD qui dépend d’un rollback rapide et fiable.