Un redémarrage de l’API server qui ralentit les contrôleurs, des GPU difficiles à mutualiser, des workers qui restent allumés sans travail : ces problèmes consomment du temps d’ingénierie bien au-delà du déploiement des applications.
Kubernetes 1.37, baptisé Garhwal et publié le 26 août 2026, apporte plusieurs évolutions qui méritent l’attention des équipes plateforme. Cette sélection se concentre sur leurs conséquences opérationnelles : récupération du control plane, allocation des accélérateurs, réduction des privilèges et adaptation à une demande intermittente. Calendrier officiel de Kubernetes 1.37
Notre lecture : une partie de la complexité des plateformes peut progressivement s’appuyer sur des mécanismes Kubernetes communs. Le travail d’intégration reste cependant décisif. Une fonctionnalité stable, une option beta et une expérimentation alpha ne justifient pas les mêmes engagements en production.
Un control plane qui récupère mieux après un redémarrage
L’API server conserve un watch cache pour servir les lectures et les abonnements aux changements. Lorsqu’il faut reconstruire ce cache, une accumulation de requêtes peut mettre etcd sous pression.
La version 1.37 stabilise WatchCacheInitializationPostStartHook, dernière étape du dispositif d’initialisation résiliente. Certaines requêtes coûteuses peuvent recevoir un HTTP 429 pendant la reconstruction, plutôt que surcharger etcd. Les clients doivent respecter Retry-After et espacer progressivement leurs tentatives.
Autre changement : ConcurrentWatchObjectDecode, toujours en beta, est désormais activé par défaut. Le décodage et les transformations s’effectuent en parallèle, tout en conservant l’ordre des événements. Le projet rapporte une réduction d’environ 40 % du temps d’initialisation sur 150 000 Pods, et d’environ 55 % avec RangeStream. Ce sont des résultats de benchmark upstream, pas une promesse applicable à chaque cluster.
La contrepartie concerne notamment les webhooks de conversion des CRD : ils peuvent recevoir davantage d’appels simultanés. Accélérer le cache suppose aussi qu’ils supportent cette concurrence. Annonce de Kubernetes 1.37
Pour une plateforme riche en opérateurs, nous privilégierions donc un test de récupération sous charge. Le bon résultat n’est pas seulement un API server revenu en ligne : c’est le retour des applications à leur fonctionnement attendu, sans emballement des nouvelles tentatives.
RangeStream : des lectures etcd moins gourmandes en mémoire
La taille d’une lecture dépend autant du poids des objets que de leur nombre. Une page contenant des objets volumineux peut provoquer un pic mémoire, même si le nombre de clés est limité.
Avec RangeStream, etcd transmet les résultats par morceaux et l’API server les traite progressivement. Cette approche réduit la nécessité de conserver de grandes réponses en mémoire lors du chargement du cache et des lectures directes concernées.
EtcdRangeStream passe en beta, activée par défaut, mais nécessite etcd 3.7 ou ultérieur. Avec un etcd plus ancien, l’API server conserve le chemin de lecture paginé : passer Kubernetes en 1.37 ne suffit donc pas à obtenir ce bénéfice.
Pour vérifier son utilisation, le projet indique ce compteur :
etcd_request_duration_seconds_count{operation="listStream"}
Une valeur non nulle confirme des lectures par streaming. Fonctionnement et prérequis de RangeStream
Sur une offre managée, cette vérification dépend des métriques et informations exposées par le fournisseur. Avant de prévoir un gain de capacité, il faut connaître la configuration effectivement opérée.
DRA : une adoption plus progressive pour les GPU et accélérateurs
Le support des extended resources par Dynamic Resource Allocation devient stable. Un driver DRA peut satisfaire une demande telle que example.com/gpu, associée à une DeviceClass, sans imposer un ResourceClaim explicite dans le workload. Cela facilite une migration du mécanisme d’allocation sans réécriture systématique des applications.
Les autres évolutions ont des maturités distinctes :
- Les device taints and tolerations deviennent stables pour gérer l’indisponibilité de périphériques.
- Les plages de capacité fractionnaire,
DRAFractionalCapacityRange, sont en beta. SchedulerPreQueueingHintsarrive en alpha pour cibler les Pods concernés par un événement DRA. Les premiers benchmarks annoncent un débit de scheduling approximativement doublé sur le scénario étudié ; cela ne décrit pas le scheduler entier.
Il faut donc évaluer chaque capacité séparément. Nouveautés DRA de Kubernetes 1.37
Pour une offre GPU, notre critère serait le service réellement rendu : quels workloads peuvent partager le matériel, avec quelle isolation, et que se passe-t-il lorsqu’un périphérique devient indisponible ? Une API d’allocation ne constitue pas, à elle seule, une garantie d’isolation matérielle ou de performance. Les réponses doivent venir des pilotes, du matériel et des essais.
Le mode rootless passe en beta, sans transformer les nœuds existants
KubeletInUserNamespace permet de faire fonctionner les composants du nœud dans un user namespace Linux, avec un utilisateur non-root sur l’hôte. Il passe en beta et sa feature gate est activée par défaut.
Cela ne convertit pas automatiquement les clusters existants en rootless. L’environnement approprié doit être préparé en dehors de Kubernetes.
Il faut aussi distinguer ce mécanisme de hostUsers: false, qui place les Pods dans des user namespaces. Les deux approches peuvent être combinées, notamment pour des environnements Kubernetes imbriqués. Les compatibilités CNI et CSI restent à examiner. Annonce du mode rootless en beta
Nous y voyons une piste pour les environnements de développement et les sandboxes d’agents : réduire les privilèges nécessaires à l’exécution d’un environnement autonome. Pour des locataires non fiables, la décision doit néanmoins porter sur toute la frontière d’isolation. Le partage du noyau demeure une différence essentielle avec une machine virtuelle ; l’étiquette rootless ne suffit pas à choisir l’architecture.
Le HPA peut descendre à zéro pour les charges intermittentes
Le passage à zéro de l’HorizontalPodAutoscaler atteint la beta, activée par défaut. Un HPA peut utiliser minReplicas: 0 avec des métriques Object ou External pour arrêter ses Pods au repos, puis les relancer lorsque la demande revient.
La consommation CPU ou mémoire ne suffit pas à ce scénario : sans Pod actif, elle ne fournit pas le signal nécessaire au réveil. Une profondeur de file d’attente, accessible indépendamment des workers, est un exemple de signal adapté. HPA et scale-to-zero dans Kubernetes 1.37
Prenons un traitement de documents utilisé quelques fois par jour. Notre recommandation serait de comparer le coût de maintien d’un worker au délai accepté pour traiter le premier document. Le passage à zéro peut être intéressant si le démarrage respecte ce délai et si la métrique reste disponible.
L’économie doit ensuite être mesurée au niveau facturé. Arrêter des Pods ne garantit pas la disparition du coût d’un nœud ou d’un GPU réservé. Ce point évite de confondre capacité libérée et dépense effectivement réduite.
Maintenance des nœuds : un vocabulaire commun, encore sans automatisation native
Kubernetes 1.37 introduit aussi des conditions de cycle de vie comme MaintenancePlanned. Un administrateur ou un contrôleur autorisé peut les publier pour rendre une maintenance visible.
La nuance est importante : la feature gate NodeLifecycleConditions est alpha, désactivée par défaut, et aucun composant cœur ne consomme encore ces conditions en 1.37. Les publier ne déclenche donc pas automatiquement un drain ou une migration de workloads. Leur intérêt immédiat est la lisibilité opérationnelle. Conditions de cycle de vie des nœuds
Notre ordre de validation avant une adoption
Nous proposons de séparer la qualification de la version et les expérimentations qui changent l’architecture de la plateforme.
| Priorité proposée | Expérimentation | Résultat à démontrer |
|---|---|---|
| 1 | Redémarrage contrôlé de l’API server sur un cluster de test représentatif | Reprise des contrôleurs, tentatives maîtrisées, délai de récupération acceptable |
| 2 | Vérification de la version etcd et des lectures RangeStream | Mécanisme réellement utilisé et pics mémoire mesurés |
| 3 | Passage à zéro d’un worker non critique | Réveil fiable et latence du premier traitement acceptable |
| 4 | DRA avec le pilote et le matériel retenus | Allocation correcte, comportement en panne et isolation vérifiée |
| 5 | Pool rootless dédié | Compatibilité réseau, stockage et exploitation démontrée |
Ces essais doivent compléter la lecture des notes de version et la vérification des compatibilités de votre distribution, de vos opérateurs et de vos extensions. Pour une procédure d’upgrade, le chemin dépendra aussi de la version de départ ; ce panorama ne remplace pas ce travail.
Le choix d’une distribution reste lui-même une décision d’exploitation, comme nous le développons dans notre comparatif Kubernetes. La disponibilité upstream ne fixe pas à elle seule votre calendrier de migration.
L’opportunité de Kubernetes 1.37 est de réexaminer quelques mécanismes coûteux à maintenir dans les plateformes : allocation spécialisée, gestion de l’inactivité, récupération et isolation. Nous commencerions par un problème mesurable, un périmètre limité et un critère de réussite explicite. C’est ainsi qu’une nouveauté devient un bénéfice d’exploitation.
