Rollback mise à jour Kubernetes production : plan de reprise

Pourquoi un rollback de mise à jour Kubernetes en production n’est pas un bouton

Le mot « rollback » donne une impression trompeuse : revenir exactement à l’état précédent. Dans Kubernetes, cette idée fonctionne très bien pour un déploiement applicatif. Pour le control plane, les API, les données d’état et les add-ons, elle doit être examinée beaucoup plus prudemment.

Une montée de version peut modifier les API disponibles, le comportement d’un contrôleur ou le format de données stocké. Si un composant a déjà consommé ces changements, tenter une rétrogradation rapide peut aggraver l’incident au lieu de l’isoler.

Le bon objectif n’est donc pas « annuler toutes les étapes ». C’est de restaurer un service fiable avec une perte de données et une indisponibilité connues, après avoir choisi le chemin le moins risqué.

Cette distinction change la gouvernance de la fenêtre. L’équipe doit savoir qui arrête l’opération, qui décide une restauration et qui communique aux équipes produit. Ces rôles se définissent avant le début, lorsque la pression est faible.

Préparer la fenêtre : versions, dépendances et points de reprise

Commencez par la trajectoire de version réellement supportée par votre distribution Kubernetes managée ou auto-hébergée. Une mise à niveau majeure peut imposer des paliers intermédiaires. Sauter un palier pour gagner une soirée accroît surtout le coût du diagnostic.

Inventoriez ensuite les composants qui parlent au cluster : ingress, CNI, CSI, DNS, monitoring, admission webhooks, opérateurs, autoscaling et outils de sauvegarde. Vérifiez leur matrice de compatibilité avec la cible, puis notez les versions actuellement déployées.

Les API dépréciées sont un risque fréquent. Avant la fenêtre, cherchez les manifestes, Helm charts et ressources personnalisées qui les utilisent. Une application qui continue à déployer une API retirée peut échouer bien après que les nœuds semblent sains.

Préparez également une liste courte de métriques de santé : disponibilité des API, erreurs 5xx du trafic applicatif, latence, taux de pods non prêts, saturation réseau et échecs de jobs critiques. Elles formeront vos critères objectifs de go/no-go.

Le flux de décision à garder en tête

Découpez la fenêtre en étapes réversibles autant que possible. Par exemple, mettez d’abord à jour un environnement de préproduction représentatif, puis un pool de nœuds canary. Observez le trafic et les workloads avant d’étendre l’opération au reste du cluster.

Un canary n’est utile que s’il porte des charges proches de la réalité : réseau, stockage, politiques de sécurité et trafic applicatif. Une simple charge synthétique peut confirmer qu’un nœud démarre, sans révéler qu’un webhook bloque les déploiements.

Mini-lab : valider un upgrade Kubernetes sans toucher la production

Ce mini-lab teste votre procédure dans un cluster de développement ou une sandbox. N’utilisez ni un contexte de production ni des identifiants capables de le modifier. Le but est de vérifier la séquence, pas de simuler tous les volumes métier.

Avant toute action, vérifiez le contexte et capturez un état exploitable. Adaptez les commandes à votre distribution : elles sont volontairement en lecture seule.

kubectl config current-context
kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -n 30
kubectl api-resources --verbs=list -o name | sort > api-resources-before.txt

Déployez ensuite une application canary non critique avec une sonde de disponibilité et une dépendance de stockage comparable à votre cas réel. Exécutez votre procédure d’upgrade officielle uniquement sur la sandbox, puis attendez que les contrôleurs aient convergé.

kubectl rollout status deployment/canary-app -n validation --timeout=180s
kubectl get pods -n validation -o wide
kubectl get endpointslice -n validation
kubectl get events -n validation --sort-by=.lastTimestamp

Le résultat attendu est simple : les pods canary sont prêts, le service répond, aucun événement ne signale d’échec persistant et les objets critiques restent lisibles. Comparez aussi les API avant et après pour détecter une suppression attendue ou inattendue.

Pour le nettoyage, supprimez seulement le namespace de sandbox et restaurez sa configuration depuis Git si nécessaire. Si votre test démontre qu’une restauration de control plane est requise, documentez précisément le délai et les prérequis avant toute fenêtre de production.

Réagir à un incident pendant la fenêtre

À la première anomalie, évitez d’enchaîner les modifications. Figez l’étape en cours, notez l’heure et regardez les métriques prévues. L’objectif est de savoir si le défaut est circonscrit au canary, à un add-on ou au control plane.

Si le trafic client ou les workloads critiques dépassent les seuils définis, appliquez la décision convenue. Il peut s’agir d’arrêter l’extension de l’upgrade, de basculer le trafic, de restaurer une sauvegarde ou d’activer une procédure de continuité.

Conservez les événements, logs de composants et versions exactes. Cette trace accélère l’escalade vers le support et évite une seconde tentative fondée sur des souvenirs incomplets. Après stabilisation, transformez l’incident en amélioration de runbook.

Checklist go/no-go pour votre prochaine fenêtre

Erreurs courantes qui transforment l’upgrade en incident

FAQ : rollback et mise à jour Kubernetes

Préparer la reprise avant de moderniser

Une mise à jour Kubernetes réussie est une opération de fiabilité, pas une course à la dernière version. En préparant les dépendances, le canary, les seuils de décision et la restauration, vous réduisez l’incertitude pour les équipes et les clients.

Si votre cluster supporte un service commercial, faites relire le runbook par une personne qui n’a pas rédigé la procédure. Les zones floues apparaissent vite lorsqu’il faut expliquer qui décide, quoi vérifier et comment revenir à un état stable.

La même discipline aide aussi au quotidien. Le monitoring Kubernetes en production doit exposer les signaux utilisés pendant la fenêtre, tandis que le durcissement Kubernetes réduit les surprises liées aux permissions et aux contrôles d’admission.

Planifiez une revue après chaque upgrade. Comparez la durée prévue et la durée réelle, les alertes reçues, les actions manuelles et les décisions prises. Ce retour transforme progressivement une procédure délicate en opération répétable, compréhensible et plus courte.

Gardez enfin une trace des composants qui ont imposé une exception. Une incompatibilité résolue à la main doit devenir une vérification automatique avant la prochaine version. C’est ainsi que l’amélioration de la plateforme protège aussi la capacité de livraison des équipes applicatives.