Kubernetes Blog · By Ocean Xie, Yuan Wang | Monday, October 05, 2026 ·
Scaling Kubernetes Workloads with Node Swap
Las pruebas muestran que Kubernetes v1.34+ con swap respaldado por SSD NVMe puede aumentar hasta 3 veces la densidad de pods en cargas aisladas de Python, y duplicarla en entornos gVisor; también permite reducir a la mitad el límite de memoria de una compilación del kernel sin ralentizarla. En las densidades máximas, el aumento de latencia se debe principalmente a la competencia por CPU, pero forzar a que la memoria activa use swap puede elevar el tiempo de ejecución más de un 40 %. La recomendación es configurar `LimitedSwap` y usar swap como margen para memoria inactiva o picos, no como sustituto de la RAM activa.
Memory is often the first hard limit a Kubernetes cluster hits. Nodes run out of RAM long before they run out of CPU, and the new wave of agentic AI workloads makes this worse. These workloads demand large memory footprints to start up and run untrusted code, then sit idle waiting for the next prompt. That idle but resident memory is expensive, and it caps how many pods a node can hold. This is where swap helps. Kubernetes support for running nodes with swap enabled reached General Availability in v1.34, and by backing that swap with fast NVMe solid state drives (SSDs), a node can page out dormant memory and pack in far more pods. This post explains how we benchmarked that approach across three workloads, including CI/CD kernel builds, sandboxed headless browsers, and isolated Python runtimes; we found density gains of up to 3×, often with little or no latency cost.