Kubernetes v1.37 (Garhwal) : les nouveautés à connaître

TL;DR

Kubernetes v1.37 ("Garhwal") apporte 67 améliorations : 16 en Stable, 23 en Beta, 27 en Alpha et 1 suppression. Les changements phares sont le redimensionnement in-place des conteneurs init et sidecar (GA), la tolérance configurable du HPA (GA), les node declared features (GA), le scale to zero pour le HorizontalPodAutoscaler (Beta), Memory QoS (Beta), les gestionnaires de ressources au niveau du Pod (Beta), le gang scheduling via la nouvelle API Workload (Beta) et le mode rootless du Kubelet (Beta). Côté Alpha, on trouve une API Eviction Request coopérative et le checkpoint/restore au niveau du Pod, ainsi que la poursuite des travaux sur la Dynamic Resource Allocation (DRA). Point d'attention : l'étiquetage des montages SELinux change par défaut dans cette version et peut casser des workloads existants sur les clusters où SELinux est activé.

Kubernetes v1.37, également baptisée "Garhwal", apporte un solide ensemble de changements pour les équipes qui s'intéressent à la gestion des ressources, à l'autoscaling et au scheduling. Cette version compte 67 améliorations : 16 passent en Stable (GA), 23 en Beta, 27 en Alpha, et 1 est une suppression. Le nom vient du Garhwal, une région himalayenne de l'Uttarakhand, en Inde. Le thème évoque des couches qui se connectent et se soutiennent mutuellement, des champs en terrasses aux torrents de montagne — une belle image pour une version qui continue de s'appuyer sur le travail des versions précédentes.

Voici quelques-unes des fonctionnalités de Kubernetes v1.37 qui nous enthousiasment le plus : le redimensionnement in-place des conteneurs init et sidecar, le scale to zero pour le HorizontalPodAutoscaler, Memory QoS et le gang scheduling natif via l'API Workload. Beaucoup d'entre elles rendent Kubernetes plus efficace pour bien utiliser les ressources, scaler en fonction de la demande réelle et placer des workloads étroitement couplés.

Voici les principaux changements de Kubernetes v1.37 :

Fonctionnalités Stable de Kubernetes v1.37

1. Redimensionnement in-place des Pods pour les conteneurs init et sidecar

Groupe : SIG Node | KEP : #1287

Le redimensionnement in-place des Pods est passé en Stable (GA) avec Kubernetes v1.35. Dans la v1.37, cette prise en charge s'étend aux conteneurs init et sidecar, et cette partie est désormais GA elle aussi.

Avant ce changement, vous pouviez redimensionner le CPU et la mémoire d'un conteneur applicatif en cours d'exécution sans redémarrage, mais les conteneurs init et sidecar restaient sur la touche. Un conteneur sidecar est un conteneur init avec restartPolicy: Always, il s'exécute donc pendant toute la vie du Pod. Si un sidecar avait besoin de plus de CPU ou de mémoire, votre seule véritable option était de recréer le Pod. Cela signifiait aussi une interruption pour l'application principale, alors que seul le sidecar avait besoin du changement.

Avec la v1.37, le feature gate InPlacePodVerticalScalingInitContainers est GA. Vous pouvez modifier les requests ou limits de CPU et de mémoire d'un conteneur sidecar en cours d'exécution, et le kubelet met à jour à chaud les paramètres cgroup du conteneur. Le Pod continue de tourner. Vous contrôlez le comportement par ressource avec resizePolicy : NotRequired applique le changement à chaud, et RestartContainer redémarre uniquement ce conteneur pour l'appliquer. La v1.37 ajoute aussi deux briques Alpha à la même fonctionnalité : le redimensionnement in-place des volumes emptyDir en mémoire (le gate InPlacePodVerticalScalingMemoryBackedVolumes) et la possibilité pour le scheduler de préempter des Pods de priorité inférieure afin de faire de la place pour un redimensionnement différé (le gate InPlacePodVerticalScalingSchedulerPreemption).

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  initContainers:
  - name: log-shipper        # sidecar
    image: log-shipper:1.0
    restartPolicy: Always
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
  containers:
  - name: app
    image: app:1.0
    # ...

Avec cette configuration, vous pouvez augmenter le CPU du sidecar sans aucun redémarrage. Augmenter sa mémoire ne redémarre que ce conteneur, jamais le Pod entier.

2. Tolérance configurable pour les HorizontalPodAutoscalers

Groupe : SIG Autoscaling | KEP : #4951

Dans Kubernetes v1.37, la tolérance configurable pour le HorizontalPodAutoscaler (HPA) est passée en disponibilité générale (GA).

