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

Kubernetes 1.37 : 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 était en bêta depuis des années. C'est l'API derrière kubectl top et les métriques CPU et mémoire du Horizontal Pod Autoscaler. Avec la v1.37, elle passe enfin en stable.

Aucun changement fonctionnel ici : 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 v1 en toute confiance : elle est stable et n'évoluera pas de façon inattendue.

2. Ressources au niveau du pod

Jusqu'ici, vous deviez 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 vous permettent de définir des requests/limits CPU, mémoire et hugepages au niveau du pod, en remplacement (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 avec des pics d'utilisation.

3. DRA : taints et tolerations pour les devices

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

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

Une taint NoSchedule empêche les nouveaux pods d'utiliser ce device, tandis qu'une 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 dans son ResourceClaim.

Vous pouvez ainsi isoler un seul GPU ou une seule NIC au lieu de mettre tout le nœud 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 utilisé une tolérance fixe de 10 % à l'échelle du cluster pour é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 est très différente d'une variation sur un workload de 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 pour les pods

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 la clé et le certificat directement 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, façon 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 du YAML, comme le parsing silencieux en booléen false (le fameux problème de la Norvège).

C'est désormais une option de sortie stable pour 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 de labels SELinux (SELinuxMount)

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

Sur les nœuds avec SELinux activé, Kubernetes relabellisait auparavant 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 d'un relabelling 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.

Un point important à retenir : un montage ne peut porter qu'un seul contexte SELinux. Si vous avez actuellement des pods avec des labels SELinux différents qui partagent le même volume sur le même nœud (ce qui fonctionnait sans problème avec l'ancien relabelling récursif), ces pods risquent désormais de ne plus démarrer. Si vous avez besoin de l'ancien comportement pour un workload spécifique, définissez seLinuxChangePolicy: Recursive dans la spec du pod. Les clusters sans SELinux ne voient aucun changement.

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 rien 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 réduire un workload à zéro réplique à partir de métriques object ou external. Mais il n'existait pas de moyen simple de savoir si c'était le HPA qui avait ramené un 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 qui s'appuient 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 que du travail arrive.

10. Sérialiseur CBOR

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

Les ressources Kubernetes natives utilisent Protobuf pour garder des appels d'API rapides, mais les CRD ne peuvent pas facilement utiliser Protobuf, qui nécessite 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é.

Fonctionnalités alpha de Kubernetes 1.37

Ces fonctionnalités sont en alpha : pas prêtes pour la production, mais intéressantes à tester 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 échec de montage ou un blocage d'I/O ; il n'existe aucun signal structuré exploitable. Cette fonctionnalité introduit quatre nouvelles RPC CSI pour que les drivers puissent remonter l'état de 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 vérifie un volume spécifique ; 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 (enregistré dans Pod.status.volumeHealth) et NodeGetStorageHealth pour l'état des drivers de ce nœud. Les contrôleurs de remédiation disposent ainsi d'informations lisibles par machine, au lieu de devoir croiser manuellement 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 par le 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 fournisseurs de matériel utilisent le même nom d'attribut, ce qui est rarement le cas. Imaginons que vous vouliez un GPU et une NIC rapide sur le même nœud NUMA : le scheduler a besoin de noms et de valeurs d'attributs correspondants, mais chaque fournisseur 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 ID de nœud NUMA, sur laquelle le scheduler peut s'appuyer. Vous pouvez donc associer GPU et NIC sur le même nœud NUMA sans attendre que tous les fournisseurs 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 le KEP pour connaître les champs exacts avant de l'utiliser.