Kubernetes 1.37 : nouvelles fonctionnalités, changements bêta et stables

Kubernetes 1.37 : les fonctionnalités stables (GA)

1. L'API Metrics passe en stable

Groupe de fonctionnalités : SIG Instrumentation | KEP : KEP-5207

L'API metrics.k8s.io est en bêta depuis des années. C'est elle qui alimente kubectl top ainsi que les métriques CPU et mémoire du Horizontal Pod Autoscaler. Avec la v1.37, elle passe enfin en version stable.

Aucun changement fonctionnel ici. Les versions v1 et v1beta1 continuent de fonctionner, vous n'avez donc rien à modifier pour l'instant. Mais si vous développez des outils qui s'appuient sur cette API, vous pouvez désormais utiliser la v1 en toute confiance : elle est stable et n'évoluera pas de manière inattendue.

2. Ressources au niveau du pod

Jusqu'ici, il fallait définir des requests et limits de ressources pour chaque conteneur d'un pod, même lorsque les conteneurs étaient conçus pour fonctionner ensemble.

Les ressources au niveau du pod permettent de définir les requests/limits de CPU, de mémoire et de hugepages à l'échelle du pod, à la place (ou en complément) du niveau conteneur.

spec:
  resources:
    requests:
      cpu: "1"
      memory: "512Mi"
    limits:
      cpu: "2"
      memory: "1Gi"
  containers:
  - name: app
    image: my-app
  - name: sidecar
    image: my-sidecar

Tous les conteneurs du pod peuvent alors partager le même pool de ressources au lieu de disposer chacun d'une allocation fixe. Cela réduit le gaspillage de ressources et convient mieux aux workloads multi-conteneurs à la consommation irrégulière.

3. DRA : taints et tolerations pour les devices

Groupe de fonctionnalités : SIG Scheduling | KEP : KEP-5055

Cette fonctionnalité transpose le modèle des taints de nœuds à la Dynamic Resource Allocation (DRA). Les drivers DRA, ou une DeviceTaintRule que vous rédigez vous-même, peuvent appliquer un taint à un device précis (par exemple un GPU en surchauffe ou en cours de drainage pour maintenance).

Un taint NoSchedule empêche les nouveaux pods d'utiliser ce device, tandis qu'un taint NoExecute évince les pods qui l'utilisent déjà. Si un workload doit malgré tout utiliser le device, il peut ajouter une toleration correspondante à son ResourceClaim.

Vous pouvez ainsi isoler un seul GPU ou une seule carte réseau (NIC) au lieu de mettre le nœud entier en cordon.

4. Tolérance configurable pour le HPA

Groupe de fonctionnalités : SIG Autoscaling | KEP : KEP-4951

Le Horizontal Pod Autoscaler (HPA) a toujours appliqué une tolérance fixe de 10 % à l'échelle du cluster afin d'éviter de déclencher un scaling à la moindre variation de métrique. Mais ces 10 % n'ont pas le même sens pour tous les workloads : une variation de 10 % sur un workload de 500 pods n'a rien à voir avec la même variation sur 5 pods.

Avec cette fonctionnalité désormais stable, vous pouvez définir une tolérance personnalisée pour chaque HPA, avec des valeurs distinctes pour le scale-up et le scale-down via spec.behavior.scaleUp et spec.behavior.scaleDown. Chaque workload peut ainsi scaler de manière plus adaptée sans toucher à la valeur par défaut du cluster.

5. Certificats de pod

Groupe de fonctionnalités : SIG Auth | KEP : KEP-4317

Les pods disposent désormais d'un moyen natif d'obtenir des certificats X.509 de courte durée sans passer par des bearer tokens. Une nouvelle API PodCertificateRequest gère l'émission, et un volume projeté PodCertificate permet au kubelet de transmettre directement la clé et le certificat au pod, avec rotation automatique.

