Fin de support Kubernetes : dates et coûts par cloud

La fin de support Kubernetes correspond à l'arrêt de la maintenance d'une version mineure par le projet upstream. Votre cloud peut continuer à la prendre en charge, parfois avec un supplément. Au 5 novembre 2026, Kubernetes 1.34 a déjà quitté le support upstream, mais reste en support standard jusqu'au 2 décembre sur EKS et au 25 janvier 2027 sur GKE. Pour choisir votre prochaine version, partez de l'échéance qui s'applique à votre cluster.

Le calendrier de support des versions Kubernetes

Méthode et dernière vérification : 5 novembre 2026. Ce relevé rassemble les calendriers publiés, sans garantir la disponibilité de chaque version dans toutes les régions. Les dates upstream viennent du calendrier actif de Kubernetes et de son historique EOL. Les colonnes des clouds reprennent les calendriers EKS, GKE et AKS. Les dates futures peuvent changer.

EKS exprime ses échéances en UTC. Quand Microsoft ne donne qu'un mois, l'échéance correspond à son dernier jour, sauf date explicite. Le déploiement régional peut décaler la disponibilité ou le retrait d'une version. Les dates Kapsule viennent de la politique de support Scaleway. « Non listée » signifie absente de ce calendrier, pas maintenue sans limite. La politique OVHcloud est détaillée plus bas ; les pages consultées ne permettent pas d'établir une date par version. Pour les versions antérieures à 1.31, vérifiez auprès du fournisseur sans prolonger ce tableau par calcul.

Plusieurs échéances tombent ce mois-ci. EKS 1.31 quitte le support étendu le 26 novembre 2026. AWS peut ensuite mettre à jour le plan de contrôle, sans annoncer l'heure ni le jour exact de son intervention. Kapsule 1.33 a atteint sa fin de support le 4 novembre, et 1.34 suit le 29. L'échéance étendue de GKE 1.31 est déjà passée. Sur AKS, novembre marque la fin du LTS de 1.31 et du support standard de 1.34. Vérifiez votre formule de support avant de comparer ces lignes.

Ce que publient Kapsule et OVHcloud

Kapsule donne des dates de fin de support. OVHcloud décrit une politique glissante. Reprendre les dates upstream pour remplir leurs colonnes ferait perdre cette différence.

Scaleway distingue la dépréciation, qui retire une version de la création de clusters, de la fin du support. Sa politique annonce une fenêtre de 14 mois. Après la fin du support, Scaleway prévoit une montée vers le dernier patch de la version mineure supportée suivante sous 30 jours, avec notification par ticket. L'option de mise à jour automatique des patchs ne dispense donc pas de préparer les montées mineures. Cette politique ne décrit pas de droit à une extension payante séparée.

Attention à la colonne choisie. Le tableau Scaleway affiche, pour l'upstream 1.34 et 1.35, des dates différentes de celles du projet Kubernetes. Notre colonne upstream suit Kubernetes ; la colonne Kapsule suit « End of Support » chez Scaleway. Si vous reprenez ce tableau dans votre documentation, conservez cette distinction et faites confirmer une échéance proche dans votre ticket fournisseur.

La politique EOS/EOL d'OVHcloud, datée du 30 mai 2022, prévoit une montée mineure forcée pour la troisième plus ancienne version hors support. Si elle échoue, le service peut être désactivé, après un préavis de 30 jours par e-mail. OVHcloud réserve aussi des interventions d'urgence face à un risque de sécurité. Le rythme historique des versions décrit sur cette ancienne page ne donne pas une durée actuelle de support. Confirmez la liste des versions et l'avis applicable à votre service : les pages consultées ne nous donnent ni extension tarifée ni date par version.

Pour comparer les fournisseurs, demandez les mêmes preuves : versions disponibles, correctifs couverts et préavis avant une mise à jour imposée. Notre page d'infogérance Kubernetes décrit le travail d'exploitation qu'on reprend. La politique de support du cloud continue de s'appliquer.

Combien coûte une montée de version reportée

EKS et GKE affichent tous deux un supplément de 0,50 $ par cluster et par heure pendant la période étendue. Regardez surtout son déclenchement. Le même tarif horaire peut produire une facture différente selon que le fournisseur active la prolongation par défaut ou vous demande de choisir un canal précis.

Prix publics en dollars US relevés le 5 novembre 2026 sur les pages tarifaires EKS et GKE. Ils concernent la gestion du cluster, pas un devis de nœuds dans une région donnée. Nœuds, stockage et réseau restent séparés. Les crédits GKE et les remises contractuelles peuvent modifier le montant net ; le tableau ne les calcule pas. Le LTS AKS exige à la fois Premium et le choix explicite du plan LTS.

