Swap is how some Kubernetes nodes fit three times the pods

Kubernetes support for nodes with swap enabled reached general availability in v1.34. On 5 October 2026, Ocean Xie and Yuan Wang published measurements of what that is worth when the swap device is a fast NVMe SSD. Memory, not CPU, is still the first hard limit on a lot of clusters. Agentic workloads make it worse: a sandbox wants a large footprint to start, then sits idle until the next prompt. That idle memory is resident, and it caps how many pods fit on the node.

Swap lets the node page dormant anonymous memory out and keep physical RAM for what is actually running. The post looks at three shapes of work, including CI kernel builds, sandboxed headless browsers, and isolated Python runtimes. The headline number is density, up to about three times as many pods, often without a latency cost that the authors attribute to swap itself.

The Python case is the clearest. Each sandbox analyzed about 5 million rows from the MovieLens 20M dataset and held roughly 375 MiB. Without swap, the node ran out of RAM at 80 concurrent sessions. With local SSD swap, the same node reached 240 isolated Python sandboxes. Latency at that peak came mostly from CPU contention, not from waiting on the SSD. The page cache stayed intact because dormant memory, not cache, was what moved.

This is not a suggestion to enable swap on every node and walk away. Swap hides a memory shortage until the working set stops being idle. A pod that is actually hot will pay for every page it touches. The workloads that match the blog are the ones with a big, quiet footprint: sandboxes between prompts, browsers between actions, builds that allocate and then wait.

If that is your node, the 1.34 feature is no longer an alpha experiment. The 5 October numbers are a reason to test it on a spare pool with NVMe under the swap file, and to watch PSI and latency before you raise the pod limit.