Kubernetes 1.37 active le scale-to-zero du HPA par défaut et protège etcd des surcharges de l’apiserver
Le 26 août 2026, Kubernetes publie la version 1.37 « Garhwal », qui cumule 67 améliorations dont 16 passées en stable. Le HorizontalPodAutoscaler sait désormais ramener un workload à zéro pod par défaut, et l’apiserver cesse de saturer etcd pendant le réchauffement de son cache.
26 août 2026. Kubernetes publie la version 1.37, baptisée « Garhwal », du nom d’une région himalayenne de l’Uttarakhand, en Inde. Le bilan de la release tranche avec l’habitude : 67 améliorations — 16 passées en Stable, 23 en Beta, 27 en Alpha et une dépréciation — mais aucune fonctionnalité spectaculaire. Pourquoi c’est important : c’est une release de consolidation, et c’est exactement ce que les équipes en production attendaient. Deux changements touchent directement la facture et la résilience du plan de contrôle : le HorizontalPodAutoscaler sait désormais ramener un workload à zéro pod par défaut, et le kube-apiserver cesse de saturer etcd pendant le réchauffement de son cache.
Le HPA sait s’arrêter : scale-to-zero en bêta, activé par défaut
La fonctionnalité la plus rentable de 1.37 est discrète. Introduit dès la version 1.16, le scale-to-zero du HorizontalPodAutoscaler passe en Beta et — surtout — devient activé par défaut. Concrètement, pour les workloads pilotés par des métriques object ou external, un spec.minReplicas: 0 suffit à ce que le HPA réduise le nombre de réplicas à zéro quand la file est vide, puis les restaure quand la demande revient.
La limite est posée d’emblée : le passage à zéro fondé sur le CPU ou la mémoire n’est pas pris en charge, parce que ces métriques n’existent que lorsque des pods tournent. La cible est ailleurs — consommateurs de file d’attente, jobs par lots, workloads GPU — là où l’inactivité est mesurable par une métrique externe indépendante des pods.
Le mécanisme est propre. Tant que le HPA maintient un workload à zéro, il expose une condition ScaledToZero à True dans son statut. Le contrôleur s’en sert pour distinguer un workload qu’il a lui-même réduit à zéro — et qu’il remontera quand la métrique revient — d’un déploiement mis à zéro manuellement. Quand le workload repart, la condition repasse à False avec la raison NotScaledToZero.
Le manifeste tient en quelques lignes. Le point décisif est la combinaison de minReplicas: 0 avec une métrique externe indépendante des pods :
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: file-processor
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: file-processor
minReplicas: 0
maxReplicas: 10
metrics:
- type: External
external:
metric:
name: queue_depth
target:
type: AverageValue
averageValue: "1"Ici, le HPA interroge une métrique externe (queue_depth) qui vit dans le courtier de messages, pas dans les pods : elle reste mesurable même quand le déploiement est à zéro. Dès que la file dépasse un message en moyenne, le contrôleur remonte le déploiement ; quand elle retombe à zéro, il le referme. Pour un consommateur Kafka ou une file SQS qui ne tourne que par intermittence, l’économie est immédiate, sans rien changer à la logique métier.
La fin d’une anomalie de neuf ans : l’API metrics.k8s.io passe en stable
L’autre promotion marquante est celle de l’API metrics.k8s.io, qui accède enfin au statut Stable après près de neuf ans en bêta. C’est elle qui fournit la voie standard de récupération de l’usage CPU et mémoire des pods et des nœuds, et c’est elle qui alimente deux piliers du quotidien : la commande kubectl top et le HorizontalPodAutoscaler.
La graduation suit l’objectif assumé du projet de ne plus laisser d’API en Beta de façon permanente. Désormais qu’une version v1 existe, les prochaines releases migreront vers elle ; la v1beta1 reste utilisable pendant la transition, conformément à la politique de dépréciation, de sorte que l’adoption du Stable ne casse aucun workflow existant. Pour un SRE, la conséquence est mince mais réelle : une dépendance de moins susceptible de changer sous vos pieds lors d’un upgrade.
Le symbole importe autant que la technique. Une API restée neuf ans en bêta était devenue le rappel permanent que la stabilité annoncée des releases ne descendait pas jusqu’aux surfaces que les opérateurs touchent tous les jours. En la figeant, Kubernetes referme l’une de ses plus anciennes dettes d’API, et envoie le même signal que la sortie de KYAML : les outils du quotidien cessent d’être des préversions.
L’apiserver n’écrase plus etcd au démarrage
Le changement le plus structurant pour les grands clusters est silencieux. Kubernetes a achevé le travail sur l’initialisation résiliente du watch cache : le feature gate ResilientWatchCacheInitialization était passé Stable en v1.34, et la v1.37 verrouille le gate restant, WatchCacheInitializationPostStartHook, désormais actif en permanence.
Ce que cela change, c’est le comportement de l’apiserver au démarrage et pendant la reprise. Avant, le réchauffement du cache déclenchait un pic de requêtes list et watch contre etcd ; les requêtes s’empilaient pendant que le cache se remplissait. Désormais, l’apiserver délègue des requêtes bornées et rejette le surplus avec une réponse HTTP 429, au lieu de laisser la charge écraser etcd ou épuiser la capacité d’API Priority and Fairness.
La consigne pour les opérateurs est explicite : les clients — y compris les controllers et operators maison — doivent gérer proprement un 429 Too Many Requests, en respectant l’en-tête Retry-After et en implémentant un backoff exponentiel. C’est la condition pour que la protection de l’apiserver ne devienne pas une panne en cascade côté clients.
Le cas d’école est le redémarrage du plan de contrôle après une panne. Avant, le kube-apiserver qui revenait pouvait, en rejouant des milliers de list pendant que son cache se réchauffait, faire retomber etcd au moment même où le cluster cherchait à se stabiliser. Désormais, la reprise est bornée : l’apiserver remonte progressivement, et les clients bien élevés réessaient au lieu de marteler.
Les politiques d’admission survivent à une panne d’etcd
1.37 fait aussi progresser la configuration d’admission par manifeste, passée en Beta. Les webhooks d’admission et les politiques CEL peuvent désormais être chargés depuis des fichiers sur disque, via le champ staticManifestsDir de l’AdmissionConfiguration, au lieu de vivre uniquement dans l’API Kubernetes.
L’intérêt opérationnel est direct : les politiques ainsi chargées sont appliquées dès le démarrage de l’apiserver, continuent de fonctionner quand etcd est indisponible, et peuvent protéger les ressources d’admission basées sur l’API contre leur propre modification. C’est un pas vers des garde-fous qui ne dépendent plus de la disponibilité du datastore pour tenir.
Ce qu’il faut vérifier avant de migrer
Deux points pratiques dominent pour qui planifie l’upgrade. D’abord, containerd 2.0 est le minimum requis : Kubernetes 1.35 était la dernière release à supporter containerd 1.x, et la 1.37 retire les flags du kubelet liés à cette fin de vie. La migration du runtime doit être réglée avant la mise à niveau, pas après.
Ensuite, les nouveautés discrètes qui stabilisent le quotidien : KYAML passe en Stable (kubectl get -o kyaml est désormais stable), les fonctionnalités SELinuxMount et SELinuxChangePolicy passent en Stable, et le checkpoint/restore au niveau du pod entre en Alpha via de nouveaux RPC CRI (CheckpointPod, RestorePod), à condition que le runtime les implémente.
Verdict
Si vous exploitez des workloads événementiels — consommateurs de file, jobs par lots, tâches GPU — activez le scale-to-zero dès le passage en 1.37 : il est par défaut, et spec.minReplicas: 0 transforme directement de l’inactivité en économies, sans rien casser pour les métriques CPU/mémoire. Si vous gérez un cluster de taille réelle, la priorité est ailleurs : vérifiez que vos operators tolèrent les 429 avec un backoff exponentiel, car la protection d’etcd ne vaut que si vos clients ne la transforment pas en avalanche. Et dans tous les cas, réglez la migration vers containerd 2.0 avant l’upgrade — c’est le seul prérequis qui ne pardonne pas d’être traité après coup.