Avec une hypothèse budgétaire de 730 heures par mois, un cluster EKS ou GKE dans la période majorée ajoute 730 × 0,50 $ = 365 $. Trois clusters ajoutent 1 095 $. C'est un calcul, pas une facture ni une estimation du chantier de migration. Une petite recette paie le même supplément qu'une grosse production : ces frais dépendent du nombre de clusters, pas du nombre de nœuds.

Payer une prolongation laisse du temps pour tester une montée difficile, mais le contrôleur Ingress, les charts Helm et les dépendances applicatives gardent leurs propres échéances de support, indépendamment de ces frais. Désignez un responsable. Fixez aussi une date cible : sans cela, le travail vous attendra encore à la fin de l'extension.

Relever la version, les nœuds et le plan de support

L'inventaire doit contenir la version du serveur, celles des nœuds et le réglage de support du cloud. La version de kubectl sur le poste d'un développeur ne suffit pas.

Ces commandes de lecture utilisent l'interface JSON de kubectl et AWS CLI v2, Google Cloud CLI ou Azure CLI. Elles demandent un compte authentifié autorisé à lire le cluster. Remplacez les valeurs en majuscules et vérifiez d'abord le contexte Kubernetes ; aucune commande ci-dessous ne lance de mise à jour.

kubectl config current-context
kubectl version -o json
kubectl get nodes -o custom-columns='NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion'

aws eks describe-cluster --name CLUSTER --region REGION \
  --query 'cluster.{version:version,support:upgradePolicy.supportType}'

gcloud container clusters describe CLUSTER --location LOCATION \
  --format='yaml(currentMasterVersion,currentNodeVersion,releaseChannel.channel)'

az aks show --resource-group RESOURCE_GROUP --name CLUSTER \
  --query '{version:kubernetesVersion,tier:sku.tier,supportPlan:supportPlan}'

Inscrivez la région et l'identifiant du cluster à côté de son échéance. Ajoutez le canal de publication GKE, ou le plan de support AKS en plus du niveau tarifaire. Pour Kapsule et OVHcloud, joignez la notification ou la confirmation écrite du fournisseur. Gardez la fin de support Kubernetes à côté des échéances du cloud : l'équipe doit pouvoir lire laquelle déclenche le chantier.

Vérifier le runtime et les API avant de choisir la cible

Le calendrier dit quand bouger. Il ne valide pas vos workloads sur la version suivante. Avant de réserver le créneau de production, lisez les notes de version de la cible et les changements d'images de nœuds chez votre cloud.

Containerd montre pourquoi ce détail compte. Le guide de migration containerd 2 de GKE situe la transition des nœuds Linux à GKE 1.33, et celle de Windows Server à 1.35. « Containerd 2 en 1.36 » ne donne donc pas la première version susceptible d'affecter vos nœuds managés. Relevez le runtime effectif et vérifiez la configuration des registres privés, ainsi que les intégrations qui parlent directement à containerd.

Vérifiez aussi la compatibilité cgroup avec l'image de nœud cible. Passez ensuite aux API retirées, aux webhooks d'admission et aux versions des add-ons. Une recette sans trafic peut laisser dormir un traitement planifié ou un opérateur qui réconcilie rarement ses ressources. Rejouer un trafic représentatif et déclencher ces traitements apporte plus de preuves qu'un déploiement simplement vert.

Réserver une revue des montées chaque trimestre

La revue trimestrielle est une recommandation d'organisation, pas une promesse sur les sorties des fournisseurs. Elle sert à choisir une cible supportée avec assez de marge, à la tester en recette et à réserver le créneau de production avant le changement de tarif.

Commencez par les clusters les plus proches de la fin de leur dernière période de support. Regroupez ensuite ceux qui partagent images de nœuds et add-ons : un changement testé peut éclairer les autres. Gardez une tâche distincte pour les node pools, car un plan de contrôle supporté ne prouve pas que chaque worker ou opérateur est à jour. Ne présumez pas qu'une descente de version sur place sera possible. Définissez la procédure de reprise avant le changement.

Conservez l'inventaire avec ses sources et sa date de vérification. Si personne dans l'équipe ne porte les montées, apportez vos versions et vos échéances au diagnostic gratuit de 30 minutes. On pourra définir le rattrapage, sans confondre le paiement du support cloud avec le travail qu'il reste à faire.