Kubernetes 1.34 sort du support et les trois clouds facturent 438 dollars par mois
Passée en mode maintenance le 27 août 2026, la version 1.34 de Kubernetes atteint sa fin de vie le 27 octobre, et AWS, Azure et Google facturent alors 0,60 dollar par cluster et par heure — soit 438 dollars par mois — pour continuer à la patcher. Migrez avant l’échéance : ce surcoût n’achète aucune fonctionnalité, seulement la survie d’un plan de contrôle dépassé.
27 août 2026. Kubernetes 1.34 passe en mode maintenance : seuls les correctifs de sécurité critiques sont encore acceptés. 27 octobre 2026. C’est la date de fin de vie officielle, après laquelle plus aucun correctif ne sera publié. 438 dollars. C’est le montant mensuel, par cluster, que AWS, Azure et Google Cloud facturent — chacun de leur côté — pour continuer à patcher une version que le projet a abandonnée. Pourquoi c’est important : cette convergence de prix n’est pas un hasard, c’est le marché qui fixe le coût d’un retard de mise à niveau.
Ce que signifie réellement la fin de vie de la 1.34
La page de publication de la 1.34 est limpide : la version est entrée en mode maintenance le 27 août 2026, et sa fin de vie tombe le 27 octobre 2026. Passé cette date, le projet open source cesse de la patcher, point final. Plus de rétroportages de CVE, plus de correctifs de bugs, rien. Un cluster qui tourne encore en 1.34 en novembre 2026 fonctionne sur une version que la communauté Kubernetes a quittée.
Ce qui ne signifie pas que le cluster s’arrête. Cela signifie que chaque nouvelle vulnérabilité découverte dans l’API server, le kubelet ou le controller manager après cette date restera non corrigée en amont, à moins qu’un service cloud managé n’intervienne avec son propre rétroportage. C’est exactement le vide que AWS, Azure et Google Cloud ont chacun transformé en offre payante.
Le calendrier d’août 2026 donne la mesure de l’urgence : 1.34.11, 1.35.8 et 1.36.4 ont tous reçu des correctifs le 11 août, et 1.37.0 est devenue la version courante le 26 août. Un cluster resté en 1.34 est donc désormais à trois versions mineures de retard, et son horloge de support tourne depuis sa date de sortie, pas depuis le jour où l’équipe l’a adopté.
Pourquoi les trois clouds facturent le même prix
Ouvrez les pages tarifaires des trois hyperscalers et un schéma étrange apparaît : tous convergent sur le même chiffre une fois un cluster dépassé, 0,60 dollar par cluster et par heure, soit 438 dollars par mois. Ce n’est pas une entente — c’est ce qui se produit quand trois concurrents décident indépendamment que les clients en retard doivent financer le coût d’ingénierie nécessaire à maintenir en vie de vieux plans de contrôle.
| Fournisseur | Tarif standard | Tarif étendu / LTS | Support | Coût étendu effectif |
|---|---|---|---|---|
| AWS EKS | 0,10 $/cluster/h | 0,60 $/cluster/h (appliqué auto) | ~14 mois standard + 12 mois étendu | 438 $/mois |
| Azure AKS | ~0,10 $/cluster/h (Standard) | ~0,60 $/cluster/h (Premium + LTS) | 1 an communauté + jusqu’à 2 ans LTS | 438 $/mois |
| Google GKE | 0,10 $/cluster/h | +0,50 $/cluster/h (canal Extended) | fenêtre standard + période étendue | 438 $/mois |
Chez AWS, le passage est automatique : tout cluster EKS paie 0,10 dollar par heure pendant la fenêtre de support standard d’environ 14 mois, puis bascule sans opt-out vers le tarif étendu de 0,60 dollar. Chez Azure, la même logique est emballée dans un tier Premium qui inclut le Long Term Support, réservé aux clusters qui y ont souscrit à l’avance. Chez Google, le canal Extended ajoute 0,50 dollar par heure au tarif de base ; les clusters des canaux Standard et Rapid échappent à ce surcoût, mais subissent des mises à niveau forcées selon le calendrier de Google plutôt que le leur.
La facture d’un retard
Faites le calcul sur un seul cluster laissé en support étendu pendant une année entière : 0,60 dollar × 24 heures × 365 jours donne environ 5 256 dollars, sans compter le moindre dollar de calcul EC2, de stockage ou de temps d’ingénierie. Étendez le raisonnement à une flotte : une équipe plateforme qui gère 100 clusters ayant tous manqué la fenêtre de mise à niveau paie près de 525 600 dollars par an rien qu’en frais de support.
Ce chiffre mérite d’être mis en regard de ce que rapporte le rapport State of Kubernetes Optimization de CAST AI, qui a analysé des dizaines de milliers de clusters : une utilisation CPU moyenne de 8 %, une utilisation mémoire de 20 %, et un sur-provisionnement CPU passé de 40 % à 69 % d’une année sur l’autre. Autrement dit, les entreprises paient déjà très cher du CPU qu’elles n’utilisent pas — ajouter 438 dollars par mois et par cluster pour un plan de contrôle dépassé ne fait qu’empiler une dépense inutile sur une autre.
La conclusion est limpide : sur un plan purement financier, il est presque toujours moins cher de mettre à niveau. Le tarif étendu n’achète ni fonctionnalité ni performance — uniquement la poursuite du patching d’une version que le reste de l’écosystème a déjà dépassée.
Mettre à niveau plutôt que payer
La vraie réponse n’est pas de budgéter le surcoût, mais de faire en sorte de ne jamais l’atteindre. Kubernetes publie environ trois versions mineures par an et n’en maintient que trois en support actif à la fois : toute équipe qui saute ne serait-ce qu’un cycle de mise à niveau se retrouve à quelques mois d’une échéance de fin de vie. L’automatisation de la veille de version est donc le meilleur levier.
# Version du plan de contrôle (API server) du contexte courant
kubectl get --raw /version
# Lister la version kubelet des nœuds pour repérer les clusters en retard
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'Deux contraintes strictes encadrent tout chemin de mise à niveau. D’abord, la politique de skew de versions de Kubernetes : le kubelet ne peut accuser plus de deux versions mineures de retard sur le plan de contrôle, et le plan de contrôle ne peut précéder le kubelet que d’une version au plus. Cette seule règle interdit de sauter directement de la 1.34 à la 1.37 — une montée de trois versions est en réalité trois mises à niveau séquentielles, chacune avec sa propre fenêtre de vidage et de retour arrière. Ensuite, les dépréciations d’API sont supprimées à un rythme fixe : les API bêta dépréciées de la 1.34 ont disparu en 1.37, si bien que chaque saut exige une passe de compatibilité sur les CRD, les opérateurs et les webhooks de mutation réellement déployés avant de vider le premier nœud.
Le moyen le moins cher de rester hors du tarif à 438 dollars est de rendre les mises à niveau banales. Traitez chaque version mineure comme un changement routinier à faible risque plutôt que comme un événement : faites tourner l’audit de compatibilité dans un cluster de staging, épinglez les versions des opérateurs, et mettez à niveau le plan de contrôle avant les nœuds afin que la politique de skew ne devienne jamais la raison d’un report. Les équipes qui automatisent cela ne pensent même plus aux dates de fin de vie — elles ont déjà une ou deux versions d’avance quand l’horloge démarre.
Le plan d’action est simple à dérouler avant le 27 octobre : inventorier les clusters encore en 1.34, vérifier la compatibilité des CRD, des opérateurs et des outils de déploiement avec la cible 1.37, puis enchaîner les montées de version une mineure à la fois. Un cluster qui reste trois versions en arrière n’est pas un actif économe, c’est une dette qui finit par se facturer 0,60 dollar de l’heure.
Verdict
Si vos clusters tournent encore en 1.34, planifiez la montée vers 1.35, puis 1.36, puis 1.37 avant le 27 octobre 2026. Chaque cluster laissé au-delà de l’échéance coûte 438 dollars par mois, quel que soit le cloud, et ce montant n’achète aucun progrès.
Si une migration à temps est impossible — dépendance à un opérateur non compatible, gel de changement réglementaire — souscrivez au tarif étendu en connaissance de cause : c’est un pont, pas une destination. Traitez-le comme une dépense de transition bornée dans le temps, avec une date de sortie ferme.
Si vous gérez une flotte, mettez en place une cadence de mise à niveau automatisée et une veille des dates de fin de vie. Le coût réel d’un retard de version ne se voit pas dans le cluster, il se voit sur la facture — et les trois clouds ont déjà fixé le prix.