Overview
Le cycle 1.37 de Kubernetes a débuté le 18 mai 2026. La première beta (v1.37.0-beta.0) a été publiée le 15 juillet 2026, et la version stable est prévue pour le 26 août 2026 (Calendrier de release: https://www.kubernetes.dev/resources/release/). Le changelog complet couvre les quatres phases alpha (alpha.1, alpha.2, alpha.3) puis la beta, avec environ 70 évolutions réparties entre API changes, features, bug fixes, et cleanup.
Objectif
Cette release s’inscrit dans la continuité des cycles précédents. L’objectif principal est de stabiliser et faire graduer plusieurs KEPs liés à l’infrastructure matérielle (Dynamic Resource Allocation, partitionable devices, device taints), de finaliser des dépréciations annoncées de longue date (cgroup v1, containerd 1.x, mode ipvs de kube-proxy), et d’enrichir le scheduler avec des mécanismes avancés pour les workloads batch et AI (PodGroup, GangScheduling, WorkloadAwarePreemption).
Liens utiles
- Changelog officiel 1.37
- Page de release Kubernetes 1.37
- Dépôt principal Kubernetes
- Release notes filtrées (relnotes.k8s.io)
- KEP-4815: Partitionable Devices
- KEP-5304: CDI Spec Version Dynamic
- Blog SELinux breaking changes
- Documentation Kubernetes
- Analyse DevOps Daily sur 1.37
Installation
La beta (v1.37.0-beta.0) est disponible via les binaires et images containers officiels :
# Télécharger le client kubectl
curl -LO "https://dl.k8s.io/v1.37.0-beta.0/kubernetes-client-linux-amd64.tar.gz"
# Image conformance
docker pull registry.k8s.io/conformance:v1.37.0-beta.0
# Images des composants du control plane
docker pull registry.k8s.io/kube-apiserver:v1.37.0-beta.0
docker pull registry.k8s.io/kube-controller-manager:v1.37.0-beta.0
docker pull registry.k8s.io/kube-scheduler:v1.37.0-beta.0
docker pull registry.k8s.io/kube-proxy:v1.37.0-beta.0
docker pull registry.k8s.io/kubectl:v1.37.0-beta.0Les architectures supportées sont amd64, arm64, ppc64le, et s390x, disponibles en manifest lists multi-arch (Changelog: v1.37.0-beta.0 Container Images).
Notions et concepts
Dynamic Resource Allocation (DRA)
Le framework DRA, passé en GA dans Kubernetes 1.34, continue d’être enrichi. Il permet aux pods de déclarer des besoins matériels complexes (GPUs, NICs, accélérateurs) avec une granularité fine. Dans 1.37, les extensions suivantes sont apportées :
- **Partitionable Devices (KEP-4815)** : permet de découper physiquement un GPU en plusieurs slices logiques, chacune pouvant être allouée indépendamment à des pods différents. Utile pour le bin-packing de workloads d’inférence. (Changelog: v1.37.0-beta.0 Dependency)
- **Device Taints and Toleration** : passé en GA via l’API
resource.k8s.io/v1. (Changelog: v1.37.0-alpha.3 API Change) - **DRA Extended Resources** : promu en GA. (Changelog: v1.37.0-alpha.1 API Change)
- **Consumable Capacity** : correction de bugs sur les SharedCounters et les fractions décimales. (Changelog: v1.37.0-beta.0 Bug or Regression)
- **Attribut standard
resource.kubernetes.io/numaNode** : ajouté pour les drivers DRA (KEP-6072). (Changelog: v1.37.0-beta.0 Feature)
PodGroup et GangScheduling
1.37 introduit l’API CompositePodGroup dans scheduling.k8s.io/v1alpha3 et unifie le GangScheduling et le WorkloadAwarePreemption sous le feature gate GenericWorkload (Changelog: v1.37.0-alpha.2 API Change). Les PodGroups permettent d’orchestrer le scheduling de groupes de pods devant être alloués ensemble.
Le PodGroupPostFilter extension point remplace le hardcoding interne de la preemption pour les PodGroups (Changelog: v1.37.0-beta.0 API Change).
SELinuxMount en GA
Le feature gate SELinuxMount passe en GA dans 1.37. Attention : cela peut casser les workloads existants sur les clusters avec SELinux activé. Un blog dédié explique comment identifier les workloads problématiques et comment migrer (Blog: https://kubernetes.io/blog/2026/04/22/breaking-changes-in-selinux-volume-labeling/). (Changelog: v1.37.0-alpha.3 API Change)
Fin de support cgroup v1 et containerd 1.x
Le kubelet refuse désormais de démarrer si le noeud est en cgroup v1 (sauf si le flag failCgroupV1: false est positionné). containerd 1.x n’est plus supporté (containerd 2.0 minimum requis). Ces changements étaient annoncés depuis plusieurs releases et deviennent effectifs dans 1.37 (Analyse DevOps Daily: https://devops-daily.com/posts/kubernetes-1-37-feature-freeze-whats-locked-in).
Dépréciation du mode ipvs de kube-proxy
Le mode ipvs de kube-proxy est officiellement déprécié depuis 1.35. Dans 1.37, kube-proxy émet un avertissement si le mode n’est pas explicitement spécifié, car le défaut va basculer de iptables vers nftables dans une future release (Changelog: v1.37.0-alpha.1 Feature, v1.37.0-alpha.2 Deprecation).
cAdvisor simplifié
Le kubelet utilise désormais un module cAdvisor allégé (github.com/google/cadvisor/lib) qui supprime de nombreuses options dépréciées, notamment les flags --application-metrics-count-limit, --storage-driver-*, et les métriques container_cpu_load_average_10s. Le kubelet ne démarrera pas si ces flags sont encore présents dans la configuration (Changelog: v1.37.0-alpha.3 Dependency).
Commandes
Quelques nouvelles commandes et changements CLI dans cette release :
# Nouveau flag --max-depth pour kubectl explain --recursive
kubectl explain pod --recursive --max-depth=3
# kubectl top pod supporte desormais --field-selector
kubectl top pod --field-selector=status.phase=Running
# kubectl get crd affiche plus de colonnes
kubectl get crd
# kubectl get supporte le format kyaml (stable)
kubectl get pod -o kyaml
# kubectl cluster-info dump --output-directory cree des fichiers en mode 0600
kubectl cluster-info dump --output-directory=./dump
# kubectl drain --disable-eviction --dry-run=server (corrige)
kubectl drain node-1 --disable-eviction --dry-run=serverDemo
Mise à niveau d’un cluster existant vers 1.37
Cette demo illustre les étapes concrètes pour préparer et effectuer une mise à niveau vers Kubernetes 1.37.
Preparation du cluster
Avant toute chose, verifier que l’infrastructure est compatible :
# Verifier que tous les noeuds sont en cgroup v2
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'
# Verifier containerd 2.0+
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'
# Lister les feature gates deprecies encore actifs
kubectl get kubeletconfig --all-namespacesMise à niveau de etcd
Kubernetes 1.37 embarque etcd 3.7.0 (Changelog: v1.37.0-beta.0 Dependency) :
# Verifier la version actuelle d'etcd
kubectl get pods -n kube-system -l component=etcd -o jsonpath='{.items[0].status.containerImage}'
# Mettre a jour etcd avant le control plane si necessaire
# (suivre la procedure de mise a niveau etcd propre a votre environnement)Mise a jour du control plane
# Mettre a jour kubeadm si utilise
kubeadm upgrade plan
kubeadm upgrade apply v1.37.0-beta.0
# Ou mettre a jour les images directement
kubeadm config images pull --kubernetes-version v1.37.0-beta.0Verification post-upgrade
# Verifier que tous les composants sont sains
kubectl get componentstatuses
kubectl get nodes
# Verifier que le scheduler inclut les nouvelles metriques
kubectl get --raw /metrics | grep scheduler_plugin_execution_duration
# Tester la compression WatchList
kubectl get pods --watch --request-timeout=30s
# Verifier que les nouvelles colonnes CRD sont presentes
kubectl get crdMise a jour de kube-proxy
# Specifier explicitement le mode (iptables, nftables, ou ipvs)
kubectl edit configmap kube-proxy -n kube-system
# Ajouter: mode: nftables (ou conserver iptables)
# Redemarrer le daemonset
kubectl rollout restart -n kube-system daemonset/kube-proxyTest du PodGroup scheduling
1.37 introduit le CompositePodGroup API (Changelog: v1.37.0-alpha.3 Feature). Pour tester :
apiVersion: scheduling.kubernetes.io/v1alpha3
kind: CompositePodGroup
metadata:
name: example-group
spec:
size: 3
minCount: 2kubectl apply -f composite-pod-group.yamlTest de la compression WatchList
Si le feature gate WatchListCompression est actif (beta, activé par défaut) :
# La compression est automatique si le client envoie Accept-Encoding: gzip
# Verifier avec curl
curl -k -H "Authorization: Bearer $(kubectl create token)" \
-H "Accept: application/json" \
-H "Accept-Encoding: gzip" \
https://localhost:6443/api/v1/pods --compressed 2>/dev/nullConclusion
Kubernetes 1.37 est une release de consolidation. Les points d’attention opérationnels sont la fin du support cgroup v1 et containerd 1.x, qui peuvent empêcher le démarrage de kubelet. Côté fonctionnalités, le travail sur DRA (partitionable devices, device taints) et le PodGroup scheduling enrichit la plateforme pour les workloads AI/ML et batch. Le changelog officiel (Source: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.37.md) et la page de release (Calendrier: https://www.kubernetes.dev/resources/release/) fournissent l’ensemble des détails pour préparer la mise à niveau.