Migrer un cluster Kubernetes en prod sans tout casser : le guide

Beaucoup d'opérations Kubernetes sont réversibles. Un upgrade ne l'est presque jamais. Une fois le control plane migré, on ne downgrade pas une version minor : la seule porte de sortie est la restauration depuis sauvegarde. C'est ce qui fait de l'upgrade l'opération où l'architecte joue le plus gros.

Le rythme de Kubernetes n'aide pas : trois versions minor par an, et une fenêtre de support court. Les clients accumulent du retard, puis demandent un saut de plusieurs versions « tant qu'on y est ». C'est le piège : Kubernetes ne supporte pas le saut de versions minor. Migrer de 1.26 à 1.30 d'un coup, c'est s'exposer à des incompatibilités cumulées impossibles à diagnostiquer une fois la production tombée.

Ajoutez à cela des composants tiers (CNI, ingress controller, CSI drivers, opérateurs) qui ont chacun leur matrice de compatibilité, et vous comprenez pourquoi un upgrade mal préparé est l'une des premières causes de downtime de production facturé à l'architecte.

La cause numéro un d'un upgrade raté, ce sont les APIs supprimées. À chaque version, Kubernetes retire des API deprecated. Un manifeste qui utilise une apiVersion disparue n'est plus déployable — et vos workloads existants peuvent cesser de se reconcilier.

Avant de toucher au control plane, passez par cet audit :

• Lancez un outil de détection (kubent / kube-no-trouble, Pluto) pour lister toutes les API dépréciées en usage.
• Vérifiez la matrice de compatibilité de chaque composant tiers : CNI (Cilium, Calico), ingress, CSI, opérateurs, service mesh (Istio).
• Contrôlez la version des CRDs et des contrôleurs qui les servent.
• Identifiez les PodDisruptionBudgets mal calibrés qui pourraient bloquer le drain des nœuds.

Cet audit, livré au client sous forme de rapport, n'est pas qu'une étape technique : c'est une pièce de preuve. Il montre que vous avez identifié les risques avant d'agir.

Quoi qu'il arrive ensuite, une certitude : si vous ne pouvez restaurer qu'une seule chose, c'est etcd. La base etcd contient l'intégralité de l'état du cluster. Un control plane qui ne remonte pas après upgrade se récupère par restauration etcd — pas autrement.

Aucun upgrade ne commence avant un snapshot etcd vérifié. C'est la règle que les incidents les plus coûteux rappellent toujours trop tard.

Concrètement, sur un cluster auto-géré : etcdctl snapshot save, vérification de l'intégrité du snapshot, et stockage hors cluster. Sur un service managé (EKS, AKS, GKE), le control plane est géré par le fournisseur, mais sauvegardez tout de même l'état applicatif (Velero pour les ressources et volumes persistants). Et n'oubliez jamais le test : une sauvegarde non testée n'est pas une sauvegarde.

Ce snapshot est aussi votre couverture juridique. Le jour d'un incident, pouvoir restaurer en minutes change radicalement l'ampleur du préjudice — donc de la réclamation.

L'ordre d'un upgrade n'est pas négociable, et l'inverser est une faute classique. La séquence correcte :

1. Control plane d'abord, version minor par version minor. Le control plane supporte des nœuds en version inférieure (skew policy), jamais l'inverse.
2. Composants système ensuite : CNI, ingress, CSI, dans l'ordre de leurs matrices de compatibilité.
3. Nœuds workers en dernier, par rolling update : cordon, drain respectant les PodDisruptionBudgets, upgrade, puis uncordon.

Migrer les nœuds avant le control plane, ou sauter une version minor, viole la version skew policy de Kubernetes et provoque exactement le type d'incompatibilité qui paralyse la production. Procédez toujours sur un environnement de staging identique d'abord, puis en production avec une stratégie progressive (un node group, puis le reste).

Documentez chaque palier franchi. Cette traçabilité est, là encore, ce qui distinguera une migration maîtrisée d'une faute reprochée.

Malgré la méthode, un incident reste possible : un opérateur tiers incompatible non documenté, un PDB qui fige le drain, un comportement non reproductible en staging. Si la production tombe, le client subit un préjudice : chiffre d'affaires perdu, pénalités SLA envers ses propres clients, coût de remédiation.

C'est un dommage immatériel consécutif, et il relève de votre RC Pro. Mais l'assurance ne joue pleinement que si vous démontrez avoir agi en professionnel diligent. C'est là que tout votre dossier méthodologique paie :

• Le rapport d'audit des APIs dépréciées.
• La preuve du snapshot etcd vérifié.
• La validation préalable en staging.
• Le plan de rollback documenté et communiqué au client.

Un architecte qui a suivi et tracé cette méthode aborde une réclamation en position de force. À l'inverse, un upgrade improvisé directement en production, sans sauvegarde ni staging, fragilise même la prise en charge. La méthode et l'assurance ne s'opposent pas : elles se renforcent. Pour sécuriser à la fois vos missions et le matériel sur lequel vous travaillez, pensez aussi à votre assurance matériel informatique.