veilletech.fr
15 sept. Feed du jour
#09 DEVOPS Article

Kubernetes 1.37 coupe le throttling mémoire

Une fonctionnalité activée par défaut qui n'écrit rien par défaut, ça se relit deux fois.

Memory QoS passe en bêta dans Kubernetes v1.37 et la feature gate est active sur tous les kubelets, mais le défaut de memoryThrottlingFactor passe de 0.9 à null : sans configuration explicite, le kubelet n'écrit plus memory.high, memory.min ni memory.low. Pour un cluster qui n'utilisait pas la fonctionnalité, la montée de version ne change rien. Pour un cluster qui l'avait activée en alpha sans inscrire le facteur dans sa configuration, le throttling s'arrête sans avertissement.

2 min de lectureavancévidéo 1:15
Partager
Sommaire4 sections
  1. Ce qui se passe
  2. Pourquoi ce choix, et où est le piège
  3. Comment configurer
  4. À retenir

Ce qui se passe

Memory QoS passe en bêta dans Kubernetes v1.37 et la feature gate MemoryQoS est activée par défaut sur tous les kubelets de cette version. La fonctionnalité, introduite en alpha dès la v1.22 et étendue en v1.36 avec la réservation par paliers, utilise le contrôleur mémoire de cgroup v2 sur les nœuds Linux pour mieux guider le noyau : memory.high freine un conteneur avant l'OOM, memory.min et memory.low lui réservent de la mémoire.

Mais l'annonce cache un second changement, plus important en pratique : la valeur par défaut de memoryThrottlingFactor passe de 0.9 à null, et memoryReservationPolicy reste à None. Autrement dit, activer la gate n'écrit rien dans les cgroups tant que rien n'est demandé explicitement.

Pourquoi ce choix, et où est le piège

Le raisonnement des mainteneurs est défendable : puisque la gate devient active partout, un memory.high automatique freinerait des charges qui tournaient jusqu'ici sans contrainte. Mettre le défaut à null garantit qu'une montée en v1.37 ne change pas le comportement d'exécution d'un cluster existant.

La conséquence est asymétrique, et c'est là qu'il faut regarder :

Votre situation avant la 1.37 Après la montée de version
Vous n'utilisiez pas Memory QoS rien ne change, objectif atteint
memoryThrottlingFactor inscrit explicitement dans le fichier de configuration la valeur est préservée, le throttling continue
Feature gate activée en alpha sans inscrire le facteur le throttling s'arrête en silence

Rien ne signale ce troisième cas. Le kubelet cesse simplement d'écrire memory.high, et la protection sur laquelle vous comptiez disparaît sans message.

Comment configurer

Pour retrouver le comportement de l'alpha :

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

Pour y ajouter la réservation par paliers via memory.min et memory.low :

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

Les deux réglages sont indépendants : memoryReservationPolicy: TieredReservation seul active la réservation sans aucun throttling.

Pour désactiver complètement la fonctionnalité, passer la feature gate à false ne suffit pas : le kubelet rejette la configuration si memoryThrottlingFactor vaut autre chose que l'ancien défaut 0.9, ou si memoryReservationPolicy vaut TieredReservation. Ces champs doivent être retirés ou ajustés d'abord.

À retenir

Le facteur s'applique aux conteneurs des classes Burstable et BestEffort — les Guaranteed, par construction, n'en ont pas besoin. Si vous exploitez un cluster qui s'appuyait sur le comportement alpha, la seule action utile tient en une ligne à ajouter dans votre KubeletConfiguration, avant la montée de version plutôt qu'après.