News › performance
By The Linux Camp News, October 6, 2026
Local SSD-backed swap increased capacity in Kubernetes sandbox tests, but the gains depended on workload and runtime. Active-memory pressure and CPU contention still imposed performance limits.
On October 5, 2026, Ocean Xie and Yuan Wang published a Kubernetes Blog report on scaling workloads with node swap. This is a report about an existing capability, not a new Kubernetes release: the post identifies version 1.34 as the release in which node-swap support reached General Availability. 1
The authors tested CI/CD kernel builds, headless browsers and isolated Python runtimes, reporting density gains of up to threefold. The mechanism is moving dormant memory from RAM to fast NVMe SSD storage. That frees physical memory for additional pods rather than keeping every idle workload's memory resident. The useful distinction is between memory a workload retains and memory it needs actively. 1
Kubernetes relies on cgroup v2's separate swap accounting to track disk swap independently. That accounting addresses one obstacle to managing swapped container memory; storage speed addresses another. The authors credit fast NVMe Local SSDs with reducing the paging latency associated with spinning disks. Their results therefore concern a particular storage approach, not swap on arbitrary disks. 1
The capacity improvement varied substantially by workload and isolation runtime. Python sandboxes using gVisor increased from 80 to 240 concurrent pods. Headless Chrome using gVisor increased from 80 to 160, while Chrome using Kata increased from 40 to 50. For capacity planning, these are the authors' measured comparisons, not a uniform multiplier to apply across a cluster. 1
The compilation test illustrates both the opportunity and its boundary. Without swap, the authors needed a 600 MB container memory limit to avoid an out-of-memory crash. With Local SSD swap, a 300 MB limit completed in 374 seconds versus 433 seconds at baseline. This halves the configured RAM limit, not necessarily total memory demand. Reducing the limit to 200 MB pushed actively needed memory into swap, adding I/O waits and increasing execution time by more than 40%. 1
For browser workloads, maximum density is not the same target as acceptable response time. The authors attribute the latency increase at peak density mainly to CPU competition rather than swap I/O, and advise operating below those peaks for a specific latency target. The operational implication is to evaluate concurrency against the service's latency requirement, not just whether additional pods survive. 1
The post's configuration recipe provides concrete items to check: kubelet failSwapOn set to false, memorySwap.swapBehavior set to LimitedSwap, and high-speed local storage backing swap. It recommends Burstable workloads with container memory limits above requests. These are the conditions described for pursuing the benefits, not evidence of equivalent gains for every workload configuration or storage type. 1
The supplied article points to separate logs and methodology for the default-runtime tests, but those materials are absent from this source packet. The results should consequently be treated as reported benchmarks rather than independently reproduced measurements. Repetition counts, run-to-run variation and the measurements needed to validate the latency explanation remain unverified here. 1