EKS Version Rollback : les upgrades Kubernetes réversibles
Un upgrade de cluster Kubernetes a longtemps eu le statut d'opération irréversible. Vous planifiiez, vous testiez en staging, vous déployiez en prod un dimanche à 3 h du matin. Et si ça cassait, vous débuggiez en direct sur un cluster à moitié cassé, avec des pods qui refusent de se scheduler et des API qui renvoient des erreurs incohérentes. AWS vient de fermer cette ère sur EKS : la fonctionnalité Version Rollback permet de revenir à la version Kubernetes précédente, dans les 7 jours suivant l'upgrade, en une opération.
Ce que permet Version Rollback
Annoncée début juillet 2026 et disponible sur tous les clusters EKS, la fonctionnalité répond au scénario que tout ops redoute : l'upgrade de 1.34 vers 1.35 qui met le feu à une partie de la plateforme. Le retour arrière se limite à la version mineure précédente — pas de saut multiple — et la fenêtre de 7 jours correspond à la période de support de l'ancienne version de control plane par AWS.
Le principe paraît simple, mais il change la dynamique entière de l'upgrade. Le risque n'est plus binaire — ça passe ou ça casse tout — il devient réversible : upgrade, problème, rollback. Trois gestes au lieu d'un post-mortem de deux semaines.
Pourquoi c'est un vrai sujet de fiabilité
Les upgrades Kubernetes restent une des premières causes d'incidents d'infrastructure. Selon un rapport récent de Flexera, environ 40 % des organisations reportent leurs upgrades par peur de casser quelque chose. Ce report a un coût caché : des clusters qui accumulent du retard de version, donc des correctifs de sécurité qui n'arrivent jamais, donc une dette qui se transforme tôt ou tard en surface d'attaque.
Un rollback mécanique ne supprime pas cette peur, mais la réduit assez pour rendre les upgrades plus fréquents. Plus fréquents veut dire moins d'écart de version à chaque saut, moins de dette technique, moins de vulnérabilités qui traînent parce que personne n'ose toucher au cluster.
Les limites à connaître
Version Rollback n'est pas une machine à remonter le temps universelle :
- Les manifestes ne sont pas corrigés. Si vos définitions utilisent des API supprimées dans la nouvelle version, le rollback ne répare pas cette incompatibilité. Les données sont préservées, mais la compatibilité applicative reste votre problème.
- Une seule version en arrière. Pas de saut multiple : le retour arrière vous ramène exactement à la version mineure précédente.
- Sept jours, pas plus. Passé ce délai, l'ancienne version n'est plus supportée et l'option disparaît.
GKE et AKS regardent derrière
À ce jour, ni Google Kubernetes Engine ni Azure AKS ne proposent d'équivalent. C'est un avantage concurrentiel net pour EKS, et un argument de plus pour les équipes qui arbitrent leur plateforme managée sur la gestion du risque opérationnel. Comme le note The New Stack, la réponse classique au risque d'upgrade — le blue-green deployment — reste valable, mais elle coûte le double de nœuds pendant la bascule. Le rollback natif ne coûte rien.
La leçon dépasse le cas d'AWS : la réversibilité est devenue un critère de conception des plateformes, au même titre que la haute disponibilité. Un système qu'on n'ose pas mettre à jour est un système déjà en panne, juste pas encore officiellement.