Le HPA ajuste le nombre de réplicas de Pods en fonction de métriques comme le CPU ou la mémoire. Avant cette fonctionnalité, le HPA utilisait une tolérance fixe de 10 % pour tout le cluster. Il n'agissait pas tant que l'utilisation ne s'écartait pas de plus de 10 % de la cible. Cette valeur unique ne convenait pas à tous les workloads. Les services sensibles pouvaient réagir trop lentement, et pour la modifier, il fallait éditer un flag global du contrôleur qui touchait tous les HPA du cluster.

Avec la v1.37, le feature gate HPAConfigurableTolerance est GA. Vous pouvez définir la tolérance par HPA et par direction de scaling dans le champ behavior. Une tolérance serrée sur le scale up permet à un service critique de réagir aux petites hausses de charge. Une tolérance plus souple ailleurs garde les workloads plus calmes stables. Cette fonctionnalité était en Beta dans la v1.35 et constitue désormais le comportement standard.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      tolerance: 0.05

La tolérance est un ratio, pas un nombre de points de pourcentage. Avec 0.05 et une cible de 60 %, le HPA déclenche un scale up dès que l'utilisation CPU dépasse environ 63 % (60 % × 1,05). Il réagit ainsi plus tôt que ne le permettait l'ancienne tolérance fixe de 10 %.

3. Node Declared Features

Groupe : SIG Node | KEP : #5328

Dans Kubernetes v1.37, les node declared features sont passées en disponibilité générale (GA).

Avant cette fonctionnalité, Kubernetes supposait qu'un nœud pouvait prendre en charge n'importe quelle fonctionnalité supportée par le plan de contrôle, tant que les versions restaient dans le skew supporté. Ce n'est pas toujours vrai. Quand une nouvelle fonctionnalité était activée côté plan de contrôle, le scheduler pouvait tout de même placer un Pod qui l'utilisait sur un nœud plus ancien qui ne la prenait pas encore en charge. Le Pod échouait alors à l'exécution ou restait bloqué après le scheduling, alors que le placement semblait correct.

Avec la v1.37, le feature gate NodeDeclaredFeatures est GA. Chaque nœud publie désormais l'ensemble des fonctionnalités qu'il comprend dans un champ status.declaredFeatures de l'objet Node. Le scheduler et les vérifications d'admission s'en servent pour ne placer les Pods utilisant ces fonctionnalités que sur des nœuds qui les prennent en charge. Une défaillance à l'exécution devient ainsi une décision de scheduling claire, ce qui compte surtout pendant les mises à niveau, quand les versions des nœuds sont hétérogènes. Les node declared features étaient en Alpha dans la v1.35.

Fonctionnalités Beta de Kubernetes v1.37

4. Scale to zero pour les HorizontalPodAutoscalers

Groupe : SIG Autoscaling | KEP : #2021

Dans Kubernetes v1.37, le scale to zero pour le HorizontalPodAutoscaler passe en Beta et est activé par défaut.

Avant cette fonctionnalité, un HPA ne pouvait pas descendre un workload à zéro réplica. Le minimum était de un. Pour un service qui n'a du travail que par intermittence, comme un consommateur de file d'attente ou un worker batch, cela signifiait payer pour garder au moins un Pod en fonctionnement même quand il n'y avait rien à faire.

Avec la v1.37, vous pouvez définir spec.minReplicas: 0 sur un HPA et le laisser descendre le workload à zéro lorsqu'il est inactif, puis le faire remonter quand la demande revient. Cela fonctionne pour les workloads pilotés par des métriques Object ou External, comme la longueur d'une file d'attente. Cela ne fonctionne pas avec les métriques CPU ou mémoire, car celles-ci proviennent des Pods en cours d'exécution — et à zéro, il n'y en a aucun. Cela peut réduire les coûts des consommateurs de files d'attente, des jobs batch et des workloads GPU qui restent inactifs entre deux exécutions. Tant que le HPA maintient un workload à zéro, il enregistre une condition ScaledToZero à True, ce qui permet de distinguer un workload qu'il a mis à zéro d'un workload arrêté manuellement. Une fois la remontée effectuée, la condition passe à False avec la raison NotScaledToZero.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages
      target:
        type: AverageValue
        averageValue: "30"

Avec cette configuration, le workload tombe à zéro Pod quand la file est vide, et le HPA le fait remonter dès que des messages arrivent.

5. Memory QoS

Groupe : SIG Node | KEP : #2570

Dans Kubernetes v1.37, Memory QoS passe en Beta.

