Kubernetes 1.37 a atteint la disponibilité générale le 26 août 2026, avec seize fonctionnalités promues au rang de stable. Cinq jours plus tard, aucun des grands fournisseurs cloud actifs en Europe ne propose encore cette version en production. AWS EKS plafonne à 1.36, Azure AKS annonce une préversion pour septembre, Google GKE reste discret et le fournisseur allemand STACKIT SKE tourne toujours sur 1.34, deux versions majeures en retard. Ce décalage, récurrent à chaque sortie, prend une tournure particulière cette fois-ci : la version 1.37 supprime une fonctionnalité que certaines équipes utilisent encore comme filet de sécurité, et active par défaut un comportement qui peut casser des charges de travail existantes.
Kubernetes 1.37 en chiffres : ce qui change le 26 août 2026
La chronologie officielle des versions Kubernetes confirme un rythme désormais bien rodé : trois sorties majeures par an, environ tous les quatre mois. La version 1.37 s’inscrit dans cette cadence et regroupe seize fonctionnalités passées en stable, deux dépréciations majeures et plusieurs changements de comportement par défaut qui touchent directement la sécurité des nœuds. Deux sujets dominent les retours des mainteneurs et des blogs techniques qui ont couvert la sortie fin août : le passage en disponibilité générale de SELinuxMount, activé par défaut, et la dépréciation du mode IPVS de kube-proxy.
Sur le papier, ces évolutions relèvent de l’optimisation technique. Dans les faits, elles obligent les équipes qui gèrent des clusters avec SELinux activé, ou qui s’appuient encore sur IPVS, à revoir leurs configurations avant de basculer. Plusieurs blogs spécialisés en sécurité des conteneurs ont publié dès la semaine du 26 août des listes de vérifications pré-montée, signe que le sujet inquiète davantage que les précédentes montées de version.
SELinuxMount atteint la disponibilité générale et change de comportement par défaut
La fonctionnalité SELinuxMount passe en disponibilité générale (GA) dans Kubernetes 1.37 et surtout, elle est activée par défaut. Concrètement, au lieu de réétiqueter un volume fichier par fichier à chaque montage, une opération lente sur les gros volumes, le kubelet applique désormais l’étiquette SELinux à l’ensemble du volume en une seule passe grâce à l’option de montage context=<label>. Le gain de performance est réel sur les volumes contenant des millions de petits fichiers, un cas fréquent dans les pipelines de données ou les registres d’images.
Le changement ne s’active que si le pilote CSI du volume l’autorise explicitement, via le champ CSIDriver.spec.seLinuxMount: true. Mais dès qu’il est activé, une contrainte technique s’impose : un point de montage ne peut porter qu’un seul contexte SELinux à la fois. Les clusters où plusieurs pods, avec des étiquettes SELinux différentes, partagent un même volume risquent donc de voir certains pods refuser de démarrer après la mise à niveau. Ce n’est pas une régression au sens strict, mais un changement de comportement qui touche en priorité les environnements multi-tenants avec SELinux activé, typiquement dans le secteur public ou la défense en Europe, où ce module de sécurité Linux reste largement déployé.
SELinuxChangePolicy : une échappatoire qui se referme en 1.38
Pour amortir la transition, Kubernetes 1.37 stabilise aussi SELinuxChangePolicy, également activé par défaut. Cette option permet de revenir temporairement à l’ancien comportement de réétiquetage récursif, via la valeur Recursive, pour les clusters qui ne sont pas encore prêts. Le problème : plusieurs blogs techniques ayant suivi le cycle de développement rapportent que cette échappatoire ne survivra pas à la version 1.38, prévue fin 2026 ou début 2027 selon le rythme habituel du projet. Les équipes qui activent l’option de repli aujourd’hui doivent donc profiter de cette fenêtre pour auditer leurs volumes partagés, pas pour repousser indéfiniment le problème.
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
name: exemple-csi-driver
spec:
seLinuxMount: true
fsGroupPolicy: File
# Repli temporaire disponible jusqu'à Kubernetes 1.38 :
# seLinuxChangePolicy: RecursivebindMountOptions : de nouveaux verrous de sécurité pour les volumes
Moins commentée mais tout aussi structurante, Kubernetes 1.37 introduit un nouveau champ bindMountOptions sur les volumeMounts. Il permet de fixer des drapeaux de sécurité comme noexec, nodev ou nosuid directement au niveau du montage, sans dépendre d’une politique globale au niveau du nœud. Pour les équipes sécurité, c’est un outil supplémentaire pour appliquer le principe du moindre privilège volume par volume, un besoin de plus en plus fréquent depuis la multiplication des exigences de durcissement liées au Cyber Resilience Act (CRA) et aux référentiels de sécurité cloud européens.
Cette granularité rapproche Kubernetes des pratiques déjà courantes sur les hyperviseurs et les conteneurs légers, où l’isolation par montage est un standard depuis plusieurs années. Reste à savoir combien de temps il faudra aux opérateurs de clusters pour intégrer ce champ dans leurs modèles de déploiement Helm ou leurs politiques d’admission, sachant que l’adoption des fonctionnalités de sécurité optionnelles suit historiquement un rythme bien plus lent que celui des fonctionnalités de plateforme.
IPVS déprécié : la fin annoncée d’un mode kube-proxy historique
Deuxième grand chantier de la version 1.37 : la dépréciation du mode IPVS pour kube-proxy. IPVS a longtemps été présenté comme l’alternative performante au mode iptables classique, notamment pour les clusters avec un grand nombre de services. Sa dépréciation ne signifie pas une suppression immédiate, mais elle envoie un signal clair aux équipes qui l’utilisent encore : il faut planifier une bascule vers un autre mode, très probablement vers les implémentations basées sur eBPF qui gagnent du terrain dans l’écosystème, à l’image de Cilium.
Cette dépréciation illustre une tendance de fond du projet Kubernetes : la simplification du cœur du système au profit de composants externes plus spécialisés. Le noyau du projet se recentre sur l’orchestration pure, tandis que la mise en réseau, le stockage avancé et l’observabilité migrent vers l’écosystème CNCF environnant.
Pods statiques : l’échappatoire des secrets et ConfigMaps supprimée
Le changement le plus disruptif pour certaines infrastructures historiques concerne les pods statiques. Depuis 1.37, ils ne peuvent plus référencer de secrets ni de ConfigMaps. Cette fonctionnalité, longtemps considérée comme une échappatoire pratique pour démarrer des composants critiques avant que l’API server ne soit pleinement opérationnel, disparaît purement et simplement. Les équipes qui l’utilisaient pour amorcer des composants de contrôle (etcd, certains opérateurs de stockage, des agents de sécurité au démarrage) doivent migrer vers des mécanismes d’injection alternatifs, comme le montage de secrets via des volumes chiffrés au niveau du système de fichiers du nœud.
Ce n’est pas un changement cosmétique. Sur les clusters bootstrappés à la main, en dehors d’un fournisseur managé, la suppression de cette référence peut casser des scripts d’amorçage écrits il y a plusieurs années et jamais retouchés depuis.
Le grand écart entre la version amont et l’adoption chez les fournisseurs cloud
C’est ici que l’histoire devient intéressante pour les équipes qui opèrent en Europe. La version 1.37 est disponible en amont depuis le 26 août 2026, mais aucun fournisseur cloud majeur ne la propose encore en production à la date de publication de cet article. Le décalage entre la sortie du code source et sa disponibilité chez les hyperscalers n’est pas nouveau, mais l’ampleur des changements de comportement par défaut dans cette version rend l’attente plus tendue que d’habitude.
Selon la documentation officielle du cycle de vie des versions sur Amazon EKS, le support standard couvre actuellement les versions 1.36, 1.35 et 1.34, tandis que le support étendu, payant, couvre 1.33, 1.32 et 1.31. La version 1.37 n’apparaît nulle part dans ces listes début septembre 2026. Pour donner une idée du délai habituel, AWS avait annoncé la disponibilité de Kubernetes 1.36 sur EKS le 2 juin 2026, soit environ six semaines après la sortie amont de cette version, survenue fin avril. Si ce rythme se répète, EKS ne devrait pas proposer 1.37 avant la mi-octobre 2026.
Côté Microsoft, le tableau publié dans la documentation des versions Kubernetes prises en charge par Azure AKS est plus explicite sur le calendrier à venir : préversion (preview) de 1.37 annoncée pour septembre 2026, disponibilité générale visée pour octobre 2026, avec une fin de support standard fixée à octobre 2027 et une fin de support étendu (LTS) à octobre 2028. AKS avait ouvert la disponibilité générale de 1.36 avec support long terme dès le 19 juin 2026, un rythme plus rapide qu’AWS sur cette version précédente.
Tableau comparatif : où en sont les fournisseurs cloud début septembre 2026
Le tableau ci-dessous synthétise l’état des lieux, tel que documenté publiquement par chaque fournisseur au 1er septembre 2026. Il illustre un écart net entre les trois hyperscalers américains, qui avancent à un rythme trimestriel assez régulier, et certains fournisseurs européens, dont le calendrier de mise à jour reste nettement plus lent.
| Fournisseur | Dernière version stable disponible | Date de disponibilité | Statut Kubernetes 1.37 |
|---|---|---|---|
| AWS EKS | 1.36 (support standard) | 2 juin 2026 | Non annoncé, estimé mi-octobre 2026 |
| Azure AKS | 1.36 (GA + support long terme) | 19 juin 2026 | Préversion annoncée pour septembre 2026, GA visée octobre 2026 |
| Google GKE | 1.36 (canal Rapid) | Mai 2026 | Aucune date publique confirmée au 1er septembre 2026 |
| Scaleway Kapsule | 1.36 | 7 juillet 2026 | Aucune date publique confirmée |
| STACKIT SKE | 1.34 | Auto-bascule depuis 1.33 le 8 juillet 2026 | Aucune annonce pour 1.35, 1.36 ou 1.37 |
Un chiffre résume l’écart : quand AWS et Azure discutent déjà de leur calendrier pour 1.37, STACKIT reste bloqué deux versions majeures en arrière, sur 1.34, sans annonce publique pour combler ce retard. Ce n’est pas un cas isolé chez les fournisseurs cloud européens de taille intermédiaire, où les équipes d’ingénierie plateforme sont souvent plus réduites que chez les trois hyperscalers américains.
STACKIT à la traîne : un cas d’école du décalage de versions en Europe
Le cas de STACKIT, filiale cloud du groupe Schwarz (propriétaire de Lidl et Kaufland), mérite un détour. Le fournisseur, qui met en avant sa souveraineté et son hébergement exclusivement en Allemagne, a retiré le support de la version 1.33 le 8 juillet 2026 et bascule automatiquement ses clients vers 1.34. Aucune annonce publique n’évoque pour l’instant 1.35, 1.36 ou 1.37. Pour un client dont le cluster a été forcé de migrer sous la contrainte, sans passer par les versions intermédiaires 1.35 et 1.36, l’écart de fonctionnalités disponibles avec un cluster EKS ou AKS à jour devient significatif.
Ce décalage pose une vraie question pour les entreprises françaises et européennes qui choisissent un fournisseur souverain pour des raisons réglementaires, notamment dans le cadre de NIS2 ou des discussions autour du Cloud and AI Development Act. Le choix d’un cloud local peut réduire l’exposition à certains risques géopolitiques, mais il peut aussi allonger le délai avant de bénéficier des correctifs de sécurité et des fonctionnalités les plus récentes du projet Kubernetes.
Pourquoi les fournisseurs cloud traînent des pieds sur les nouvelles versions
Le retard n’est pas de la paresse. Chaque fournisseur managé doit valider la compatibilité de sa propre couche d’orchestration, de ses contrôleurs internes et de ses intégrations réseau et stockage avant d’ouvrir une nouvelle version à ses clients. Plus une version majeure change de comportements par défaut, comme c’est le cas avec SELinuxMount cette fois-ci, plus la phase de validation interne s’allonge, car un incident de production chez un client déclenché par une mise à niveau forcée coûte beaucoup plus cher en réputation qu’un mois de retard sur le calendrier amont.
Les hyperscalers américains disposent de plusieurs centaines d’ingénieurs dédiés à cette validation, répartis entre plusieurs équipes de release. Les fournisseurs de taille intermédiaire, en Europe notamment, opèrent avec des équipes bien plus réduites, ce qui explique mécaniquement l’écart de rythme observé dans le tableau ci-dessus. Ce constat rejoint les analyses déjà publiées sur le sujet de la montée en exigence des référentiels de sécurité pour les conteneurs en Europe, où le nombre de critères à valider a bondi ces derniers mois.
Contexte historique : de Kubernetes 1.0 à la cadence trimestrielle actuelle
Kubernetes a publié sa première version stable, 1.0, en juillet 2015, sous l’égide de Google puis de la Cloud Native Computing Foundation. Le projet a longtemps visé un rythme de sortie trimestriel strict, avant d’assouplir légèrement ce calendrier ces dernières années pour privilégier la qualité des tests de compatibilité ascendante. La version 1.37 s’inscrit dans la continuité de cette approche : elle ne bouleverse pas l’architecture du projet, mais elle continue le travail de fond entamé depuis plusieurs cycles sur le durcissement de la sécurité des nœuds, notamment via SELinux, un sujet monté en priorité depuis que les clusters Kubernetes hébergent de plus en plus de charges de travail sensibles ou réglementées.
Sur dix ans, le projet est passé d’un outil d’orchestration expérimental à l’épine dorsale de facto de l’infrastructure cloud native mondiale. Le rythme de release, désormais prévisible, est devenu un point de repère pour les équipes de planification des fournisseurs cloud, qui calent leurs propres feuilles de route dessus, avec plus ou moins de succès selon les moyens dont elles disposent.
L’ombre de Januscape : quand une faille KVM percute le calendrier des mises à niveau
La sortie de Kubernetes 1.37 arrive alors que les équipes d’infrastructure européennes gèrent encore les suites de Januscape, la vulnérabilité KVM (CVE-2026-53359) qui a forcé une vague de correctifs sur les nœuds pendant l’été. Il s’agit d’une faille de type use-after-free dans l’implémentation shadow MMU du sous-système KVM/x86 du noyau Linux, permettant à une machine virtuelle invitée de s’échapper vers son hôte, c’est-à-dire potentiellement vers le nœud du cluster. Le correctif amont a été publié le 19 juin 2026, intégré dans les noyaux 6.18.38 et ses rétroportages, comme le détaille l’avis de sécurité publié par les mainteneurs de Cozystack.
Pour les équipes plateforme, cela signifie deux chantiers de mise à niveau qui se chevauchent au même moment : patcher le noyau des nœuds contre Januscape, et préparer la bascule vers Kubernetes 1.37 avec ses changements de comportement par défaut. Empiler ces deux opérations augmente mécaniquement le risque d’erreur humaine, ce qui explique en partie pourquoi certains fournisseurs préfèrent étaler les mises à jour plutôt que de les grouper.
Impact marché : ce que ce décalage coûte aux entreprises européennes
Le décalage entre la disponibilité amont et l’adoption chez les fournisseurs managés a un coût concret, même s’il est rarement chiffré publiquement. Une entreprise qui a besoin d’une fonctionnalité stabilisée dans 1.37, par exemple les nouveaux verrous bindMountOptions pour répondre à une exigence d’audit de sécurité, doit soit attendre plusieurs semaines que son fournisseur managé propose la version, soit gérer elle-même un cluster auto-hébergé avec la version amont, ce qui déplace la charge opérationnelle et le risque vers ses propres équipes.
Ce type d’arbitrage pèse particulièrement sur les entreprises soumises à des obligations de conformité serrées, dans la finance ou la santé par exemple, où la traçabilité des correctifs de sécurité appliqués à l’infrastructure fait partie des points de contrôle audités. Un cluster bloqué deux versions en arrière, comme c’est le cas chez certains clients STACKIT actuellement, complique la démonstration de diligence raisonnable lors d’un audit, même si l’infrastructure reste par ailleurs correctement gérée.
Comparaison des réglages de sécurité par défaut entre versions
Pour mesurer l’ampleur du changement introduit par la version 1.37, le tableau suivant compare les principaux réglages de sécurité par défaut sur les trois dernières versions majeures du projet.
| Réglage | Kubernetes 1.35 | Kubernetes 1.36 | Kubernetes 1.37 |
|---|---|---|---|
| SELinuxMount | Feature gate désactivée par défaut | Bêta, activable via feature gate | Stable, activée par défaut |
| SELinuxChangePolicy | Non disponible | Bêta | Stable, repli possible jusqu’à 1.38 |
| Mode kube-proxy IPVS | Supporté | Supporté | Déprécié |
| Secrets/ConfigMaps sur pods statiques | Autorisé | Autorisé | Supprimé |
| bindMountOptions sur volumeMounts | Non disponible | Non disponible | Introduit |
Ce tableau montre une progression cohérente sur trois cycles : chaque fonctionnalité liée à SELinux a suivi le chemin classique du projet, de la feature gate désactivée à la bêta puis à la disponibilité générale activée par défaut. C’est ce dernier saut, de bêta à stable-par-défaut, qui provoque le plus de frictions chez les opérateurs, car il transforme une option qu’on choisissait d’activer en un comportement qu’il faut désormais choisir de désactiver.
Prédictions : ce qui attend les opérateurs Kubernetes d’ici la fin 2026
- AWS EKS devrait ouvrir le support standard de Kubernetes 1.37 autour de la mi-octobre 2026, si le fournisseur reproduit le délai de six semaines observé pour la version 1.36.
- Azure AKS, selon son propre calendrier publié, devrait passer 1.37 en disponibilité générale en octobre 2026, avec une préversion ouverte dès septembre.
- Les fournisseurs cloud européens de taille intermédiaire, à l’image de STACKIT ou Scaleway, resteront probablement en retard d’au moins une version majeure sur les hyperscalers pendant encore plusieurs cycles, sauf renforcement notable de leurs équipes de plateforme.
- La dépréciation d’IPVS devrait accélérer la migration des grands clusters vers des solutions de mise en réseau basées sur eBPF, un mouvement déjà amorcé avant l’annonce de 1.37.
- La fermeture de l’échappatoire SELinuxChangePolicy prévue pour Kubernetes 1.38 va probablement provoquer une vague d’audits de volumes partagés chez les grandes entreprises courant début 2027, avant que l’option de repli ne disparaisse définitivement.
Ce que les équipes d’infrastructure doivent vérifier avant de migrer
Avant toute migration vers Kubernetes 1.37, une fois la version disponible chez le fournisseur managé concerné, trois vérifications s’imposent. D’abord, un audit des volumes persistants pour repérer les cas où plusieurs pods aux étiquettes SELinux différentes partagent un même point de montage, la situation la plus susceptible de provoquer un échec de démarrage après mise à niveau. Ensuite, un inventaire des usages du mode IPVS de kube-proxy, pour préparer une bascule progressive avant que la dépréciation ne devienne une suppression pure et simple. Enfin, un recensement des pods statiques qui référencent encore des secrets ou des ConfigMaps, afin de migrer ces références vers un mécanisme d’injection compatible avant la mise à niveau, plutôt que de le découvrir en production.
Ces trois vérifications, simples sur le papier, demandent un temps d’ingénierie non négligeable sur les clusters anciens, où la documentation des choix de configuration d’origine a parfois disparu avec le départ des équipes qui les ont mis en place. C’est précisément ce travail d’archéologie qui explique pourquoi de nombreuses entreprises attendent plusieurs mois après la disponibilité générale chez leur fournisseur avant de basculer réellement leurs clusters de production.
Questions fréquentes
Quand Kubernetes 1.37 est-il sorti ?
Kubernetes 1.37 a atteint la disponibilité générale le 26 août 2026, avec seize fonctionnalités promues au rang de stable dans cette version.
Pourquoi ma migration vers 1.37 peut-elle casser des pods existants ?
Le principal risque vient de SELinuxMount, activé par défaut dans cette version. Un point de montage ne peut porter qu’un seul contexte SELinux, donc les pods aux étiquettes différentes qui partagent un même volume peuvent échouer à démarrer après la mise à niveau si le pilote CSI concerné a activé cette option.
Puis-je désactiver SELinuxMount après la mise à niveau ?
Oui, via l’option SELinuxChangePolicy réglée sur Recursive, mais uniquement jusqu’à la sortie de Kubernetes 1.38, où cette échappatoire devrait disparaître selon le calendrier annoncé par le projet.
Quand AWS EKS proposera-t-il Kubernetes 1.37 ?
Aucune date n’est officiellement confirmée au 1er septembre 2026. En se basant sur le délai de six semaines observé lors du passage à 1.36, ouvert le 2 juin 2026, une disponibilité mi-octobre 2026 est plausible, sans garantie.
Que devient le mode IPVS de kube-proxy ?
Il est déprécié dans Kubernetes 1.37, sans date de suppression définitive annoncée. Les équipes qui l’utilisent encore devraient commencer à planifier une bascule vers un autre mode de mise en réseau, notamment les solutions basées sur eBPF.
Pourquoi les pods statiques ne peuvent-ils plus référencer de secrets ?
Cette capacité, longtemps utilisée comme échappatoire pour amorcer des composants critiques avant que l’API server ne soit disponible, a été supprimée dans Kubernetes 1.37. Les équipes concernées doivent migrer vers un autre mécanisme d’injection, par exemple un montage de secrets via le système de fichiers du nœud.
Quel rapport entre Kubernetes 1.37 et la faille Januscape ?
Aucun lien technique direct, mais un chevauchement de calendrier. Les équipes d’infrastructure européennes doivent gérer en même temps le correctif noyau contre Januscape (CVE-2026-53359), une faille d’échappement de machine virtuelle KVM corrigée en amont le 19 juin 2026, et la préparation de la mise à niveau vers Kubernetes 1.37, ce qui augmente la charge opérationnelle du moment.
Faut-il migrer vers Kubernetes 1.37 dès que mon fournisseur le propose ?
Pas nécessairement dès le premier jour. Il est plus prudent de commencer par les trois vérifications décrites plus haut, volumes partagés SELinux, usages d’IPVS et pods statiques avec secrets, avant de basculer les clusters de production, en particulier sur les environnements soumis à des exigences de conformité strictes.