Cela simplifie la mise en place native du mTLS (y compris avec des outils tiers comme HashiCorp Vault), sans la tuyauterie de sidecars ou de webhooks qu'utilisent aujourd'hui de nombreux service meshes.

6. Sortie KYAML pour kubectl

Groupe de fonctionnalités : SIG CLI | KEP : KEP-5295

KYAML est un sous-ensemble de YAML plus strict, pensé pour Kubernetes : accolades pour les maps, crochets pour les listes, guillemets doubles pour les chaînes. Il autorise toujours les commentaires et les virgules finales, mais élimine les pièges classiques de YAML, comme l'interprétation silencieuse en booléen false (le fameux "problème norvégien").

C'est désormais une option de sortie stable de kubectl : vous pouvez générer des manifestes dans ce format sans craindre qu'une coercition de type accidentelle ne casse votre configuration.

7. Accélération du changement récursif des labels SELinux (SELinuxMount)

Groupe de fonctionnalités : SIG Storage | KEP : KEP-1710

Sur les nœuds avec SELinux activé, Kubernetes ré-étiquetait jusqu'ici chaque fichier d'un volume un par un avant qu'un pod puisse démarrer. Sur un volume contenant des millions de fichiers, cette seule étape pouvait prendre plusieurs minutes.

SELinuxMount passe en GA et est activé par défaut dans la v1.37. Au lieu de ré-étiqueter fichier par fichier, les volumes sont montés avec -o context=<label> : tout le volume reçoit le bon label en une seule opération de montage. Ce comportement ne s'applique que si le driver CSI du volume l'active via CSIDriver.spec.seLinuxMount: true.

