Kubernetes 1.34 ne reçoit plus de correctifs depuis le 27 octobre : votre échéance réelle dépend du fournisseur
Le 27 octobre 2026, Kubernetes 1.34 est passé en fin de vie : plus aucun correctif upstream ne sera publié. Mais la date qui compte vraiment dépend de votre plateforme : le 2 décembre chez EKS, le 25 janvier chez GKE, le 30 novembre chez AKS.
27 octobre 2026. Kubernetes 1.34 est passé en fin de vie : le projet ne publiera plus aucun correctif pour cette branche. La dernière rustine, 1.34.12, remonte au 15 septembre 2026 et corrige notamment la CVE-2026-2270, une faille qui permet à un utilisateur capable d’écrire des StatefulSets et des ControllerRevisions dans un espace de noms de faire créer un Pod par le kube-controller-manager dans un autre. Le point qui compte : cette date upstream ne change presque rien en soi. Ce qui change tout, c’est l’horloge de votre fournisseur — EKS, GKE ou AKS — et ce qu’elle facture pour vous laisser attendre.
Une mort à date fixe, mais pas la même pour tout le monde
La fin de vie upstream est la seule échéance commune. Kubernetes maintient trois branches mineures à la fois : aujourd’hui 1.37, 1.36 et 1.35. 1.34 est entrée en mode maintenance le 27 août 2026, puis en fin de vie le 27 octobre 2026. Après cette date, une CVE découverte dans le noyau de l’orchestrateur n’a plus de correctif 1.34 — sauf si votre distribution décide de le backporter elle-même.
La question n’est donc pas « suis-je en retard », mais « qui va encore me protéger ». La réponse diffère radicalement selon l’endroit où tourne le cluster :
- EKS : le support standard s’arrête le 2 décembre 2026, puis le support étendu s’enclenche automatiquement jusqu’au 2 décembre 2027. Le prix du cluster passe de 0,10 $ à 0,60 $ par heure. Si vous avez désactivé le support étendu, AWS met à niveau le control plane à la fin du support standard.
- GKE : le support standard court jusqu’au 25 janvier 2027. Sur le canal Extended, il va jusqu’au 25 novembre 2027, au tarif de 0,60 $ par heure de cluster.
- AKS : la fin de vie tombe le 30 novembre 2026. Le cluster continue de servir du trafic et de scaler, mais Microsoft cesse d’appliquer les correctifs de sécurité — à moins d’être sur le canal LTS, qui exige le palier Premium et court jusqu’en novembre 2027.
Retenez l’asymétrie : AKS est le plus silencieux le jour J (rien ne bouge, mais plus rien n’est corrigé), tandis qu’EKS est le plus direct (mise à niveau du control plane « à tout moment, sans notification » une fois le support étendu épuisé).
Ce que « plus de correctifs » veut dire concrètement
La CVE-2026-2270 illustre le risque réel. Elle a été corrigée dans 1.34.12, la toute dernière rustine de la branche. Quiconque applique encore des correctifs 1.34 doit au minimum s’assurer d’être en 1.34.12 avant de planifier la migration. Mais une faille équivalente publiée le 1er novembre 2026 n’aura, elle, aucun correctif 1.34.
Sur un cluster autogéré (kubeadm, k3s, RKE2), c’est à vous de porter la responsabilité. Sur un cluster managé, c’est au fournisseur — mais pas de la même façon : EKS dit explicitement qu’il backporte les correctifs de sécurité sur toutes les versions encore supportées, y compris en support étendu, tandis qu’AKS dit explicitement que son « platform support » n’applique pas de correctifs de sécurité. Deux interprétations opposées de la même notion de support.
Le chemin de migration : un mineur à la fois
On ne saute pas de 1.34 à 1.37. Le control plane se met à niveau un mineur à la fois : 1.34 → 1.35 → 1.36 → 1.37. C’est une règle documentée par Microsoft dans la documentation AKS, et partagée par EKS et GKE. Concrètement, pour être en position soutenue durablement, il faut enchaîner jusqu’à 1.36 (fin de vie le 28 juin 2027) ou 1.37 (fin de vie le 28 octobre 2027).
Trois pièges méritent une vérification avant chaque saut :
- GKE peut mettre en pause la mise à niveau automatique s’il détecte l’usage d’une API supprimée par le mineur suivant, jusqu’à constater 30 jours consécutifs sans cet usage. Résultat : ce sont précisément les clusters qui ont des blocages connus qui restent en arrière.
- EKS ne met à niveau que le control plane lors d’une montée forcée. Les nodes autogérés et les managed node groups restent sur l’ancienne version, ce qui vous place dans un état de skew jamais testé : un control plane 1.32 avec des nodes 1.31.
- AKS supprime les images de node Azure Linux 2.0 le 31 octobre 2026 ; les node pools concernés ne peuvent plus scaler.
La règle opérationnelle tient en une phrase : planifiez chaque saut, ne subissez pas la montée forcée du fournisseur.
# Versions et politique de support de tous les clusters EKS de la région
for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
aws eks describe-cluster --name "$c" \
--query 'cluster.[name, version, upgradePolicy.supportType]' --output text
done
# Dates de support qu'EKS fera respecter
aws eks describe-cluster-versions --cluster-versions 1.34 1.35 1.36 1.37 \
--query 'clusterVersions[].[clusterVersion, status, endOfStandardSupportDate, endOfExtendedSupportDate]' \
--output table
# Inventaire GKE : version maître, version nodes, canal
gcloud container clusters list \
--format="table(name, location, currentMasterVersion, currentNodeVersion, releaseChannel.channel)"Ce qui arrive ensuite
La fin de vie de 1.34 n’est pas le dernier rendez-vous de l’année. La sortie de Kubernetes 1.38 est proposée pour le 16 décembre 2026, et 1.35 passera en mode maintenance le 28 décembre 2026 — ce qui déclenchera le même compte à rebours pour les clusters encore en 1.35. Dans l’écosystème adjacent, Helm 3 a publié sa dernière version de fonctionnalités (v3.22.0) le 9 septembre 2026 : les correctifs de sécurité continueront jusqu’au 10 février 2027, après quoi il faudra avoir migré.
Gardez aussi en tête la politique de version skew : le control plane ne peut devancer les kubelets que d’un nombre limité de mineurs. C’est pour cela qu’une montée forcée d’EKS qui ne déplace que le control plane laisse les nodes en arrière, et pourquoi chaque saut doit inclure les deux : le plan de contrôle et les agents de nœud.
Verdict
Si vous êtes encore en 1.34, agissez avant la date de votre fournisseur, pas avant celle du projet : chez AKS, vous n’avez plus qu’un mois avant le 30 novembre et la fin des correctifs ; chez EKS, chaque jour passé après le 2 décembre vous coûte 0,50 $ de plus par heure de cluster. Si votre parc est petit ou autogéré, prenez la branche directe : montez 1.34 → 1.35 → 1.36 avant la fin de l’année, et figez-vous sur 1.36 si vous voulez éviter un second cycle au premier trimestre 2027. Et si vous gérez du multi-cloud, ne raisonnez jamais en version « supportée » : cartographiez chaque cluster contre la date de son fournisseur, car un « 1.34 » sur GKE a encore trois mois de sursis là où un « 1.34 » sur AKS n’en a plus qu’un. La fin de vie upstream n’est qu’une ligne dans un tableau ; la vraie échéance, c’est celle qui déclenche une facture ou une montée forcée.