Kubernetes has General Availability for running nodes with swap enabled, announced as part of v1.34. When swap is backed by fast NVMe Local SSDs, a node can page out dormant memory and fit substantially more pods without a predictable latency penalty in typical workloads. The move addresses a core constraint: RAM limits often cap cluster density as workloads become more dynamic and memory-hungry, such as agentic AI tasks and untrusted code execution environments.
HOW NODE SWAP INCREASES DENSITY AND WHAT CHANGES UNDER THE HOOD
Swap allows the Linux kernel to move idle anonymous memory to disk, reducing the active RAM footprint and enabling more pods to reside on a node during memory spikes. The approach relies on cgroup v2 for separate swap accounting and on Local SSDs to minimize paging latency, making it practical to increase pod density while preserving responsiveness for active processes. Operators configure kubelet with LimitedSwap and route swap to Local SSDs. TechStaged has also covered Kubernetes v1.37 Beta: KubeletInUserNamespace (Rootless) Graduates to Beta.
BENCHMARKS ACROSS THREE WORKLOADS SHOW DENSITY GAINS
The analysis benchmarked swap-backed density across three workload categories: a Traditional Build Workload for CI/CD pipelines (kernel builds), High-Density Browser Sandboxes, and Isolated Python Sandboxes. In a baseline Linux kernel build, memory limits without swap were around 600 MB. Routing swap to a Local SSD reduced the required memory to 300 MB without slowing execution (374 seconds vs. 433 seconds). Reducing the limit further to 200 MB caused longer I/O waits and more than a 40% increase in runtime, illustrating swap as an insurance policy for burst memory rather than a RAM replacement.
- CI/CD kernel builds: density gains observed with swap; baseline memory 600 MB; with swap 300 MB; 200 MB with swap led to latency penalties.
- Headless browser sandboxes: gVisor and Kata containers show higher pod counts when swap is enabled, with swap absorbing memory overhead from sandboxing.
- Isolated Python sandboxes: 5 million-row data scans with ~375 MiB resident memory per run scaled to 240 concurrent sessions with swap, up from 80 concurrent sessions without swap.
CONCRETE DENSITY FIGURES AND WHAT THEY IMPLY
Unsandboxed containers on a c4-standard-32 node (32 vCPU, 120 GB RAM) reached 768 concurrent pods with Local SSD swap, up from a hard limit near 512 pods without swap.
gVisor sandboxed pods rose from about 80 to 160 pods when swap was used. Kata Containers microVMs rose from about 40 to 50 pods under swap.
Python sandboxes scaled to 240 concurrent sessions with swap, versus 80 without swap, highlighting swap’s role in enabling memory-heavy workloads to run in parallel.
WHAT OPERATORS SHOULD KNOW ABOUT IMPLEMENTING NODE SWAP
Kubernetes v1.34 and later expose node swap as Generally Available. In Google Kubernetes Engine, Node Memory Swap configured on Local SSD profiles is a native option. Burstable QoS—allocating memory limits higher than requests—helps the node balance active workload memory against swap-backed idle memory.
The swap mechanism serves as an accelerant for density in environments running browser tests, AI agents, JVM applications, or sandboxed runtimes, while maintaining security boundaries where needed.
WHY THIS MATTERS IN THE ERA OF AGENTIC WORKLOADS
The combination of bursty, memory-intensive agentic workloads and strict hardware memory limits has long constrained pod density. Swap backed by Local SSDs offers a practical path to pack more pods per node, potentially lowering infrastructure costs and enabling more concurrent workloads without compromising security or stability.
WHAT HAPPENS NEXT FOR KUBERNETES USERS
Users can enable node swap via kubelet configuration and pair it with high-speed local storage on supported platforms like GKE. Operators should tune memory requests and limits to respect Burstable QoS and expect density gains to vary with workload characteristics and CPU contention.
RELATED COVERAGE
SOURCES
- Kubernetes Blog: Scaling Kubernetes Workloads with Node Swap Published · Primary source
