Kubernetes publie trois versions mineures par an depuis 2021, et chaque version n'est maintenue que 14 mois (12 mois de support actif, 2 mois de maintenance). Une plateforme qui n'upgrade qu'une fois par an vit donc structurellement en fin de support, sans correctif de sécurité upstream et souvent hors des garanties de son fournisseur managé.
La contrainte se durcit côté fournisseurs : AWS facture le support étendu EKS 0,60 $ par cluster et par heure, soit environ six fois le tarif standard, avant une mise à niveau automatique en fin de course ; AKS et GKE appliquent des mécanismes équivalents. À cela s'ajoute la dette d'API — retrait d'Ingress extensions/v1beta1 en 1.22, de PodSecurityPolicy en 1.25 — et les calendriers indépendants des CNI, CSI et opérateurs, qui transforment un saut de version différé en chantier de remédiation.
La bonne nouvelle est que la politique de compatibilité de Kubernetes rend l'opération prévisible : le control plane monte d'une mineure à la fois et les kubelets peuvent rester jusqu'à 3 versions mineures en retrait de l'API server, ce qui ouvre une vraie fenêtre de bascule progressive. Ce document décrit comment exploiter cette marge : détecter les API obsolètes avant la bascule, choisir entre in-place et node pools bleu/vert, calibrer PodDisruptionBudgets et drainage, puis automatiser et vérifier le tout.
Le tempo imposé par l'upstream
La question n'est plus de savoir s'il faut mettre à jour, mais à quelle fréquence et dans quelles conditions. Trois dynamiques convergent aujourd'hui pour transformer l'upgrade Kubernetes d'un projet ponctuel en routine d'exploitation permanente.
Reste à traduire cette contrainte de calendrier en pratique d'ingénierie : compatibilités à vérifier, stratégie de bascule, drainage et automatisation.
Skew de versions et API dépréciées
Kubernetes autorise un décalage borné entre ses composants, et cette fenêtre — pas le calendrier de l'équipe — détermine l'ordre et le rythme des bascules.
Ne validez pas seulement les manifestes de votre dépôt Git : activez les logs d'audit et la métrique `apiserver_requested_deprecated_apis` pendant au moins un cycle complet (batch mensuel inclus) pour capter les appels réels des opérateurs, charts Helm et scripts CI avant de figer la date d'upgrade.
Stratégies d'upgrade comparées
Trois familles de stratégies coexistent en production, et elles ne se distinguent pas par leur élégance mais par le temps qu'il faut pour revenir en arrière.
Un downgrade de version mineure du control plane n'est pas supporté : les schémas etcd migrent en avant seulement. Toute stratégie in-place doit donc s'appuyer sur un plan de roll-forward, un snapshot etcd vérifié et des sauvegardes applicatives testées — pas sur l'illusion d'un bouton retour.
Drainage, PDB et workloads capricieux
Le drainage est le seul moment de l'upgrade où l'interruption devient visible : c'est là que se concentrent les 502 et les pods bloqués pendant des heures.
Automatiser, tester, valider en continu
Trois versions mineures par an signifient un upgrade par trimestre : à ce rythme, seule l'automatisation empêche l'exercice de redevenir un projet.
Un upgrade répété quatre fois par an est un incident ; une rotation de nœuds exécutée chaque semaine est une routine. Automatisez la rotation avant d'automatiser l'upgrade : c'est elle qui révèle les PDB mal réglés et les arrêts sales, à froid, hors fenêtre critique.
Ce qu'il faut retenir
- Connaissez-vous la date de fin de support (End of Life) de la version mineure actuellement en production sur chacun de vos clusters ?
- Avez-vous instrumenté `apiserver_requested_deprecated_apis` et les logs d'audit sur un cycle complet, batchs mensuels compris, plutôt que de vous fier au seul contenu de vos dépôts Git ?
- Chaque application exposée dispose-t-elle d'un PodDisruptionBudget cohérent avec son nombre de réplicas, et d'un `terminationGracePeriodSeconds` aligné sur la durée réelle de ses requêtes ?
- Avez-vous restauré, et pas seulement produit, un snapshot etcd au cours des six derniers mois ?
- Êtes-vous capable de créer un cluster éphémère en version n+1 depuis votre CI et d'y déployer la totalité de votre stack sans intervention manuelle ?
- Vos nœuds sont-ils immuables et remplacés régulièrement, plutôt que mis à jour en place et conservés plusieurs mois ?
