Executive Summary
The Kubernetes project published benchmarks on October 5 showing that NVMe-backed node swap, generally available since v1.34, raises pod density on a single node by up to three times for sandboxed agent runtimes. A 32 vCPU node held 240 isolated Python sandboxes with swap against 80 without it. Headless Chrome pods under gVisor doubled from 80 to 160, and an unsandboxed sweep climbed from 512 to 768.
This lands in a year when DRAM, not compute, sets the price of an AI rack. Paging idle agent memory to fast local SSD turns stranded RAM into usable capacity, and that is a lever operators have been missing. The catch is real. Swap is a shock absorber for burst memory, not a substitute for active RAM, and density peaks carry a CPU penalty. Treat it as a density dial, not a free upgrade.
Memory is the wall every Kubernetes cluster hits first. Nodes run out of RAM long before they run out of CPU, and the current wave of agent workloads makes it worse. A coding agent boots a large runtime to execute untrusted code, then sits idle waiting for the next prompt. That idle memory stays resident, and it caps how many pods a node will hold.
Kubernetes shipped a way around that in v1.34, and on October 5 the project published the benchmarks to prove it holds up. Kubernetes node swap, backed by fast local solid state drives, lets the kernel page dormant memory to disk so one node can carry far more work.
Swap was banned for reasons that no longer hold
For years the advice was blunt. Turn swap off. Two problems drove it, and both are now solved.
The first was accounting. Under cgroup v1, memory and swap shared a single limit, so a process could push anonymous memory to disk and make its real footprint unpredictable. Kubernetes now leans on cgroup v2, which tracks disk swap separately, so a container’s RAM use stays knowable.
The second was latency. Paging out to a spinning disk was slow enough to wreck tail latency. Fast local NVMe removes most of that penalty. Together they make swap practical again on nodes that carry the right disk.
The density numbers are the actual story
The project ran three workload families on a 32 vCPU node with 120 GB of RAM. The numbers are not marginal, and the pattern repeats across all of them.
A sandboxed Python runtime under gVisor went from 80 concurrent sessions to 240, a three times gain. Headless Chrome under gVisor doubled, from 80 pods to 160. A plain runc sweep failed past 512 pods without swap and reached 768 with it. Kata Containers microVMs, the heaviest isolation, moved from 40 to 50 before CPU saturated. The project ran the untrusted code through its agent-sandbox framework.
Even ordinary batch work improved. A full Linux kernel build needed a 600 MB memory limit to avoid an out of memory kill without swap. With local SSD swap it ran at 300 MB, and finished faster, 374 seconds against 433.
Swap is a shock absorber, not free memory
The same data shows the limit. When the project squeezed the kernel build cap to 200 MB, the active working set spilled into swap and execution time rose by more than 40 percent. Swap absorbs bursts of memory. It does not replace the memory a workload needs to run.
At the density peaks, the added latency came from pods competing for CPU, not from swap I/O. An operator tuning to a latency target would run below the peak and pay less. And the whole method depends on one ingredient, fast local NVMe on every node, which competes for the same budget as the memory it is meant to relieve.
The verdict is a dial, not a switch. If your nodes carry local NVMe and you run sandboxed agents that idle between prompts, node swap is now measured, supported, and worth a pilot. If your storage is remote, or your workloads hold memory hot, it will not save you.
Three questions for your own cluster. Do your nodes have local NVMe to back swap, or only network storage? Which of your workloads sit idle with resident memory, agent sandboxes, browser farms, or JVM heaps? And is your density ceiling today RAM or CPU?
Related reading. The memory shortage is already setting the price of a rack, and the cold start problem shows why the model, not the container, is the real footprint.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.