Kubernetes 1.34 has moved node swap support to General Availability, allowing clusters to page idle memory to fast NVMe local SSDs while using cgroup v2 for separate swap accounting. For engineers building AI agents, CI/CD pipelines, or sandboxed runtimes, this change opens a path to higher pod density without the latency penalties that historically made swap unattractive.
Kubernetes node swap: why it was previously discouraged
Two technical reasons kept swap out of production Kubernetes deployments. First, under cgroup v1 memory and swap were combined into a single limit, making it impossible to track how much memory a container actually consumed versus how much was being swapped. This blurred isolation boundaries and complicated capacity planning. Second, the latency of paging to spinning disks could add noticeable pause times, especially for latency‑sensitive workloads.
How GA swap works with cgroup v2 and NVMe SSDs
Version 1.34 requires nodes to run with cgroup v2, which provides independent accounting for memory.swap. The kernel can now report swap usage per container, preserving the predictability of memory limits. When swap is backed by NVMe local SSDs, the I/O path is fast enough that the latency impact is minimal for most workloads, turning swap into a practical overflow buffer rather than a performance sink.
Observed density gains across representative workloads
Benchmarks compared a baseline node without swap to a node with swap backed by an NVMe SSD. The results showed substantial increases in concurrent pod counts or reductions in required RAM limits:
- Linux CI/CD kernel build: memory limit dropped from 600 MB to 300 MB (‑50 % RAM footprint) with no slowdown; execution time improved from 433 s to 374 s.
- Headless Chrome (Kata): concurrent pods rose from 40 to 50, a 25 % density improvement.
- Headless Chrome (gVisor): concurrent pods doubled from 80 to 160, a 100 % increase.
- Python sandbox (gVisor): concurrent pods tripled from 80 to 240, a 200 % increase.
These figures illustrate that workloads with large idle memory footprints—common in agentic AI scenarios—can be packed more tightly when swap absorbs the dormant pages.
Operational and security considerations
Enabling swap introduces new operational signals. Teams should monitor swap.used per pod to detect excessive paging that could indicate under‑provisioned memory or a mis‑behaving workload. Because swap resides on local SSDs, encrypting the disk is advisable to protect any swapped‑out data, especially for workloads handling untrusted code. The change does not alter the Kubernetes memory limit enforcement; OOM kills still occur if a container exceeds its memory.limit while active pages remain in RAM.
From a platform perspective, nodes must run a kernel and container runtime that support cgroup v2. Existing node images may need updating, and any tooling that assumes cgroup v1 accounting will require review. Security engineers should verify that the swap device is isolated from other tenants and that audit logs capture swap‑related events if compliance monitoring is required.
Related CloudNinjas coverage: Kubernetes.
What This Means For Practitioners
To take advantage of the new capability, practitioners should:
- Upgrade node OS and container runtime to versions that enable cgroup v2.
- Configure the node’s
--fail-swap-on=falseflag and provision an NVMe local SSD for swap storage. - Adjust pod memory requests/limits to reflect the ability to page idle memory, but validate that active working sets remain in RAM.
- Implement monitoring for
memory.swapmetrics and set alerts for sustained high swap usage. - Encrypt the swap device to mitigate data exposure risks.
By following these steps, teams can increase workload density for AI agents, CI/CD builds, and sandboxed runtimes while maintaining acceptable latency and security posture.