Avant cette fonctionnalité, le kubelet fixait une limite mémoire stricte pour un conteneur (cgroup memory.max), mais ne donnait aucun signal plus souple au noyau. Un conteneur pouvait consommer de la mémoire jusqu'à sa limite puis se faire tuer par l'OOM killer sans grand préavis. Il n'existait pas non plus de protection mémoire liée à la request d'un conteneur : sous pression mémoire, le noyau pouvait récupérer des pages d'un conteneur qui restait pourtant en deçà de sa request.

Avec la v1.37, le feature gate MemoryQoS est en Beta. Il utilise les contrôles mémoire de cgroup v2 pour donner de meilleurs signaux au noyau. Le kubelet définit memory.min à partir de la request mémoire d'un conteneur, ce qui protège cette quantité de mémoire de la récupération. Lorsque vous définissez memoryThrottlingFactor dans la configuration du kubelet, celui-ci définit aussi memory.high comme seuil de throttling sous la limite. Le noyau ralentit alors le conteneur et récupère des pages avant que celui-ci n'atteigne la limite stricte et ne soit tué par l'OOM killer. Par défaut, memoryThrottlingFactor n'est pas défini et memory.high reste désactivé tant que vous ne le configurez pas. cgroup v2 est requis, ce qui est de toute façon le seul mode supporté depuis la v1.35.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9

Avec ce réglage, le kubelet définit memory.high pour les conteneurs en dessous de leur limite mémoire, avec le facteur 0.9. Le noyau récupère de la mémoire et ralentit le conteneur avant qu'il n'atteigne la limite stricte, ce qui rend les OOM kills moins probables sous pression.

6. Gestionnaires de ressources au niveau du Pod

Groupe : SIG Node | KEP : #5526

Dans Kubernetes v1.37, les gestionnaires de ressources au niveau du Pod passent en Beta.

