Kubernetes v1.37 a atteint son code freeze le 22 juillet 2026, ce qui veut dire que la liste des fonctionnalités cesse de bouger et que la planification de la montée de version commence. La sortie est prévue le 26 août, et deux de ses changements sont des exigences fermes, pas des options. Le kubelet réclame désormais containerd 2.0 ou une version supérieure, car le support de containerd 1.x et la vieille API CRI v1alpha2 disparaissent. Les nœuds encore sous cgroup v1 refuseront de démarrer le kubelet, sauf si vous positionnez explicitement failCgroupV1 à false. S'ajoutent une nouvelle étape pour Dynamic Resource Allocation et l'arrivée d'etcd RangeStream, qui rend les grands appels list moins coûteux. C'est le moment de tester, pas le moment d'être surpris en production.
The short answer
Kubernetes v1.37 a atteint son code freeze le 22 juillet 2026, pour une disponibilité générale prévue le 26 août. Les deux changements qui toucheront tous les opérateurs sont des exigences fermes : le kubelet réclame containerd 2.0 ou supérieur, et cgroup v2 est de fait obligatoire car le drapeau FailCgroupV1 vaut true par défaut. Dynamic Resource Allocation progresse, avec Device Taints and Tolerations qui atteint la disponibilité générale, et etcd RangeStream arrive derrière un feature gate pour rendre les grandes opérations list moins coûteuses. Rien de tout cela n'est censé être découvert sur un nœud en production, testez donc d'abord les versions candidates.
La plupart des code freezes sont une étape administrative discrète. Celui-ci mérite un rappel dans l'agenda, car Kubernetes v1.37 transforme deux recommandations en exigences, et les deux vivent au niveau du nœud, là où une mauvaise hypothèse devient un statut NotReady.
Les deux changements qui ne sont pas optionnels
Commençons par le runtime. Kubernetes v1.37 abandonne le support de containerd 1.x, et la vieille API CRI v1alpha2 est retirée. Si un nœud tourne encore sur une série containerd 1.x, le kubelet ne négociera pas avec lui comme la v1.37 l'attend. Le correctif est banal, et c'est justement le point : vérifiez chaque nœud avec containerd --version, et passez le runtime en 2.0 ou supérieur avant de toucher au plan de contrôle.
Le second changement concerne les cgroups. cgroup v2 est désormais le monde supposé. Un nœud encore sous cgroup v1 refusera de démarrer le kubelet, sauf si vous positionnez explicitement failCgroupV1 à false, car le drapeau FailCgroupV1 vaut true par défaut dans cette version. Le fallback de l'ancien drapeau --cgroup-driver a lui aussi disparu, donc le kubelet se fie au pilote cgroup rapporté par le CRI et à rien d'autre. Confirmez chaque nœud avec stat -fc %T /sys/fs/cgroup/, qui doit dire cgroup2fs. Tout hôte présentant encore l'ancienne hiérarchie a besoin d'une reconfiguration, pas d'un espoir.
Dynamic Resource Allocation continue de grandir
Le travail de fond le plus intéressant se trouve dans Dynamic Resource Allocation, le cadre qui permet à Kubernetes d'ordonnancer du matériel spécialisé avec le même soin qu'il accorde au CPU et à la mémoire. Dans la v1.37, Device Taints and Tolerations atteint la disponibilité générale via l'API resource.k8s.io/v1, ce qui donne aux opérateurs un moyen de première classe pour isoler un accélérateur défaillant afin que l'ordonnanceur cesse d'y placer des demandes.
Partitionable Devices reste en alpha. C'est la ligne à surveiller si vous faites de l'inférence, car c'est la voie vers le découpage d'un GPU physique en plusieurs tranches ordonnançables pour des charges multi tenant. Ce n'est pas encore prêt pour la production, mais la direction est claire, et il vaut la peine de l'éprouver dès maintenant dans un cluster de test pour que la future promotion ne soit pas un démarrage à froid.
etcd rend les grandes listes moins chères
Il y a un gain plus discret au niveau du stockage. etcd v3.7.0 est sorti le 8 juillet avec une fonctionnalité nommée RangeStream, et la v1.37 l'expose via le feature gate EtcdRangeStream. Le mécanisme est simple et utile : les grandes opérations list diffusent leurs résultats par blocs plutôt que de bufferiser toute la réponse côté serveur. Pour les clusters qui émettent des appels list et watch fréquents et volumineux, et quiconque exploite un plan de contrôle chargé sait qu'ils existent, cela se traduit directement par une charge CPU etcd plus basse. La fonctionnalité est pour l'instant derrière un gate, ce qui est la bonne posture pour un changement aussi proche du datastore, mais c'est un point à mesurer délibérément une fois sur la version.
La montée est une checklist, alors utilisez-en une
La façon la plus saine de traiter la v1.37 est de la voir comme une tâche d'exploitation avec trois portes concrètes. Confirmez containerd 2.0 ou supérieur sur chaque nœud. Confirmez cgroup v2 sur chaque nœud. Lancez ctr deprecations list pour attraper les incompatibilités au niveau du runtime avant que l'ordonnanceur ne le fasse. Puis prenez un cluster de préproduction, pointez-le vers une version candidate de la v1.37, et faites-y passer vos vraies charges, avec une attention particulière aux device plugins, à l'ordonnancement GPU et à tout composant qui s'appuie sur un trafic list à haute fréquence.
Un code freeze le 22 juillet signifie que les surprises sont déjà écrites. Une disponibilité générale le 26 août signifie que vous avez environ cinq semaines pour les lire. Passer un après-midi en préproduction maintenant coûte bien moins cher qu'une soirée sur un nœud qui refuse de rejoindre le cluster.
Sources et pour aller plus loin
- Kubernetes v1.37 Release Information
- Calendrier et équipe de la v1.37
- Vue d'ensemble des versions Kubernetes
Questions fréquentes
Quand Kubernetes v1.37 sort-il vraiment ?
Le code freeze est intervenu le 22 juillet 2026 (anywhere on Earth), soit le 23 juillet à 12h00 UTC. À partir de là, le périmètre des fonctionnalités de la v1.37 est verrouillé et le cycle passe à la stabilisation. La disponibilité générale est prévue le 26 août 2026. L'écart entre ces deux dates est précisément la fenêtre pour tester les versions candidates sur vos propres clusters, puisque tout ce qui sera dans la version finale est déjà dans l'arbre.
Pourquoi la v1.37 exige-t-elle containerd 2.0 ?
Kubernetes v1.37 abandonne le support de containerd 1.x, et la vieille API runtime CRI v1alpha2 a été retirée. Si vos nœuds tournent encore sur une série containerd 1.x, le kubelet ne dialoguera pas avec le runtime comme il l'attend. Vérifiez chaque nœud avec containerd --version avant la montée de version, et faites d'abord évoluer le runtime. C'est le genre de prérequis trivial à corriger en préproduction et pénible à découvrir sur un nœud qui vient de passer NotReady.
Que change cgroup v2 dans cette version ?
cgroup v2 devient le défaut supposé. Les nœuds sous cgroup v1 refuseront de démarrer le kubelet, sauf si failCgroupV1 est explicitement positionné à false, car le drapeau FailCgroupV1 vaut désormais true par défaut. Le fallback de l'ancien drapeau --cgroup-driver disparaît aussi, donc le kubelet se fie entièrement au pilote cgroup rapporté par le CRI. Vérifiez chaque nœud avec stat -fc %T /sys/fs/cgroup/, qui doit renvoyer cgroup2fs, et prévoyez une reconfiguration pour tout hôte encore sur l'ancienne hiérarchie.
Quoi de neuf pour Dynamic Resource Allocation et etcd ?
Dynamic Resource Allocation continue de mûrir. Device Taints and Tolerations atteint la disponibilité générale via l'API resource.k8s.io/v1, et Partitionable Devices reste en alpha, ce qui est la voie vers le découpage d'un seul GPU entre des charges d'inférence multi tenant. Par ailleurs, etcd v3.7.0 est sorti le 8 juillet avec RangeStream, et la v1.37 l'expose via le feature gate EtcdRangeStream. Les grandes opérations list se diffusent désormais par blocs au lieu d'être bufferisées côté serveur, ce qui abaisse la charge CPU d'etcd pour les clusters qui émettent des appels list fréquents et volumineux.
Que faire avant de monter en v1.37 ?
Trois vérifications couvrent l'essentiel du risque. Confirmez containerd 2.0 ou supérieur sur chaque nœud avec containerd --version. Confirmez cgroup v2 sur chaque nœud avec stat -fc %T /sys/fs/cgroup/. Lancez ctr deprecations list pour faire remonter les incompatibilités au niveau du runtime avant qu'elles ne mordent. Puis pointez un cluster de préproduction vers une version candidate de la v1.37 et faites tourner vos vraies charges, en particulier tout ce qui dépend des device plugins, de l'ordonnancement GPU ou d'un trafic list et watch à haute fréquence.