Kubernetes clusters frequently exhaust physical memory well before reaching CPU saturation, a bottleneck that node-level swap support addresses by paging dormant memory to fast local storage to substantially increase container density. Following the promotion of node swap to General Availability in Kubernetes v1.34, testing published by Kubernetes shows that pairing the feature with NVMe Local SSDs can double or triple pod capacity across continuous integration builds and isolated agent execution environments.
Historically, Kubernetes discouraged swap because cgroup v1 combined physical memory and swap tracking into a single ceiling, preventing operators from isolating disk swap usage. Kubernetes resolves that limitation through cgroup v2, which provides dedicated swap accounting controls. Modern NVMe storage also removes the severe latency penalties associated with paging out memory to spinning disks, enabling the Linux kernel to page anonymous memory to disk during periods of heavy oversubscription.
To measure these improvements, Kubernetes benchmarked three distinct workload types. For batch jobs, engineers built the Linux 6.1.1 kernel, which requires substantial memory spikes during linking. Without swap, the process required a minimum 600 MB memory limit to avoid an out-of-memory crash. Diverting swap to a Local SSD cut that limit by 50 percent to 300 MB without performance degradation, finishing in 374 seconds compared to the baseline 433 seconds. However, lowering the limit further to 200 MB pushed the active working set into swap, increasing I/O wait times and raising compilation time by more than 40 percent.
For agentic workloads running headless Chrome browsers, swap helped overcome the memory overhead imposed by security sandboxing runtimes. On a c4-standard-32 node with 32 vCPUs and 120 GB of RAM, unsandboxed runc containers scaled from a no-swap ceiling of 512 pods to 768 pods with Local SSD swap. When running isolated headless Chrome instances inside gVisor, swap doubled node capacity from 80 pods to 160 pods. Kata Containers microVMs increased from a baseline of 40 pods to 50 concurrent microVMs before reaching CPU saturation.
Isolated Python runtimes processing 5 million rows from the MovieLens 20M dataset showed similar density gains. Each Python session required approximately 375 MiB of resident memory. Under concurrent bursts without swap, physical memory limits capped the node at 80 simultaneous sessions. Adding Local SSD swap allowed the system to page out inactive memory and scale to 240 isolated sandboxes, representing a 200 percent density improvement. At maximum densities across both browser and Python tests, per-pod latency increases were driven primarily by pods competing for CPU rather than disk swap I/O.
Operators can activate the feature in Kubernetes v1.34 and later by updating the KubeletConfiguration to set failSwapOn to false and configuring swapBehavior to LimitedSwap under memorySwap. Google Kubernetes Engine provides native support for this through Node Memory Swap paired with Local SSD profiles. Kubernetes notes that the configuration relies on Burstable Quality of Service settings, where memory limits exceed memory requests, and that operators targeting strict latency goals must tune density below peak limits to prevent CPU contention.