Kubernetes v1.34 avait ajouté les ressources au niveau du Pod (KEP #2837), qui permettent de définir les requests et limits de CPU et de mémoire pour l'ensemble du Pod, et non plus seulement par conteneur. Mais les gestionnaires de ressources du kubelet ne comprenaient pas encore ces valeurs. Avant cette fonctionnalité, le CPU Manager, le Memory Manager et le Topology Manager ne regardaient que les requests par conteneur. Un Pod qui définissait ses ressources au niveau du Pod pouvait passer à côté de l'épinglage exclusif de CPU ou de l'alignement NUMA.

Avec la v1.37, le feature gate PodLevelResourceManagers est en Beta. Il est désactivé par défaut dans la v1.37 : il avait été activé, puis désactivé en fin de cycle après la découverte de problèmes critiques par l'équipe ; vous devez donc l'activer vous-même si vous en avez besoin. Une fois activé, le CPU Manager (politique static), le Memory Manager et le Topology Manager tiennent compte des ressources au niveau du Pod lorsqu'ils attribuent les CPU, la mémoire et la localité matérielle. Cela profite aux workloads exigeants et sensibles à la latence qui définissent leurs ressources au niveau du Pod, afin qu'ils bénéficient quand même de cœurs exclusifs et d'une mémoire alignée NUMA.

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  resources:              # pod-level resources
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "2"
      memory: "4Gi"
  containers:
  - name: app
    image: app:1.0
    # containers can set their own resources, or use the pod-level ones

Avec cette configuration, le Pod est Guaranteed au niveau du Pod, et les gestionnaires du kubelet peuvent lui épingler des CPU entiers et aligner la mémoire, même lorsque le conteneur ne définit pas ses propres requests.

7. Gang scheduling avec l'API Workload

Groupe : SIG Scheduling | KEP : #4671

Dans Kubernetes v1.37, le gang scheduling natif via l'API Workload passe en Beta.

Avant cette fonctionnalité, Kubernetes planifiait les Pods un par un. Pour un job étroitement couplé, comme un entraînement distribué où tous les workers doivent démarrer ensemble, cela provoquait un scheduling partiel. Certains Pods démarraient tandis que d'autres restaient en attente, monopolisant des ressources sans rien accomplir. Les équipes devaient ajouter un scheduler externe pour obtenir un comportement tout-ou-rien (gang). Kubernetes v1.35 avait introduit le gang scheduling natif en Alpha via une nouvelle API Workload.

Avec la v1.37, l'API devient scheduling.k8s.io/v1beta1. Vous l'activez avec le feature gate GenericWorkload. Dans la v1.37, les anciens gates GangScheduling et WorkloadAwarePreemption ont été fusionnés dans GenericWorkload : un seul gate couvre désormais à la fois le gang scheduling et la workload-aware preemption. Le modèle comporte trois parties. Un Workload contient un ou plusieurs podGroupTemplates, chacun avec une politique de scheduling comme gang et un minCount. Un PodGroup est créé à partir d'un template et suit un groupe en cours d'exécution. Chaque Pod pointe vers son groupe avec schedulingGroup.podGroupName. Le scheduler retient les Pods jusqu'à ce qu'au moins minCount d'entre eux puissent s'exécuter ensemble, puis les place. S'il ne peut pas atteindre minCount, aucun n'est lié à un nœud, et les Pods attendent qu'il y ait de la place. Le champ minCount reste modifiable après création, ce qui aide les jobs élastiques à s'adapter à la hausse comme à la baisse.

Le Workload définit le template :

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
  name: training-job
spec:
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        minCount: 4

Un PodGroup est créé à partir de ce template :

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: training-job-workers-0
spec:
  workloadRef:
    workloadName: training-job
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 4

Chaque Pod rejoint le groupe par son nom :

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  schedulingGroup:
    podGroupName: training-job-workers-0
  containers:
  - name: trainer
    image: trainer:1.0
    # ...

Avec cette configuration, Kubernetes ne planifie les workers que lorsqu'au moins quatre d'entre eux peuvent s'exécuter ensemble. Si le cluster ne peut pas en accueillir quatre, aucun ne démarre.

8. Kubelet dans un user namespace (mode rootless)

Groupe : SIG Node | KEP : #2033

Dans Kubernetes v1.37, l'exécution du kubelet dans un user namespace, aussi appelée mode rootless, passe en Beta.

Avant cette fonctionnalité, les composants du nœud comme le kubelet s'exécutaient en root sur l'hôte. Si le kubelet était compromis, un attaquant pouvait obtenir les droits root sur l'ensemble du nœud.

Avec la v1.37, le feature gate KubeletInUserNamespace est en Beta. Il exécute le kubelet et les autres composants du nœud dans un user namespace Linux. Ils apparaissent toujours comme root à l'intérieur du namespace, mais sur l'hôte ils correspondent à un utilisateur non privilégié. Cela ajoute une couche d'isolation sans changer votre usage quotidien du kubelet. Cette fonctionnalité est en chantier depuis la v1.22 : atteindre la Beta est donc une étape majeure.

Fonctionnalités Alpha de Kubernetes v1.37

9. API Eviction Request

Groupe : SIG Node | KEP : #4563

Avant cette fonctionnalité, drainer un nœud pour maintenance était une action côté client. Un outil comme kubectl drain évinçait les Pods un par un en respectant les PodDisruptionBudgets, mais l'intention résidait dans le client, pas dans le cluster. Les contrôleurs et les applications ne pouvaient pas voir qu'un nœud était en cours de drain, coordonner une passation sûre ni participer à la décision. Une application stateful pouvait être évincée au mauvais moment parce que rien ne l'avertissait de la maintenance à venir.

Avec la v1.37, une fonctionnalité Alpha ajoute l'API EvictionRequest afin que l'éviction puisse être coopérative plutôt qu'une suppression brutale. Un demandeur crée un EvictionRequest pour un Pod, et les composants enregistrés via le nouveau champ spec.evictionResponders du Pod gèrent une passation en douceur. La v1.37 ajoute aussi de nouvelles conditions de cycle de vie des nœuds (MaintenancePlanned, MaintenanceInProgress, GracefulNodeShutdownInProgress, DrainInProgress et Drained) que les contrôleurs peuvent surveiller pour savoir où en est un nœud dans le flux de maintenance. Ensemble, ces briques permettent à une application ou à un opérateur de drainer selon ses propres conditions, par exemple en déplaçant un leader ou en vidant son état avant la disparition de son Pod.

10. Checkpoint et restore au niveau du Pod

Groupe : SIG Node | KEP : #5823

Avant cette fonctionnalité, Kubernetes pouvait effectuer un checkpoint d'un seul conteneur (KEP #2008), principalement à des fins d'analyse forensique. Vous pouviez capturer l'état d'un conteneur, mais pas de tout un Pod d'un coup : un Pod multi-conteneurs ne pouvait pas être capturé comme une seule unité.

Avec la v1.37, une fonctionnalité Alpha ajoute le checkpoint et le restore au niveau du Pod. Elle étend la Container Runtime Interface (CRI) avec les appels CheckpointPod et RestorePod, afin que le kubelet et un runtime compatible puissent capturer ensemble tous les conteneurs d'un Pod, puis les restaurer. C'est utile dès aujourd'hui pour le travail forensique, et cela pose les bases d'usages futurs comme le déplacement d'un Pod en cours d'exécution entre nœuds. La fonctionnalité nécessite un runtime de conteneurs qui prend en charge les nouveaux appels CRI.