Kubernetes triple la densité de pods en activant le swap sur SSD NVMe

5 octobre 2026. Un billet du blog Kubernetes, signé Ocean Xie et Yuan Wang, documente le swap de nœud, passé en GA depuis la v1.34. 240 pods isolés sur un seul nœud, contre 80 sans swap. 3×. C’est le gain de densité mesuré sur des sandboxes Python. Pourquoi c’est important : après des années où le kubelet refusait de démarrer avec le swap activé, la plateforme officialise un mécanisme qui change le calcul économique des nœuds surchargés en mémoire.

Pourquoi le swap était interdit

Pendant près d’une décennie, le swap a été un interdit dans Kubernetes. Le kubelet refusait littéralement de démarrer sur un nœud où le swap était monté — la directive failSwapOn: true était la valeur par défaut, et activer le swap demandait de la contourner explicitement. Deux raisons techniques justifiaient ce dogme.

La première est la comptabilité mémoire. Sous cgroup v1, le contrôle traitait la mémoire et le swap comme une limite unique et fusionnée : impossible de fixer une borne indépendante pour le swap disque. Un conteneur pouvait donc envoyer une large part de sa mémoire anonyme sur le disque, rendant sa consommation réelle imprévisible et difficile à isoler d’un voisin. Le second frein était la latence : paginer vers un disque mécanique lent pénalisait lourdement les applications, et le bénéfice d’une densité accrue était annulé par la dégradation des temps de réponse.

Le résultat : on préférait tuer proprement un pod en OOM plutôt que de le laisser déborder sur un disque lent et mal compté. Un choix rationnel dans le monde cgroup v1 + disques rotatifs.

Ce qui a changé

Les deux verrous ont sauté en même temps. cgroup v2 apporte une comptabilité séparée du swap : la mémoire et le swap disque sont suivis indépendamment, ce qui permet de fixer une limite de swap distincte et de savoir précisément ce qu’un conteneur a envoyé sur disque. Et les SSD NVMe locaux ont ramené la latence de pagination à un niveau où elle ne domine plus le coût : page dormante, on la déplace ; page active, on la garde en RAM.

Le billet du 5 octobre formalise le résultat. Le support du swap de nœud est GA depuis la v1.34, et il repose sur ce tandem : cgroup v2 pour la comptabilité, NVMe pour la vitesse. Sur GKE, le mécanisme est exposé nativement via la fonction Node Memory Swap configurée sur des profils SSD local.

Les chiffres du benchmark

Le billet mesure trois familles de charges, avec des résultats qui quantifient précisément le compromis.

Le cas du build noyau est le plus instructif sur la nature du swap. Compiler Linux 6.1.1 exige une grosse pointe mémoire au moment de l’édition de liens, mais laisse de nombreux objets compilés inactifs en RAM le reste du temps — exactement le profil d’un pipeline CI/CD. Sans swap, il fallait une limite de 600 Mo pour éviter l’OOM. En routant le swap vers un SSD local, la limite tombe à 300 Mo, et le build se termine en 374 s contre 433 s sans swap. En revanche, descendre à 200 Mo force le jeu de travail actif à paginer : le temps d’exécution grimpe de plus de 40 %. La leçon tient en une phrase — le swap est une assurance contre les pointes, pas un substitut à la RAM.

Les charges agentiques racontent la même histoire avec plus d’ampleur. Sur un nœud c4-standard-32 (32 vCPU, 120 Go de RAM), des conteneurs runc non sandboxés plafonnaient à 512 pods ; le swap SSD local pousse la limite à 768. Avec des runtimes de sécurité stricts, l’effet est encore plus net, car l’isolation a un coût mémoire : gVisor passait de 80 à 160 pods, et Kata Containers de 40 à 50 microVM. Les sandboxes Python isolées — des sessions analysant 5 millions de lignes du jeu de données MovieLens 20M, avec une empreinte résidente d’environ 375 Mio par exécution — sautent de 80 à 240 sessions simultanées, soit 3×.

Le détail qui compte : à ces densités maximales, la latence supplémentaire vient surtout de la compétition CPU entre pods, pas des E/S de swap. Un opérateur qui vise une cible de latence précise tournera en dessous du pic, et verra une dégradation proportionnellement moindre.

Comment l’activer

L’activation passe par la configuration du kubelet, en désactivant le verrou historique et en bornant le comportement du swap :

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
failSwapOn: false
memorySwap:
  swapBehavior: LimitedSwap

Deux points de réglage complètent le mécanisme. Côté disque, pointez le swap vers un SSD local rapide — sur GKE, activez Node Memory Swap sur un profil SSD local. Côté charge, configurez vos workloads en QoS Burstable : fixez la limite mémoire du conteneur au-dessus de sa requête. Le nœud rationne alors automatiquement l’espace de swap rapide en fonction de la mémoire réellement utilisée par les applications inactives, tout en gardant les processus actifs réactifs.

Ce que ça ne règle pas

Le swap de nœud n’est pas une baguette magique, et le billet le dit sans détour. D’abord, il ne corrige pas une fuite mémoire : une application qui alloue sans libérer finira par saturer le swap comme elle aurait saturé la RAM, avec le même crash au bout — juste plus tard et plus lentement. Ensuite, les charges latence-critiques doivent rester en QoS Guaranteed : leur donner une limite égale à leur requête les exclut du mécanisme et préserve leur temps de réponse. Enfin, le gain suppose un disque local rapide ; router le swap vers un volume réseau lent réintroduira exactement la pénalité que le NVMe avait éliminée.

Verdict

Si vous opérez des clusters qui hébergent des agents IA, des sandboxes ou des pipelines CI/CD avec de longues phases d’inactivité, activez le swap de nœud sur SSD local dès maintenant : les chiffres de GKE montrent jusqu’à 3× de densité, souvent sans coût de latence mesurable, sur la même infrastructure. Si vos charges sont latence-critiques, gardez-les en QoS Guaranteed et laissez le swap aux pods Burstable — le mécanisme est fait pour absorber les pointes, pas pour porter vos bases de données. Si vous hésitez sur le principe, retenez la distinction du billet : le swap est une assurance contre les pics de mémoire, jamais un remplacement de la RAM — et quiconque l’utilise pour masquer une fuite paiera la facture plus tard.

Références

• Kubernetes Blog — Scaling Kubernetes Workloads with Node Swap
• Kubernetes Docs — Node swap memory