Point important à retenir : un montage ne peut porter qu'un seul contexte SELinux. Si des pods avec des labels SELinux différents partagent aujourd'hui le même volume sur le même nœud (ce qui fonctionnait très bien avec l'ancien ré-étiquetage récursif), ces pods risquent désormais de ne plus démarrer. Si vous avez besoin de l'ancien comportement pour un workload précis, définissez seLinuxChangePolicy: Recursive dans la spec du pod. Les clusters sans SELinux ne verront aucun changement.

Les fonctionnalités bêta de Kubernetes 1.37

8. Kubelet dans un user namespace (mode rootless)

Groupe de fonctionnalités : SIG Node | KEP : KEP-2033

Les composants de nœud comme le kubelet s'exécutent normalement en root sur l'hôte. Si le kubelet est compromis, un attaquant pourrait obtenir un accès root au nœud.

Kubelet in UserNS exécute le kubelet dans un user namespace Linux. Il semble toujours s'exécuter en root à l'intérieur du namespace, mais sur l'hôte réel, il est mappé sur un utilisateur non privilégié. Cette fonctionnalité passe en bêta dans Kubernetes v1.37 et ajoute une couche d'isolation supplémentaire sans changer votre utilisation quotidienne du kubelet.

9. HPA : scaling vers/depuis zéro pour les métriques Object et External

Groupe de fonctionnalités : SIG Autoscaling | KEP : KEP-2021

Le Horizontal Pod Autoscaler (HPA) sait depuis un certain temps ramener un workload à zéro réplique à partir de métriques object ou external. Mais il n'existait aucun moyen simple de savoir si c'était le HPA qui avait ramené le workload à zéro ou si quelqu'un l'avait fait par un autre biais.

Kubernetes v1.37 ajoute une condition de statut ScaledToZero à l'objet HPA, qui lève cette ambiguïté. C'est particulièrement utile pour les workloads événementiels, par exemple ceux basés sur la profondeur d'une file d'attente ou des déclencheurs de type KEDA, qui descendent à zéro en période d'inactivité et remontent dès qu'un nouveau travail arrive.

10. Sérialiseur CBOR

Groupe de fonctionnalités : SIG API Machinery | KEP : KEP-4222

Les ressources Kubernetes intégrées utilisent Protobuf pour garder des appels d'API rapides, mais les CRD ne peuvent pas facilement l'utiliser, car Protobuf exige une génération de code à la compilation. CBOR est un format binaire qui n'a pas cette contrainte, et les premiers benchmarks montrent un encodage jusqu'à 8 fois plus rapide et un décodage 2 fois plus rapide pour les ressources personnalisées par rapport à JSON. Les clients le négocient automatiquement et retombent sur JSON face aux serveurs d'API plus anciens : le déploiement se fait donc en toute sécurité.

Les fonctionnalités alpha de Kubernetes 1.37

Ces fonctionnalités sont en alpha : pas prêtes pour la production, mais elles méritent d'être testées dans un cluster de staging.

11. Volume Health Monitor

Groupe de fonctionnalités : SIG Storage | KEP : KEP-1432

Aujourd'hui, si un volume CSI rencontre un problème au niveau du stockage, vous ne le découvrez généralement qu'à travers un montage en échec ou un blocage d'E/S ; il n'existe aucun signal structuré exploitable. Cette fonctionnalité introduit quatre nouveaux RPC CSI pour que les drivers puissent signaler la santé des volumes d'une manière exploitable par les contrôleurs. Côté contrôleur, ControllerListVolumeHealth liste les volumes en mauvaise santé et ControllerGetVolumeHealth en vérifie un en particulier ; un moniteur de santé côté contrôleur interroge ces RPC et écrit le résultat dans PersistentVolumeClaim.status.healthStatus. Côté nœud, le kubelet appelle NodeGetVolumeHealth pour les volumes individuels (consigné dans Pod.status.volumeHealth) et NodeGetStorageHealth pour la santé des drivers du nœud. Les contrôleurs de remédiation disposent ainsi d'une information lisible par machine, au lieu de devoir recouper à la main les dashboards des fournisseurs.

12. ulimits par conteneur

Groupe de fonctionnalités : SIG Node | KEP : KEP-5758

Certaines applications, comme les bases de données ou les applications à forte concurrence, ont besoin de limites POSIX plus élevées (nombre maximal de fichiers ouverts ou de processus, par exemple) que celles fournies par défaut par le runtime de conteneurs. Jusqu'à présent, les options habituelles étaient des scripts d'entrypoint personnalisés ou la modification de la configuration de l'hôte.

Kubernetes v1.37 ajoute un champ ulimits à Container.SecurityContext. Le kubelet transmet ces limites au runtime de conteneurs. Cette fonctionnalité ne fonctionne pour l'instant qu'avec le profil Privileged des Pod Security Standards, et Kubernetes vérifie la prise en charge du nœud avant de planifier le pod, afin qu'il ne s'exécute pas sur un nœud incapable d'appliquer les limites requises.

13. DRA : attributs dérivés

Groupe de fonctionnalités : SIG Scheduling | KEP : KEP-6080

DRA sait déjà faire correspondre des devices sur des attributs partagés, mais seulement si les différents fabricants de matériel utilisent le même nom d'attribut, ce qui est rarement le cas. Imaginons que vous vouliez un GPU et une carte réseau rapide sur le même nœud NUMA : le scheduler a besoin de noms et de valeurs d'attributs identiques, mais chaque fabricant décrit la topologie à sa manière.

Les attributs dérivés vous permettent d'écrire une expression CEL dans votre requête de device pour construire un attribut virtuel à partir de ce que le driver expose déjà. Vous obtenez ainsi une clé commune, comme un identifiant de nœud NUMA, sur laquelle le scheduler peut effectuer la correspondance. Vous pouvez donc associer GPU et cartes réseau sur le même nœud NUMA sans attendre que tous les fabricants s'accordent sur une convention de nommage.

Cette fonctionnalité est en alpha et l'API évolue encore : testez-la dans un cluster de staging et vérifiez les champs exacts dans le KEP avant de l'utiliser.