Optimisation des paramètres d'échange Linux pour des nœuds Kubernetes stables

Dans un article publié sur le blog Kubernetes en août 2025, Ajay Sundar Karuppasamy de Google a détaillé la manière d'optimiser l'espace d'échange Linux pour les clusters Kubernetes. L'article aborde la stabilisation prochaine de la fonctionnalité NodeSwap dans Kubernetes v1.34, qui permet aux nœuds d'utiliser l'espace disque comme mémoire virtuelle. Cette évolution nécessite une configuration minutieuse des paramètres du noyau pour équilibrer l'utilisation des ressources et la stabilité du système.

Ce qui s'est passé

Pendant des années, le conseil standard pour les opérateurs Kubernetes était de désactiver entièrement l'espace d'échange afin de garantir des performances prévisibles. Cependant, l'introduction de la fonctionnalité NodeSwap change ce paradigme en permettant aux nœuds Linux de décharger les pages mémoire moins fréquemment utilisées vers un stockage secondaire. Cette capacité vise à réduire les terminaisons pour manque de mémoire (OOM) et à améliorer l'efficacité globale des ressources. Malgré ces avantages, l'activation de l'espace d'échange n'est pas un simple interrupteur. Sans réglage précis, elle peut entraîner une dégradation sévère des performances et interférer avec la capacité du Kubelet à gérer les évictions de pods de manière gracieuse.

L'article souligne que des paramètres d'échange mal configurés peuvent provoquer un comportement imprévisible du noyau sous pression mémoire. Lors de tests utilisant les paramètres par défaut, les nœuds ont subi des redémarrages inattendus et des terminaisons OOM prématurées lorsqu'ils étaient soumis à des taux élevés d'allocation mémoire. Le problème fondamental réside dans l'interaction entre les algorithmes de remplacement de pages du noyau Linux et la logique d'éviction de Kubernetes. Si le noyau ne récupère pas la mémoire assez rapidement, ou s'il récupère le mauvais type de mémoire, le nœud peut devenir instable avant que le Kubelet n'ait la possibilité d'agir.

Pour relever ces défis, l'auteur a mené une série de tests de charge sur des nœuds Google Kubernetes Engine (GKE) exécutant Kubernetes v1.33.2. Les tests impliquaient des applications Go personnalisées conçues pour simuler divers modèles et pressions d'accès mémoire. En ajustant des paramètres spécifiques du noyau, l'auteur a démontré comment créer une fenêtre opérationnelle plus sûre pour la gestion de la mémoire, empêchant ainsi les défaillances critiques lors de pics soudains de demande.

Comment cela fonctionne

Linux gère la mémoire par pages, généralement de 4 KiB chacune. Lorsque la RAM physique est pleine, le noyau doit décider quelles pages déplacer vers l'espace d'échange. Il distingue la mémoire anonyme, telle que les données de tas et de pile, de la mémoire liée aux fichiers, comme le code exécutable et les caches. Les pages anonymes doivent être écrites sur un périphérique d'échange pour être récupérées, tandis que les pages liées aux fichiers propres peuvent simplement être écartées. Le noyau utilise plusieurs paramètres pour guider ces décisions, principalement vm.swappiness, qui contrôle la préférence pour l'échange de pages anonymes par rapport à la suppression du cache de fichiers.

Deux autres paramètres critiques sont vm.min_free_kbytes et vm.watermark_scale_factor. Le paramètre min_free_kbytes définit une marge de sécurité de mémoire libre. Lorsque la mémoire disponible tombe sous ce seuil, le noyau récupère agressivement les pages. Le watermark_scale_factor détermine l'écart entre les seuils bas, min et haut de mémoire. Un écart plus grand donne au processus de récupération en arrière-plan, connu sous le nom de kswapd, plus de temps pour déplacer les pages vers l'échange progressivement. Cela empêche le système d'atteindre trop rapidement le seuil critique min, ce qui bloquerait sinon les allocations de processus et déclencherait des terminaisons OOM.

Détails clés

• La fonctionnalité NodeSwap devrait atteindre le statut stable dans Kubernetes v1.34.
• Les tests ont été effectués sur des nœuds GKE dotés de 8 GiB de RAM et de 50 GB d'espace d'échange sur des disques pd-balanced.
• Les paramètres par défaut (swappiness=60, min_free_kbytes=68MB) ont entraîné des terminaisons OOM sous forte charge.
• Augmenter min_free_kbytes à 512 MiB force une récupération mémoire plus précoce, offrant une marge de sécurité plus large.
• Définir watermark_scale_factor à 2000 élargit la fenêtre d'échange, permettant à kswapd de travailler plus efficacement.
• Les composants système critiques tels que kubelet et le runtime de conteneurs devraient avoir l'échange désactivé via les cgroups.

Pourquoi c'est important

Pour les ingénieurs logiciels et les équipes de plateforme, l'activation de l'espace d'échange introduit un compromis complexe entre capacité et latence. L'échange est significativement plus lent que l'accès à la RAM ; si l'ensemble de travail actif d'une application est déplacé sur le disque, les performances souffriront en raison de l'augmentation des temps d'attente I/O. Cependant, un espace d'échange correctement optimisé peut prévenir les plantages abrupts d'applications causés par des terminaisons OOM, qui sont souvent plus perturbants que des pics temporaires de latence. Comprendre ces mécanismes du noyau est essentiel pour construire des systèmes résilients capables de gérer la surallocation mémoire en toute sécurité.

De plus, un réglage inadéquat peut masquer des problèmes sous-jacents tels que les fuites mémoire. Au lieu d'échouer rapidement avec une terminaison OOM, une application sujette aux fuites pourrait dégrader lentement les performances du nœud en consommant l'espace d'échange, rendant le diagnostic difficile. Cela risque également de contourner les mécanismes d'éviction gracieuse de Kubernetes. Si le noyau déclenche une terminaison OOM avant que le Kubelet ne puisse évicter les pods selon la politique définie, des charges de travail de priorité supérieure pourraient être terminées de manière inattendue. Par conséquent, aligner le comportement du noyau sur les attentes de Kubernetes est crucial pour maintenir la santé du cluster.

Ce que vous pouvez faire

• Commencez avec vm.swappiness=60 pour les charges de travail polyvalentes, mais ajustez en fonction de la sensibilité I/O ou de la lourdeur de cache de vos applications.
• Définissez vm.min_free_kbytes à environ 2-3 % de la mémoire totale du nœud (par exemple, 500 MB pour un nœud de 8 GiB) pour créer une marge de sécurité suffisante.
• Augmentez vm.watermark_scale_factor à 2000 pour élargir la fenêtre de récupération mémoire en arrière-plan et prévenir les blocages.
• Désactivez l'échange pour les composants système critiques comme kubelet et le runtime de conteneurs via les cgroups.