The Kubernetes project published an experiment using fast local SSD-backed node swap to increase workload density. It targets workloads with resident memory and idle periods. This is operational analysis, not an announcement that swap support has just reached GA. Kubernetes official announcement
Swap does not provide unlimited RAM. Pages needed again must be read from storage, introducing latency and I/O. Acceptable average latency can conceal long waits for a subset of requests.
On this page
Resident memory and the active working set are different
Not every page held by a process is read continuously. Swap moves some memory pages to storage and brings them back when needed. A waiting browser or execution workspace may have substantial dormant state. Pushing an actively accessed working set out of RAM can instead create repeated storage operations and sharply increase latency. The workload’s behavior determines which situation applies.
A memory-usage number alone does not establish suitability. Distinguish startup peaks, long waits followed by reactivation, and continuously active large working sets. Low CPU utilization is not proof that memory is dormant. Examine representative requests and access patterns before deciding that the resident footprint can be reduced without affecting the service experienced by users.
Fast SSDs remain a different resource from RAM
NVMe storage can offer better conditions than slower disks, but it does not become equivalent to memory. Swap traffic can compete with application data and logs, especially when many Pods become active at once. Look for occasional long responses as well as ordinary behavior. Average latency can conceal the tail that determines whether an interactive service remains usable.
Swap can also contain information previously held in memory. Review storage encryption, access control, and retirement policy. Confirm supported versions, cgroup prerequisites, and workload policies in the relevant product documentation. Enabling host swap with a shell command is different from verifying that Kubernetes manages the workload under the intended resource policy.
Test the transition out of the idle phase
For agent browser sessions, an evaluation could separate creation, a waiting period, and concurrent resumption. Compare with a no-swap baseline at matching concurrency and request patterns, recording latency and failures immediately after resumption. More simultaneously resident sessions are not sufficient justification if the resulting user wait exceeds the service’s acceptable range.
Place page-in and page-out activity, disk waiting, CPU pressure, and memory pressure on the same timeline. Define stop conditions for sustained page churn and a way to reduce density or adjust limits. The commands below provide a read-only starting point for inspecting current host swap and memory; they do not replace compatibility checks or workload-specific performance evaluation.
swapon --show
free -hAn empty swapon listing means no active swap entries are shown by this check. These outputs alone do not establish per-Pod swap policy or latency impact.
Metrics for an experimental node
- Measure average and tail latency alongside page-in and page-out activity.
- Check competition between swap and application storage I/O.
- Review sensitive-memory persistence and disk-encryption policy.
Start with one workload class and explicit resource and recovery limits. Compare additional RAM with storage costs under equivalent conditions.
Announcement reference date: 2026-10-05 · Checked: October 24, 2026
