veilletech.frCe qui se passe
Le blog officiel de Kubernetes publie des mesures du swap des nœuds — fonctionnalité stable depuis Kubernetes 1.34 — placé sur des SSD NVMe locaux. Trois familles de charges ont été testées : une compilation de type CI, des navigateurs headless isolés, des bacs à sable Python.
La cible est explicite : les sandbox d'agents (projet kubernetes-sigs/agent-sandbox), qui réclament beaucoup de mémoire pour démarrer et exécuter du code non fiable, puis restent inactives en attendant la requête suivante. De la mémoire résidente qui ne travaille pas, et qui plafonne le nombre de pods par nœud.
Pourquoi le swap redevient fréquentable
Deux raisons le faisaient proscrire :
- la comptabilité : sous cgroup v1, mémoire et swap formaient une limite unique. Un conteneur pouvait paginer massivement sans que sa consommation réelle soit lisible. Le support du swap repose sur cgroup v2, qui compte le swap à part ;
- la latence : paginer sur disque rotatif coûtait cher, ce qu'un NVMe local réduit fortement.
Les mesures
| Charge | Sans swap | Avec swap sur SSD local |
|---|---|---|
| Compilation Linux 6.1.1 | limite 600 Mo | limite 300 Mo |
| Chrome headless, Kata Containers | 40 pods | 50 pods (+25 %) |
| Chrome headless, gVisor | 80 pods | 160 pods (×2) |
| Sandbox Python, gVisor | 80 pods | 240 pods (×3) |
- À 300 Mo, la compilation a fini en 374 s contre 433 s sans swap. À 200 Mo, le jeu de travail actif part en swap : plus de 40 % de temps en plus.
- En
runc, sans isolation, une machine c4-standard-32 (32 vCPU, 120 Go) passe de 512 à 768 pods. - Kata plafonne à 50 parce que le processeur sature, pas la mémoire.
- Chaque sandbox Python analyse 5 millions de lignes du jeu MovieLens 20M, environ 375 Mio résidents.
- Aux densités maximales, la latence monte surtout à cause de la concurrence sur le CPU, pas des entrées-sorties du swap.
Comment l'activer
Côté kubelet (Kubernetes 1.34 ou plus récent) :
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
failSwapOn: false
memorySwap:
swapBehavior: LimitedSwapEnsuite :
- placer le swap sur un disque local rapide — sur GKE, la fonction Node Memory Swap avec un profil Local SSD ;
- déclarer les pods en QoS Burstable, limite mémoire au-dessus de la requête. Valeurs d'exemple :
resources:
requests:
memory: "256Mi"
limits:
memory: "1Gi"Les limites
- Le swap est une assurance contre les pics, pas de la mémoire supplémentaire pour le jeu actif : la compilation à 200 Mo le montre.
- Les chiffres viennent de Google Cloud, sur SSD locaux. Sur un disque réseau, rien ne dit qu'ils tiennent.
- Viser une latence donnée impose une densité plus basse que les pics publiés.
Source : Scaling Kubernetes Workloads with Node Swap, blog Kubernetes, 5 octobre 2026. Bancs et code : agent-sandbox/examples/gke-swap.