Le compte à rebours est enclenché. Kubernetes 1.34 quitte le support standard le 27 octobre 2026, et les trois grands fournisseurs de cloud (AWS, Google Cloud et Microsoft Azure) ont chacun bâti leur propre grille tarifaire pour les clusters qui traîneront après cette date. Chez AWS et Google, la facture grimpe de 0,10 $ à 0,60 $ par cluster et par heure, soit un facteur six qui se traduit, sur un mois de 730 heures, par un saut d’environ 73 $ à 438 $ par cluster. Pour une DSI qui gère cinquante clusters de production, l’addition peut vite dépasser les 20 000 $ mensuels, juste pour continuer à recevoir des correctifs de sécurité sur une version qui, elle, ne bouge plus.
Ce n’est pas un cas isolé. Chaque version mineure de Kubernetes suit un cycle de vie strict, et 1.34 n’échappe pas à la règle. Ce qui change cette fois, c’est le calendrier serré (moins de deux mois de battement pour les retardataires) et l’écart croissant entre la date de fin de vie fixée par le projet open source et celle, souvent plus tardive mais bien plus coûteuse, imposée par les hyperscalers. Pour les équipes françaises et européennes qui pilotent des clusters critiques, l’enjeu dépasse la simple ligne budgétaire : il s’agit de sécurité, de conformité NIS2, et d’une pression de plus en plus forte pour automatiser les mises à jour.
Kubernetes 1.34 : une fin de vie programmée depuis 2025
Kubernetes 1.34 a été publié en amont (upstream) le 27 août 2025. Comme toute version mineure du projet, elle bénéficie d’environ 14 mois de support communautaire avant de basculer en fin de vie. Selon la page officielle des releases de Kubernetes, la date de fin de vie de la version 1.34 est fixée au 27 octobre 2026. Passé ce cap, plus aucun correctif de sécurité n’est publié par le projet open source lui-même, quelle que soit la gravité d’une faille découverte.
Le calendrier officiel du projet, consultable sur la page des releases Kubernetes, distingue plusieurs phases : la phase active où les correctifs de bugs et de sécurité sont réguliers, une phase de maintenance qui a démarré le 27 août 2026 (seules les failles critiques y sont encore corrigées), puis la fin de vie complète. La version 1.36, elle, reste en support actif avec un dernier correctif publié le 11 août 2026 (version 1.36.4). Sa propre bascule en mode maintenance est prévue le 28 avril 2027, avec une fin de vie fixée au 28 juin 2027.
Cette architecture en cascade crée un problème récurrent pour les équipes d’exploitation : chaque version n’a qu’une fenêtre de vie utile limitée, et les hyperscalers ne calquent pas toujours leur propre calendrier sur celui du projet open source. C’est précisément là que la facture change de visage.
AWS EKS : 0,60 $ de l’heure dès le support étendu
Amazon a publié sa version gérée de Kubernetes 1.34 sur EKS le 2 octobre 2025, quelques semaines après la sortie amont. Selon la documentation officielle d’Amazon EKS sur le cycle de vie des versions, le support standard de la version 1.34 s’étend jusqu’au 2 décembre 2026, soit plus d’un mois après la date de fin de vie fixée par le projet Kubernetes lui-même. Une fois ce cap dépassé, le cluster bascule automatiquement en support étendu jusqu’au 2 décembre 2027.
C’est ce basculement automatique qui pose problème à de nombreuses équipes. AWS facture le plan de contrôle d’un cluster EKS 0,10 $ par heure en support standard. Une fois en support étendu, ce tarif grimpe à 0,60 $ par heure, sans action explicite requise de la part du client : la bascule tarifaire se fait toute seule, dès que la date passe. Rapporté à un mois de 730 heures, cela représente environ 73 $ contre 438 $, soit une multiplication par six de la facture de plan de contrôle pour un unique cluster qui n’a simplement pas été mis à jour à temps.
Pour une organisation qui gère un parc de clusters de test, de préproduction et de production sur plusieurs régions, ce surcoût peut se multiplier rapidement. Une entreprise avec vingt clusters EKS bloqués en 1.34 après la bascule paierait environ 8 760 $ par mois rien que pour le support étendu du plan de contrôle, sans compter les nœuds de calcul associés.
Google GKE : la même mécanique, un calendrier différent
Google Cloud applique une logique tarifaire quasi identique sur son offre Google Kubernetes Engine (GKE), mais avec une architecture de frais en deux couches. Selon la page de tarification officielle de GKE, chaque cluster standard est déjà facturé 0,10 $ par heure au titre des frais de gestion classiques. Une fois la date de fin de support standard dépassée, Google ajoute des frais de gestion supplémentaires dits “de période étendue”, eux aussi fixés à 0,50 $ par heure. Le total grimpe donc, comme chez AWS, à 0,60 $ par heure et par cluster.
La différence se joue sur le calendrier. D’après le calendrier de publication de GKE, la version 1.36 y termine son support standard le 9 août 2027, avec un support étendu qui court jusqu’au 9 juin 2028. Pour la version 1.34, Google Cloud a historiquement tendance à offrir une fenêtre de support standard plus longue que ses concurrents directs, ce qui laisse un peu plus de marge de manœuvre aux équipes qui traînent sur leurs migrations, sans pour autant annuler la logique de surfacturation une fois le délai écoulé.
Dans les deux cas, le message envoyé aux clients est identique : rester sur une version obsolète a un prix, et ce prix est calibré pour rendre la migration financièrement plus attractive que l’inertie.
Comparatif des tarifs de support étendu par fournisseur
Le tableau ci-dessous synthétise les informations disponibles publiquement sur les grilles tarifaires et calendriers de support des trois principaux hyperscalers pour la version 1.34 de Kubernetes.
| Fournisseur | Tarif support standard | Tarif support étendu | Fin support standard (1.34) | Fin support étendu (1.34) |
|---|---|---|---|---|
| AWS EKS | 0,10 $/cluster/heure | 0,60 $/cluster/heure | 2 décembre 2026 | 2 décembre 2027 |
| Google GKE | 0,10 $/cluster/heure | 0,60 $/cluster/heure | Fenêtre plus longue selon la version | Selon calendrier de version |
| Azure AKS | Inclus dans l’offre standard | Support étendu de sécurité disponible | Variable selon canal de version | Non communiqué publiquement dans le détail |
| Kubernetes upstream (auto-géré) | Gratuit (communauté) | Aucun correctif après l’EOL | 27 octobre 2026 | Aucun (fin de vie totale) |
Ce tableau illustre un point clé : contrairement à AWS et Google, qui publient des tarifs précis et documentés pour leur support étendu, Microsoft communique de façon plus parcellaire sur ses grilles Azure Kubernetes Service (AKS). Les équipes qui pilotent des clusters AKS doivent donc se référer directement à la documentation Microsoft actualisée et à leur contrat de support pour connaître le coût exact d’un maintien en version obsolète, une opacité relative qui complique les arbitrages budgétaires côté entreprise.
Pourquoi Kubernetes fonctionne par cycles aussi courts
Le projet Kubernetes publie environ trois versions mineures par an, chacune bénéficiant d’à peu près 14 mois de support communautaire avant extinction. Ce rythme, hérité des débuts du projet chez Google puis repris par la Cloud Native Computing Foundation (CNCF), vise à permettre une évolution rapide de l’API et des fonctionnalités, quitte à imposer aux utilisateurs un effort de mise à jour soutenu.
Dans la pratique, cela signifie qu’une équipe qui ne planifie pas ses montées de version au moins deux fois par an se retrouve mécaniquement hors support à un moment ou un autre. Les hyperscalers ont donc construit des couches de support étendu payantes pour absorber ce décalage, transformant une contrainte technique du projet open source en source de revenus récurrents. Cette dynamique n’est pas nouvelle : elle rappelle le modèle des éditeurs Linux d’entreprise, qui facturent depuis longtemps des extensions de support pour les versions vieillissantes de leurs distributions.
Ce qui change avec Kubernetes, c’est la vitesse. Une distribution Linux d’entreprise reste généralement supportée cinq à dix ans. Une version mineure de Kubernetes, elle, ne dépasse pas 14 mois de vie active. Les équipes qui gèrent des clusters critiques doivent donc intégrer ce rythme dans leur feuille de route FinOps, sous peine de voir leurs coûts d’infrastructure grimper silencieusement à chaque bascule de calendrier.
L’écart entre la date amont et la date des hyperscalers
Un détail technique mérite d’être souligné : la date de fin de vie officielle du projet Kubernetes (27 octobre 2026 pour la 1.34) ne correspond pas exactement à la date de fin de support standard chez les fournisseurs cloud. AWS, par exemple, prolonge son support standard jusqu’au 2 décembre 2026, soit environ cinq semaines de plus que le calendrier communautaire. Cette différence s’explique par le délai entre la sortie amont d’une version et son intégration dans le service géré, qui décale mécaniquement tout le cycle de support côté fournisseur.
Ce décalage crée une zone grise délicate : un cluster peut techniquement tourner sur une version dont le projet Kubernetes ne publie plus aucun correctif de sécurité, tout en restant facturé au tarif standard par le fournisseur cloud parce que celui-ci maintient sa propre fenêtre de support en parallèle. Certains fournisseurs, dont Amazon, appliquent alors des correctifs de sécurité rétroportés en interne au-delà de la date amont, un travail qui justifie en partie le tarif de support étendu une fois cette période également écoulée.
Impact budgétaire pour les entreprises européennes
Pour les directions informatiques françaises et européennes, la question du support étendu Kubernetes s’inscrit dans un contexte budgétaire déjà tendu. Les efforts de maîtrise des coûts cloud, portés depuis plusieurs années par les démarches FinOps, se heurtent régulièrement à ce type de coût caché : une ligne de facturation qui n’existait pas l’année précédente et qui apparaît brutalement parce qu’une équipe n’a pas eu le temps de migrer ses clusters à temps.
Le calcul est simple à faire mais souvent négligé. Un cluster de production coûte, hors compute et stockage, 73 $ par mois en support standard. Le même cluster, laissé en 1.34 après la bascule vers le support étendu, coûte 438 $ par mois, soit 365 $ de surcoût mensuel, 4 380 $ sur l’année. Pour une entreprise qui gère un parc de dix à cinquante clusters, une taille courante chez les grandes entreprises françaises du CAC 40 ou les scale-ups technologiques, la facture additionnelle peut représenter entre 43 800 $ et 219 000 $ par an, uniquement pour avoir repoussé une migration.
Ce surcoût s’ajoute à un contexte réglementaire qui pousse déjà les entreprises à muscler leur gestion des vulnérabilités. La directive européenne NIS2, dont la transposition se poursuit dans plusieurs États membres en 2026, impose aux opérateurs de services essentiels et importants de maintenir leurs systèmes à jour en matière de sécurité. Faire tourner un cluster Kubernetes qui ne reçoit plus aucun correctif du projet open source, même en payant le support étendu du fournisseur cloud, expose donc à un risque de conformité qui dépasse la seule question budgétaire.
Les alternatives : migrer, geler ou externaliser
Face à cette échéance, les équipes d’exploitation disposent de trois grandes stratégies. La première, la plus recommandée en ingénierie de plateforme, consiste à migrer vers Kubernetes 1.36 avant la date butoir. Cette version bénéficie d’un support actif prolongé jusqu’en 2027, ce qui laisse une marge de manœuvre confortable. La migration implique toutefois de valider la compatibilité des API dépréciées, des contrôleurs d’admission et des CRD (Custom Resource Definitions) tierces utilisées en production.
La deuxième option consiste à payer le support étendu de façon temporaire, le temps de finaliser une migration plus complexe. C’est une solution coûteuse mais parfois inévitable pour des clusters legacy qui hébergent des applications monolithiques difficiles à faire évoluer rapidement. Certaines équipes choisissent cette voie en connaissance de cause, en provisionnant explicitement le surcoût dans leur budget cloud du dernier trimestre.
La troisième option, plus radicale, consiste à externaliser la gestion du cycle de vie Kubernetes auprès d’un prestataire spécialisé ou à migrer vers une offre Kubernetes managée par un acteur européen, à l’image d’OVHcloud, Scaleway ou Clever Cloud, qui appliquent leurs propres calendriers de support. Cette option séduit particulièrement les entreprises soucieuses de souveraineté numérique, un sujet devenu central dans les arbitrages cloud européens de 2026.
Historique : un modèle de monétisation qui s’installe
La facturation du support étendu Kubernetes n’est pas une nouveauté absolue. AWS a introduit ce modèle sur EKS il y a plusieurs années déjà, en s’inspirant directement des pratiques établies dans le monde des systèmes d’exploitation d’entreprise. Ce qui a évolué, c’est la généralisation de la pratique chez tous les grands fournisseurs, ainsi que la vitesse à laquelle une version Kubernetes bascule d’un statut à l’autre.
Il y a cinq ans, une entreprise pouvait encore faire tourner un cluster Kubernetes plusieurs années sans se soucier d’un calendrier de fin de vie aussi strict. L’écosystème s’est professionnalisé, la CNCF a formalisé des cycles de release plus prévisibles, mais cette prévisibilité a un revers : chaque version a une date de péremption connue à l’avance, et les fournisseurs cloud en ont fait un levier commercial assumé.
Comparaison avec les cycles de vie d’autres briques cloud
Pour mettre en perspective la rapidité du cycle Kubernetes, il est utile de le comparer à d’autres briques technologiques largement déployées dans les architectures cloud actuelles.
| Technologie | Durée de support standard | Fréquence des versions majeures/mineures | Modèle de support étendu |
|---|---|---|---|
| Kubernetes (upstream) | ~14 mois | ~3 versions mineures/an | Aucun (fin de vie totale) |
| Amazon EKS | 14 mois après release EKS | Suit le rythme upstream | 12 mois, facturé 0,60 $/heure |
| Google GKE | Variable selon canal (Rapid/Regular/Stable) | Suit le rythme upstream | Frais de gestion étendue à 0,50 $/heure en plus |
| Distribution Linux d’entreprise | 5 à 10 ans | 1 version majeure tous les 3-5 ans | Support étendu de sécurité, souvent inclus dans l’abonnement |
Cette comparaison illustre bien l’écart de philosophie entre l’écosystème Kubernetes et celui des systèmes d’exploitation traditionnels. Là où une entreprise pouvait historiquement planifier une montée de version tous les cinq ans, elle doit désormais intégrer un rythme de mise à jour proche de l’annuel pour rester dans les clous du support gratuit sur ses clusters Kubernetes.
Le rôle grandissant de l’automatisation des mises à jour
Face à ce rythme soutenu, de plus en plus d’équipes de plateforme investissent dans l’automatisation du cycle de vie Kubernetes. Des outils de mise à jour progressive, couplés à des pipelines GitOps, permettent de tester une nouvelle version mineure sur un cluster de préproduction avant de la déployer en production de façon graduelle, cluster par cluster. Cette approche réduit le risque de régression tout en évitant de se retrouver bloqué en fin de cycle.
Les fournisseurs cloud eux-mêmes poussent dans cette direction. AWS propose des mises à jour automatiques planifiées pour les clusters EKS qui n’ont pas été migrés manuellement avant la date de fin de support standard, une fonctionnalité qui limite la casse mais retire aux équipes une partie du contrôle sur le calendrier de bascule. Cette automatisation forcée illustre bien la tension entre commodité opérationnelle et maîtrise fine de l’infrastructure, un débat récurrent dans les communautés DevOps.
Ce que cela signifie pour le marché du cloud européen
Selon les estimations de Synergy Research régulièrement citées dans la presse spécialisée, AWS, Azure et Google Cloud représentent ensemble près de 70 % du marché cloud européen. Cette concentration signifie que les décisions tarifaires prises par ces trois acteurs sur le support Kubernetes affectent directement la majorité des charges de travail conteneurisées déployées en France et sur le continent, des start-ups de la French Tech aux grands comptes du secteur bancaire et industriel.
Cette dépendance nourrit un débat de fond sur la souveraineté et la portabilité des charges de travail Kubernetes. Plusieurs acteurs européens, dont OVHcloud, Scaleway et Clever Cloud, proposent désormais des offres Kubernetes managées opérées depuis la France ou l’Union européenne, avec des calendriers de support qu’ils maîtrisent eux-mêmes. Ces alternatives restent toutefois en retrait sur la largeur du catalogue de services annexes (bases de données managées, IA, edge computing) par rapport aux trois géants américains, ce qui limite encore leur adoption à grande échelle chez les entreprises multi-cloud.
Prévisions pour les prochains mois
Plusieurs tendances se dessinent pour la fin d’année 2026 et le début 2027 autour du cycle de vie Kubernetes et de sa monétisation par les hyperscalers.
- La pression tarifaire sur les clusters en fin de vie devrait continuer de s’intensifier, avec probablement des ajustements de prix à la hausse chez au moins un des trois grands fournisseurs d’ici la mi-2027, dans la continuité des hausses déjà observées sur d’autres services cloud en 2026.
- De plus en plus d’entreprises vont automatiser entièrement leur pipeline de mise à jour Kubernetes pour éviter la bascule en support étendu, un mouvement déjà amorcé chez les grands comptes technologiques et qui devrait s’étendre aux entreprises de taille intermédiaire d’ici 2027.
- La demande pour des offres Kubernetes managées européennes devrait continuer de croître, portée par les arbitrages de souveraineté numérique et la volonté de certaines organisations de réduire leur dépendance tarifaire aux trois hyperscalers américains.
- Les régulateurs européens, dans le sillage de NIS2 et du Cyber Resilience Act, pourraient renforcer les exigences de mise à jour de sécurité sur les infrastructures critiques, ce qui rendrait le maintien de clusters en fin de vie encore plus risqué sur le plan de la conformité, indépendamment du coût financier.
- Le rythme de publication des versions mineures de Kubernetes devrait rester stable, autour de trois versions par an, sans signe d’un ralentissement du cycle du côté de la CNCF à court terme.
Comment vérifier si vos clusters sont concernés
Avant toute décision, la première étape consiste à établir un inventaire précis des versions Kubernetes utilisées sur l’ensemble du parc de clusters, qu’ils soient gérés en interne ou via un service managé. Un simple audit de la commande kubectl version exécutée sur chaque cluster, croisé avec la documentation du fournisseur, suffit à identifier les clusters qui approchent de la date de fin de support standard.
kubectl version --short
kubectl get nodes -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersionCette commande permet de croiser rapidement la version du plan de contrôle et celle des nœuds, un décalage entre les deux étant souvent le signe d’une migration partiellement réalisée. Les équipes qui gèrent plusieurs dizaines de clusters ont tout intérêt à automatiser cet audit via un script exécuté régulièrement, ou à s’appuyer sur les tableaux de bord natifs proposés par AWS, Google Cloud et Azure pour suivre l’état de support de chaque cluster en un coup d’œil. Le site indépendant endoflife.date recense également, version par version, les dates de fin de support standard et étendu des principaux services Kubernetes managés, une ressource utile pour croiser les informations officielles des fournisseurs.
Foire aux questions
Quelle est la date exacte de fin de vie de Kubernetes 1.34 ?
Le projet Kubernetes fixe la fin de vie de la version 1.34 au 27 octobre 2026. Passé cette date, plus aucun correctif de sécurité n’est publié par la communauté open source pour cette version.
Pourquoi la date de fin de support AWS EKS diffère-t-elle de la date upstream ?
Amazon EKS publie sa propre version gérée de Kubernetes quelques semaines après la sortie amont, ce qui décale mécaniquement son calendrier de support. Pour la 1.34, le support standard EKS s’étend jusqu’au 2 décembre 2026, plus d’un mois après la date de fin de vie du projet Kubernetes lui-même.
Combien coûte le support étendu d’un cluster EKS ou GKE ?
Chez AWS comme chez Google Cloud, le tarif du plan de contrôle passe de 0,10 $ à 0,60 $ par cluster et par heure une fois le support étendu activé, soit environ 438 $ par mois contre 73 $ en support standard, sur la base d’un mois de 730 heures.
Le basculement vers le support étendu est-il automatique ?
Oui, chez AWS le cluster bascule automatiquement en support étendu et le tarif majoré s’applique dès que la date de fin de support standard est dépassée, sans action explicite requise du client.
Que se passe-t-il si je reste sur Kubernetes 1.34 sans payer le support étendu ?
Sur un cluster auto-géré (Kubernetes upstream sans service managé), aucun correctif de sécurité n’est plus publié après le 27 octobre 2026, ce qui expose l’infrastructure à des vulnérabilités non corrigées. Sur un service managé comme EKS ou GKE, le fournisseur applique automatiquement le tarif de support étendu pour continuer à fournir des correctifs.
Quelle version faut-il cibler pour éviter ce problème à court terme ?
La version 1.36 offre la fenêtre de support la plus large actuellement disponible, avec un passage en mode maintenance prévu le 28 avril 2027 et une fin de vie fixée au 28 juin 2027, ce qui laisse une marge confortable pour planifier la migration suivante.
Les fournisseurs cloud européens appliquent-ils le même modèle tarifaire ?
Des acteurs comme OVHcloud, Scaleway ou Clever Cloud proposent des offres Kubernetes managées avec leurs propres calendriers de support, mais leur catalogue de services annexes reste plus restreint que celui des trois grands hyperscalers américains.
Comment savoir si mes clusters sont concernés par cette échéance ?
Un audit rapide via la commande kubectl version sur chaque cluster, croisé avec la documentation officielle du fournisseur cloud utilisé, permet d’identifier les clusters qui approchent de la date de fin de support standard et de planifier leur migration à temps.
