A Kubernetes node can run out of available memory even when its workloads have correctly declared memory requests and limits. A sudden traffic spike, a memory leak, or several containers allocating memory at the same time can push the node toward exhaustion. When the kernel cannot reclaim enough memory, processes may be terminated, pods may restart, and applications can become unavailable.
Kubernetes node swap provides another option for handling memory pressure. Instead of requiring all active memory pages to remain in physical RAM, the operating system can move some less-active pages to swap space, freeing RAM for other workloads. Kubernetes has been evolving its support for swap so administrators can decide how nodes use this resource rather than treating swap as universally forbidden.
The important distinction is that swap does not create additional physical memory or eliminate memory exhaustion. It changes how the operating system manages memory under pressure, introducing trade-offs involving latency, disk activity, workload isolation, and operational predictability.
For Kubernetes administrators, the decision is not simply whether swap should be enabled. It is whether the node configuration, workload characteristics, and resource controls make swap an appropriate part of the cluster's memory strategy.
What Is Swap in Kubernetes?
Swap is a memory-management mechanism provided by the operating system. When physical RAM becomes scarce, the kernel can move selected memory pages to a configured swap area, such as a swap partition or swap file. Those pages can be brought back into RAM when a process needs them again.
Without swap, memory pressure may force the kernel to reclaim caches aggressively or terminate processes when it cannot satisfy allocations. Swap gives the operating system another place to store some memory contents, potentially allowing more workloads to remain alive during temporary pressure.
However, accessing data from swap is generally much slower than accessing RAM. If a workload repeatedly accesses pages that have been moved to swap, the system may spend substantial time moving memory pages between storage and physical memory. This behavior, often called thrashing, can make applications extremely slow even if they have not crashed.
Kubernetes adds another layer to this problem because memory is managed both by the operating system and by the container runtime and kubelet. The cluster must account for how swap affects workload isolation, resource enforcement, and node-level scheduling decisions.
Why Kubernetes Historically Restricted Swap
Kubernetes relies on predictable resource management to operate workloads across a cluster. CPU and memory requests help the scheduler determine where pods can run, while memory limits can help constrain the amount of memory a container is permitted to use.
Swap complicates this model because memory pages belonging to a workload may occupy swap space instead of physical RAM. A node might appear to have enough available physical memory while applications experience substantial latency due to swap activity.
There are also differences between Linux kernel versions, cgroup configurations, container runtimes, and kubelet settings. Without explicit controls, swap behavior can make resource consumption harder to reason about.
Historically, Kubernetes commonly required swap to be disabled on Linux nodes. Support has since evolved to allow administrators to configure swap behavior explicitly on supported versions and environments.
The exact configuration depends on the Kubernetes version, kubelet settings, operating system, and available cgroup functionality. Administrators should consult the documentation for their deployed version rather than assuming that enabling swap at the operating-system level automatically makes it available to Kubernetes workloads.
How Kubernetes Node Swap Works
On a Linux node, the operating system must first have a valid swap area configured. Kubernetes then needs a compatible kubelet configuration that determines whether swap is permitted and how it is accounted for.
The kubelet setting failSwapOn controls whether the kubelet fails to start when swap is detected. In configurations that permit swap, administrators can also configure the memorySwap behavior through the kubelet configuration API.
For example, the following YAML illustrates the relevant configuration fields:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failSwapOn: false
memorySwap:
swapBehavior: LimitedSwapThis is an illustrative configuration fragment, not a complete kubelet configuration for every cluster. The accepted values and behavior must be verified against the Kubernetes version in use.
The settings have different responsibilities:
failSwapOn: falseallows the kubelet to start when swap is enabled on the node.memorySwap.swapBehaviordetermines the configured swap policy for workloads, subject to the capabilities and restrictions of the Kubernetes version and node environment.
The LimitedSwap option is intended to allow controlled swap use for eligible workloads rather than treating all workloads as unrestricted consumers of swap. Exact eligibility and accounting behavior depend on the Kubernetes implementation and configuration.
Administrators should not interpret failSwapOn: false as a complete swap policy. It permits the kubelet to operate with swap enabled, but the remaining configuration determines how that swap is managed.
Configuring Swap on a Linux Node
Before changing Kubernetes settings, establish whether the node operating system supports the intended configuration and whether the swap area is already configured.
On a Linux node, the following commands provide an initial view of memory and swap:
free -h
swapon --show
cat /proc/swapsThe output helps identify the available RAM, configured swap areas, and current swap capacity. It does not establish whether Kubernetes workloads are using swap heavily or whether the current configuration is safe for production.
A controlled configuration process should include these steps:
Confirm the Kubernetes and Linux versions running on the node.
Verify that the node's cgroup configuration supports the intended swap behavior.
Configure and validate the operating-system swap area according to the node's operating-system documentation.
Update the kubelet configuration using the supported configuration mechanism for the cluster.
Restart or reconfigure the kubelet according to the environment's operational procedure.
Confirm that the node returns to a healthy state and that the intended swap policy is active.
Run representative workloads and monitor memory pressure, latency, and swap activity.
For managed Kubernetes services, the provider may control some node configuration details or impose additional restrictions. Check the service-specific documentation before modifying kubelet settings directly.
Do not make a cluster-wide change before testing a representative node. A node that starts successfully is not necessarily a node that handles memory pressure correctly.
Understanding LimitedSwap and NoSwap
Kubernetes exposes swap behavior through the memorySwap.swapBehavior setting in supported kubelet configurations. The two important policies are NoSwap and LimitedSwap.
Behavior | Practical effect | When it may fit |
|---|---|---|
| Kubernetes workloads are not permitted to use swap under the configured policy. | Latency-sensitive workloads and environments that prioritize predictable memory behavior. |
| Eligible workloads can use swap within the limits and accounting rules supported by the Kubernetes implementation. | Workloads that may benefit from additional memory flexibility during temporary pressure. |
The correct choice depends on workload behavior, not just node size. Applications with predictable memory usage and strict latency requirements may be better served by NoSwap. Other workloads may tolerate occasional swap activity, particularly when the alternative is losing useful work during a short-lived memory spike.
Even with LimitedSwap, administrators must retain appropriate memory requests and limits. Swap should not become a reason to assign unrealistic resource values or schedule more workloads than the node can sustain.
Memory Requests, Limits, and Swap Are Different Controls
A common mistake is assuming that swap makes Kubernetes memory limits unnecessary. It does not.
Memory requests influence scheduling decisions. The scheduler uses declared requests when determining whether a node has enough allocatable resources for a pod. A request is not a guarantee that the application will never use more memory than that amount.
Memory limits define a separate boundary for container memory consumption, with enforcement behavior influenced by the Linux kernel and cgroup configuration. Swap accounting and enforcement depend on the supported Kubernetes implementation and configured policy.
Consider a node running several services, each with a memory request based on normal usage. A sudden workload increase can cause their actual memory consumption to exceed the available physical RAM. Swap may give the operating system more flexibility, but it does not fix incorrect requests, uncontrolled memory growth, or a cluster that consistently schedules too much work.
Administrators should still investigate why memory demand increased. If a service has a leak, allowing it to use swap can delay a failure while making the node slower. The underlying leak remains a problem.
Monitoring Swap and Troubleshooting Performance
Swap should be monitored alongside ordinary memory metrics. A node can remain technically healthy while experiencing significant performance degradation because memory pages are being moved between RAM and storage.
Start with basic node-level diagnostics:
free -h
vmstat 1
swapon --showThe vmstat command can help identify memory and swap activity over time. Its si and so columns represent swap-in and swap-out activity on Linux systems that report these fields. Persistent activity combined with increased latency can indicate that workloads are under pressure.
Interpret these measurements in context. Some swap allocation does not automatically indicate a problem, and the presence of a configured swap area does not mean it is being used heavily.
For Kubernetes, correlate node metrics with pod restarts, container memory usage, node conditions, application latency, and workload events. Determine whether the problem affects one container or multiple workloads across the node.
If a node becomes slow after enabling swap, investigate whether the system is thrashing, whether a workload has exceeded its intended memory budget, and whether the swap storage can handle the access pattern. Increasing swap capacity alone may not improve the situation.
Where latency is critical, test the effect of swap under realistic memory pressure rather than waiting for a production incident to reveal the behavior.
Security and Workload Isolation Considerations
Swap can also affect how sensitive information is handled. Memory pages may contain application data, credentials, tokens, or other sensitive material. Depending on the operating system and storage configuration, moving these pages to swap can introduce additional data-at-rest considerations.
Administrators should evaluate encryption, storage access controls, node disposal procedures, and the handling of swap devices or files according to their security requirements.
Workload isolation also needs attention. A memory-intensive workload that consumes substantial swap can affect node responsiveness even if it does not immediately exhaust physical RAM. Kubernetes resource controls, appropriate requests and limits, and workload placement remain important.
For multi-tenant clusters, test whether the configured swap policy provides the level of isolation expected by the organization. Do not assume that allowing swap automatically preserves the same performance characteristics as a no-swap environment.
Common Mistakes to Avoid
Disabling the kubelet's swap check without configuring a policy. Setting failSwapOn: false allows the kubelet to start with swap enabled, but it does not by itself define an appropriate workload policy. Configure the supported swap behavior and validate the resulting state.
Treating swap as extra physical memory. Swap provides additional backing storage for memory pages, not RAM with equivalent performance. Heavy swap activity can severely degrade application responsiveness.
Ignoring memory requests and limits. Swap does not replace resource planning. Continue to measure workload consumption, set realistic requests and limits, and investigate unexplained memory growth.
Enabling swap across every node immediately. Nodes may run different workloads and have different storage characteristics. Begin with a controlled test and expand only after validating performance and stability.
Monitoring only whether pods are running. A pod can remain healthy from Kubernetes' perspective while its application becomes too slow to serve requests effectively. Monitor latency and node-level swap activity in addition to restart counts.
Advantages and Disadvantages
Advantages
Additional flexibility during memory pressure: Swap can help the operating system retain workloads during temporary memory shortages instead of immediately exhausting physical RAM.
Potentially fewer abrupt failures in suitable workloads: Where the alternative is process termination, controlled swap use may allow some workloads to continue operating, although it does not guarantee that they will remain responsive.
More configuration control: Supported Kubernetes swap policies let administrators decide how swap should be exposed to workloads rather than relying only on a global operating-system setting.
Disadvantages
Higher and less predictable latency: Accessing swapped pages is slower than accessing RAM, and repeated paging can make applications unresponsive.
More operational complexity: Administrators must validate kernel, cgroup, kubelet, and runtime compatibility and monitor the resulting memory behavior.
Potential security implications: Sensitive data may be written to swap storage, requiring an appropriate storage and encryption policy.
No substitute for capacity planning: Swap cannot resolve a sustained shortage of memory or compensate for uncontrolled application growth.
Summary
Kubernetes node swap provides a configurable way to use swap space on supported Linux nodes. It can offer additional flexibility during temporary memory pressure, but it changes the performance and resource-management characteristics of the node.
Before enabling it, verify the Kubernetes version, Linux and cgroup capabilities, kubelet configuration, and workload requirements. Keep memory requests and limits meaningful, monitor swap-in and swap-out activity, and test under realistic pressure.
For latency-sensitive services, disabling workload swap may remain the more predictable choice. For workloads that can tolerate occasional paging, controlled swap use may be worth evaluating. The decision should follow measured behavior and an explicit operational policy, not the assumption that more available memory storage always improves reliability.
Join the conversation! Your thoughts help the community grow.