Les gestionnaires de ressources au niveau du pod passent en bêta dans Kubernetes 1.37

26 août 2026. Kubernetes 1.37 est publié. 15 septembre. L’équipe SIG Node documente le passage en bêta des Pod-Level Resource Managers. La nouveauté reste désactivée par défaut, derrière une feature gate. Pourquoi c’est important : jusqu’ici, obtenir des cœurs CPU ou de la mémoire exclusifs et alignés NUMA forçait un choix binaire — réserver des ressources dédiées à chaque conteneur du pod, ou renoncer à l’alignement. La bêta lève ce blocage pour les workloads qui mélangent un conteneur principal critique et des sidecars légers.

Le choix impossible d’avant : tout ou rien sur les cœurs exclusifs

Le problème que résout la fonctionnalité est aussi simple à décrire qu’il était coûteux à contourner. Pour un workload latency-critical — une base de données en mémoire, un plan de contrôle de télécom, un proxy de données — l’alignement des cœurs exclusifs et de la mémoire locale NUMA est une condition de performance, pas un confort. Un processus qui voit son thread migrer entre des cœurs de sockets différents, ou qui accède à de la mémoire distante, subit des latences qui se mesurent en dizaines de microsecondes et se paient en percentiles de queue.

L’ancien modèle imposait une discipline stricte : pour bénéficier de l’allocation exclusive du CPU Manager et du Topology Manager, il fallait déclarer des requêtes de ressources entières sur tous les conteneurs du pod, du conteneur d’application au sidecar de logging. Résultat : un sidecar qui n’a besoin que d’une fraction de cœur se voyait réserver un cœur physique entier, gaspillé. L’alternative — laisser le sidecar en qualité Burstable — faisait perdre l’alignement NUMA au pod entier. Entre gaspillage de capacité et dégradation de latence, les équipes plateforme choisissaient souvent le moindre mal, et documentaient l’exception.

Ce que la bêta change : l’allocation hybride

La fonctionnalité Pod-Level Resource Managers, introduite en alpha dans Kubernetes 1.36, s’appuie sur les Pod-Level Resources stabilisés en 1.34 pour équiper les trois gestionnaires de ressources du kubelet — Topology Manager, CPU Manager et Memory Manager — à lire directement les déclarations .spec.resources au niveau du pod plutôt que du conteneur.

Le bénéfice concret est un modèle d’allocation hybride. Le kubelet peut réserver des cœurs NUMA exclusifs au conteneur principal de l’application, tout en plaçant les sidecars non-Guaranteed dans un pool partagé isolé du pod. Le conteneur principal obtient des cœurs non throttlés et NUMA-locaux ; les sidecars bénéficient d’un alignement NUMA local et d’une protection contre les interférences des autres pods, sans consommer de cœur physique dédié. C’est la fin du choix binaire : on ne sacrifie plus la latence du workload critique pour épargner quelques cœurs aux sidecars.

La graduation en bêta apporte aussi un changement d’API. Le service gRPC PodResourcesLister (v1) expose désormais des champs cpu_ids et memory de premier niveau sur les réponses PodResources. Les outils de monitoring et les device plugins peuvent interroger les affectations exclusives au niveau du pod sans double-compter les allocations des conteneurs — un détail qui compte quand un agent d’observabilité doit rendre compte de la topologie réelle des allocations.

Comment l’activer

La fonctionnalité est désactivée par défaut en 1.37 : il faut l’activer explicitement via la feature gate PodLevelResourceManagers sur les composants concernés du cluster. C’est le comportement attendu d’une bêta — la porte d’entrée est volontairement manuelle, pour que les équipes valident le comportement sur un périmètre restreint avant de généraliser.

# Exemple : activation de la feature gate sur le kubelet (kubeadm)
# À ajouter au fichier de configuration du kubelet, puis redémarrer le service.
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  PodLevelResourceManagers: true

Une fois la gate activée, le kubelet lit les déclarations .spec.resources du pod et les transmet aux gestionnaires. La documentation officielle fournit un tutoriel complet de configuration — de la déclaration des ressources au niveau du pod jusqu’à la vérification de l’allocation — ainsi qu’une tâche dédiée à l’assignation des ressources CPU et mémoire au niveau du pod. Le retour d’expérience est attendu sur le canal #sig-node de Slack et sur la liste de diffusion du groupe, preuve que la graduation vers GA dépend encore des remontées de terrain.

Verdict

Pod-Level Resource Managers en bêta est un de ces changements discrets qui corrigent une injustice structurelle : on ne devrait jamais avoir à choisir entre la latence d’un workload critique et le gaspillage de cœurs physiques sur des sidecars. Si vous opérez des workloads latency-critical avec des sidecars — bases de données, plans de contrôle, nœuds de données — activez la feature gate sur un cluster de test et mesurez l’effet sur vos percentiles avant de généraliser ; le gain se lit dans la queue de latence, pas dans la moyenne. Si vous maintenez des agents de monitoring ou des device plugins, préparez la lecture des nouveaux champs cpu_ids et memory du service PodResourcesLister : c’est la donnée qui vous dira enfin qui possède quel cœur, sans double comptage. Si vous êtes en retard de versions, rappelez-vous que cette bêta s’appuie sur des briques stabilisées en 1.34 — le chemin de mise à niveau est un prérequis, pas une option.

Références

• Kubernetes Blog — Kubernetes v1.37: Pod-Level Resource Managers graduated to Beta, 15 septembre 2026
• Kubernetes Documentation — Pod-level resource managers
• Kubernetes Blog — Kubernetes v1.34: Pod-Level Resources, 22 septembre 2025
• Kubernetes Blog — Kubernetes v1.36: Pod-Level Resource Managers (Alpha), 1er mai 2026
• ETTAYEB — Memory QoS passe en bêta et devient actif par défaut dans Kubernetes 1.37