A Kubernetes node can run out of physical memory even when its applications appear healthy. A sudden traffic spike, a large in-memory cache, or several memory-intensive workloads running together can push a node toward memory pressure. When the kernel cannot reclaim enough memory, containers may be terminated by the out-of-memory (OOM) killer, and Kubernetes may evict Pods to protect the node.
Linux swap provides another option. It allows the operating system to move selected memory pages from RAM to backing storage, freeing physical memory for more active workloads. Kubernetes supports configurable swap usage on Linux nodes, allowing administrators to decide whether workloads can use swap and how that access is limited.
The goal is not to replace adequate memory sizing. It is to give selected workloads additional flexibility during memory pressure while preserving predictable resource management.
What Is Swap in Kubernetes?
Swap is a Linux memory-management mechanism that moves less-active memory pages from physical RAM to a swap area, such as a dedicated partition or file. If a process needs a swapped-out page again, the kernel must retrieve it from storage.
This can help workloads with large memory footprints when only part of their allocated data is actively accessed. It can also provide additional breathing room during short-lived memory spikes.
Consider a node running three workloads:
An API service that needs predictable response times.
A background processor that occasionally allocates large amounts of memory.
A cache that keeps more data in memory than it actively accesses at any given moment.
With carefully configured swap, the background processor or eligible cache workload may move less-active pages to storage, leaving more physical memory available for active work.
However, accessing swapped-out data is much slower than accessing RAM. If a workload repeatedly swaps data in and out, performance can deteriorate significantly. This condition, known as thrashing, can make the node less responsive rather than more stable.
How Kubernetes Handles Swap
Kubernetes does not enable workload swap usage by default on Linux nodes. The kubelet normally refuses to start when it detects enabled swap unless its configuration explicitly permits it.
Two settings control the basic behavior:
The two supported behaviors are NoSwap and LimitedSwap.
Behavior | Workload swap access | Appropriate use |
|---|
NoSwap
| Kubernetes-managed workloads cannot use swap | Predictable latency and resource isolation |
LimitedSwap
| Eligible workloads can use a calculated amount of swap | Selected memory-heavy workloads that can tolerate additional latency |
NoSwap is the default. Even with this behavior, processes outside Kubernetes-managed containers, including system services, may use swap if the operating system permits it.
LimitedSwap enables controlled swap usage rather than giving every Pod unrestricted access. Kubernetes uses the container runtime and cgroup controls to apply the configured limits.
Configure a Linux Node to Allow Swap
Before enabling Kubernetes workload swap, verify that the node's operating system, kernel, kubelet, and container runtime support the configuration. Kubernetes swap support on Linux requires cgroup v2.
First, inspect the current swap configuration:
swapon --show
free -h
stat -fc %T /sys/fs/cgroup/
The first command lists active swap areas, the second reports memory and swap usage, and the third identifies the cgroup filesystem. A cgroup2fs result indicates a cgroup v2 hierarchy.
If the node has no swap area, an administrator must provision one before configuring kubelet. Swap provisioning is an operating-system task and should follow the procedures appropriate for the Linux distribution and infrastructure.
Next, update the kubelet configuration. The following YAML fragment illustrates the relevant settings:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failSwapOn: false
memorySwap:
swapBehavior: LimitedSwap
This fragment belongs in the kubelet configuration file; it is not a Kubernetes Pod manifest.
The failSwapOn: false setting allows kubelet to start when swap is detected. LimitedSwap permits eligible Kubernetes workloads to use swap within the limits applied by Kubernetes and the container runtime.
After changing the configuration, restart kubelet according to the node's operating procedures and verify that it starts successfully. On a kubeadm-managed system using systemd, the restart is commonly performed with:
sudo systemctl restart kubelet
sudo systemctl status kubelet
Do not apply these commands indiscriminately across a production cluster. Test the configuration on a worker node first, and follow your platform's documented process for managed Kubernetes services.
Which Pods Can Use Swap?
LimitedSwap does not mean every container receives unrestricted access to the node's swap space.
Under the documented policy, only eligible Burstable workloads can use swap. BestEffort and Guaranteed Pods are not permitted to use it. High-priority Pods are also excluded to help keep their memory resident in RAM.
The amount of swap available to an eligible container is calculated proportionally using its memory request, the node's total physical memory, and the swap capacity available to Kubernetes workloads.
Conceptually, the calculation is:
[
\text{Container swap limit} =
\frac{\text{Container memory request}}
{\text{Node physical memory}}
\times
\text{Pod-available swap}
]
For example, assume a node has 32 GiB of physical memory and 8 GiB of swap available for Kubernetes workloads. A container requests 4 GiB of memory.
Its proportional share would be:
[
\frac{4}{32}\times 8 = 1\text{ GiB}
]
This is an illustrative calculation, not a guarantee that the container can always consume exactly 1 GiB of swap. The actual allocation depends on Kubernetes' implementation, node configuration, workload eligibility, and the swap capacity available to Pods.
Memory requests therefore remain important when configuring swap. A container with a larger request receives a larger proportional allowance, but its actual swap usage still depends on memory pressure and kernel behavior.
Design Pod Resources for Predictable Behavior
Enabling swap does not remove the need to configure requests and limits carefully.
For example, a background processing workload might use the following specification:
apiVersion: v1
kind: Pod
metadata:
name: batch-processor
spec:
containers:
- name: processor
image: example/processor:stable
resources:
requests:
cpu: "500m"
memory: "2Gi"
limits:
cpu: "1"
memory: "4Gi"
The image is illustrative and must be replaced with a valid application image.
The memory request of 2 GiB influences scheduling and the workload's proportional swap allowance under LimitedSwap. The 4 GiB memory limit remains a separate resource constraint; swap does not mean the application can ignore its configured memory limit.
A workload with a memory request equal to its memory limit is treated as Guaranteed only when the Pod satisfies the Kubernetes QoS requirements for all relevant containers. Such workloads are not eligible for swap under LimitedSwap.
For latency-sensitive services, this may be desirable. For batch processors or workloads with infrequent access to large memory regions, limited swap may be worth testing.
Monitor Swap Usage and Memory Pressure
A successful kubelet startup does not prove that swap is helping the application. Monitor memory usage, swap activity, latency, and node health together.
Start with operating-system metrics:
free -h
swapon --show
vmstat 1
In vmstat, the si and so columns represent swap-in and swap-out activity. Sustained activity combined with rising application latency may indicate that the node is spending significant time moving memory pages between RAM and storage.
Also inspect Kubernetes node and Pod status:
kubectl describe node NODE_NAME
kubectl get pods -A -o wide
kubectl describe pod POD_NAME -n NAMESPACE
Look for memory-pressure conditions, Pod evictions, container restarts, and OOM-related events.
A useful monitoring dashboard should track:
Physical memory utilization and available memory.
Swap capacity and current swap usage.
Swap-in and swap-out rates.
Container memory usage relative to requests and limits.
Pod eviction events and container OOM events.
Application latency, error rates, and throughput.
Disk I/O latency and saturation.
Swap usage alone does not prove that a node is unhealthy. Some inactive pages can remain in swap without creating an immediate problem. The stronger warning sign is sustained swap activity combined with degraded workload or system performance.
Understand the Risks Before Enabling Swap
Latency and Disk I/O
Swap depends on the storage backing it. When a node uses a slow or I/O-constrained device, moving memory pages can increase storage latency and interfere with other operations.
Kubelet, the container runtime, and system services may also need disk access during memory pressure. A saturated disk can therefore affect the entire node.
Use sufficiently fast storage, monitor I/O latency, and consider prioritizing system-critical services. A dedicated encrypted swap device can help isolate swap traffic and reduce the risk of exposing sensitive memory contents.
Memory Accounting and Scheduling
Kubernetes schedules Pods based primarily on resource requests, not on swap capacity. Its scheduler does not automatically treat available swap as additional schedulable memory.
This means that adding swap does not justify increasing Pod density without considering physical memory. A node can still experience severe pressure if too many workloads compete for RAM.
Sensitive Data in Swap
Memory pages moved to swap may contain application data, credentials, or other sensitive information. Configure encrypted swap where appropriate and verify that the operating system protects memory-backed volumes as intended.
The Linux noswap tmpfs option is supported by the kernel starting with version 6.3, with some distributions backporting the capability. Verify the actual kernel and distribution behavior before relying on it for sensitive data.
Control Plane Stability
The Kubernetes project recommends running control plane nodes without swap configured. Control plane components need predictable responsiveness, and swapping their memory can degrade cluster operations.
A safer starting point is to evaluate swap on selected worker nodes rather than enabling it indiscriminately across the cluster.
Production Best Practices
Start with a controlled worker-node rollout. Test one suitable node before extending the configuration to other workers.
Choose workloads deliberately. Favor workloads that can tolerate occasional memory-access latency, rather than latency-sensitive services.
Use encrypted, sufficiently fast storage. Consider disk contention, I/O limits, and system-service responsiveness.
Keep requests and limits accurate. Swap does not replace correct capacity planning or resource configuration.
Tune eviction thresholds carefully. Coordinate kubelet eviction thresholds with Linux memory-reclaim behavior and vm.min_free_kbytes; setting them incorrectly can lead to premature evictions or late intervention.
Protect system-critical processes. Monitor kubelet, the container runtime, and other system services when swap activity increases.
Test under realistic pressure. Simulate memory spikes and measure application latency, swap activity, evictions, and node recovery.
Maintain a rollback plan. Define when swap should be disabled or a workload moved to a larger node if performance or stability deteriorates.
Conclusion
Kubernetes node swap gives administrators another tool for managing memory pressure on Linux worker nodes. With LimitedSwap, eligible workloads can use a controlled amount of swap instead of relying exclusively on physical RAM, which may help during certain memory spikes.
The trade-off is that storage-backed memory is slower than RAM, and excessive swapping can increase latency, disk pressure, and the risk of noisy neighbors. Kubernetes scheduling also does not treat swap as additional allocatable memory.
Use swap selectively, configure kubelet and the operating system deliberately, and measure application behavior under realistic memory pressure. The goal is not to make a memory-constrained node appear larger than it is, but to improve resilience without sacrificing predictable performance.
Join the conversation! Your thoughts help the community grow.