Kubernetes Swap Support: Should You Turn It On in 1.35?

Short answer: enable it per node with failSwapOn: false and memorySwap.swapBehavior: LimitedSwap in the kubelet config, and only your Burstable pods will actually use it. Guaranteed pods are excluded by design. It's a genuine win for memory-spiky, cache-heavy workloads and a bad idea for latency-sensitive request handlers.

For most of Kubernetes' existence, running with swap enabled on a node simply wasn't allowed. The kubelet would refuse to start. That made sense at the time: Kubernetes builds its scheduling and eviction decisions on the assumption that a byte of RAM a pod is granted behaves like RAM, fast and predictable, and swap quietly breaks that assumption. A pod that gets OOMKilled at 90% memory headroom because a brief spike tripped the node's eviction threshold isn't a bug. It's the system working as designed, just not in a way that feels forgiving.

Node swap support, tracked as KEP-2400, went GA in Kubernetes 1.34 and reached stable in 1.35, which shipped as the "Timbernetes" release. If you're running a self-managed cluster (kubeadm, bare metal, or cloud VMs where you control node config, as opposed to a fully managed node pool where this setting isn't exposed to you) and you've been putting off a decision on this, this is the release where teams are actually flipping it on.

It's worth being precise about what "stable" means here, because it's easy to read that word as "turned on for you." It isn't. Swap support is opt-in at two separate levels: the node has to have swap space actually provisioned on disk, and the kubelet has to be explicitly configured to allow pods to use it. Nothing changes on an existing cluster just because you upgraded to 1.35. The kubelet still refuses to start on a swap-enabled node unless you tell it otherwise.

The detail that trips people up first is that swap access isn't a node-wide switch. It's gated by pod QoS class, and only Burstable pods (the ones where at least one container sets a memory request lower than its limit) get access to swap at all. BestEffort pods, which set no requests or limits, are also excluded. Guaranteed pods, where every container's memory request exactly equals its limit, never touch swap no matter what you configure on the node.

That's not an oversight or a current limitation waiting to be lifted in a future release. It's the point. Choosing Guaranteed QoS is an explicit statement that a workload needs dedicated, predictable memory with no surprises, and letting it silently swap would undermine the entire reason someone reached for that QoS class in the first place. If you're not already comfortable with how Kubernetes derives QoS class from requests and limits, it's worth reviewing the mechanics before you touch swap config, since the swap behavior you get is entirely downstream of a decision you already made when you wrote your pod spec. Our Kubernetes interview questions guide covers the QoS class breakdown (Guaranteed, Burstable, BestEffort) and how the scheduler and eviction manager treat each one differently.

Swap support only works on nodes running cgroup v2. If your nodes are still on cgroup v1 (increasingly rare on current distros, but worth checking if you're on an older base image), the kubelet will reject the swap configuration outright rather than silently ignoring it. Confirm which version a node is running before you do anything else:

You'll also need a container runtime that supports cgroup v2 memory swap limits, which means a current containerd or CRI-O build. Most distributions that ship cgroup v2 by default (recent Ubuntu, Fedora, and their derivatives) already pair it with a runtime version new enough to work, but it's worth confirming on any node image you built or pinned a while ago rather than assuming.

First, provision swap on the node itself. Kubernetes doesn't create this for you; it just changes how the kubelet reacts once swap exists:

Then configure the kubelet to allow it:

The swapBehavior value matters more than it looks like it should. NoSwap is the default once failSwapOn is set to false: the kubelet will start on a swap-enabled node, but your pods still won't touch that swap. That combination, swap provisioned on disk but NoSwap configured, is a trap people fall into constantly. You've spent disk space and gotten zero behavioral change, and you'll spend real debugging time later wondering why memory pressure is still evicting pods exactly like before.

LimitedSwap is what you actually want if the goal is giving Burstable pods real swap access. Under LimitedSwap, a Burstable container's swap usage is capped in proportion to how much its memory request sits below its limit, so a pod can't quietly swap its way past the memory ceiling the scheduler placed it against. Guaranteed and BestEffort pods still get nothing, regardless of this setting.

Restart the kubelet after applying the config change, and give it a minute to re-register the node with its updated capacity before you schedule anything that depends on the new behavior.

Don't take the config file's word for it. Confirm the node actually sees swap and the kubelet started with it enabled:

Then deploy a small Burstable test pod (a request below its limit) that deliberately allocates memory past its request, and watch free -h on the node while it runs. If swap usage climbs instead of the pod immediately hitting eviction or an OOM kill, the configuration is working end to end, not just accepted by the kubelet on paper.

The clearest win is a workload with a large memory footprint but a small active working set: a service holding a big in-memory cache or dataset where only a fraction of it is touched at any given moment. The rarely-accessed pages can sit in swap without meaningfully affecting performance, and the node avoids evicting or killing a pod that looks like it's using more memory than it actually needs moment to moment.

Batch and background jobs that can tolerate some slowdown are the other good fit. A nightly data processing job that swaps a bit and takes twenty-two minutes instead of eighteen is a fine trade against getting OOMKilled partway through and restarting from scratch, especially for jobs that aren't cleanly idempotent or checkpointed.

Latency-sensitive request-serving services are the wrong fit, full stop. A memory access that normally costs nanoseconds becomes a disk read measured in milliseconds the moment that page is swapped out, and that shows up as p99 latency spikes that are genuinely harder to diagnose than an OOM kill. An OOM kill is loud: the pod restarts, your alerting fires on the restart count, and you know immediately what happened and when. A swap-thrashing pod just gets quietly slower in a way that looks like a mystery performance regression, and it can stay that way for a long time before anyone thinks to check node-level swap usage instead of application code.

There's a real debugging cost buried in that failure mode too. Most profiling and metrics tooling assumes memory access cost is roughly uniform, and that assumption starts lying to you once swap enters the picture. If you're already fighting production memory issues that don't show up as clean crashes, that pattern will feel familiar. We covered the same shape of problem from the application side in our guide to catching Go goroutine leaks before they OOMKill a pod, where the failure is silent right up until a node-level threshold gets crossed. If you're trying to work backward from a crash that's already happened, PodTriage walks through the kubectl describe and events output needed to tell an OOMKilled pod apart from a node-level eviction, which is exactly the distinction that gets murkier once swap is involved.

There's no single yes-or-no answer here, because the feature being stable doesn't mean it's the right fix for your specific memory problem. It means it's finally safe to test the question at all, on a workload where the question makes sense to ask.

If you land in the "test it in staging" row, do exactly that before touching production: roll it out to one node pool, point a representative slice of Burstable traffic at it, and watch both the OOM-kill rate and p99 latency for at least a full traffic cycle (a week, ideally, to catch batch jobs and weekend traffic patterns) before deciding whether to expand it fleet-wide.

Watch node-level swap usage during that window, not just pod-level metrics. node_memory_SwapCached_bytes and node_memory_SwapFree_bytes from node_exporter, if you're already running Prometheus, tell you whether swap is being touched at all versus sitting idle because LimitedSwap capped usage tighter than expected. Pair that with your existing p99 latency dashboards for the same pods, and set an alert on sustained swap growth rather than any swap usage at all, since brief swap-ins during a traffic spike are exactly the behavior you're trying to enable.

Rolling back is simple if the staging window doesn't go well: set failSwapOn: false back with memorySwap.swapBehavior: NoSwap, restart the kubelet, and the node stops granting swap access on the next scheduling cycle. You don't need to disable swap on the node itself or drain it first, since NoSwap is safe to run indefinitely even with swap space provisioned and sitting unused.