Kubernetes workloads that approach their memory limits can experience severe performance degradation or termination by the Linux out-of-memory mechanism. On memory-constrained nodes, this can disrupt application availability, trigger container restarts, and create cascading failures across dependent services.

Linux swap provides another layer of memory management by moving less-active memory pages from RAM to disk. However, Kubernetes has historically treated swap conservatively because uncontrolled swapping can make application performance unpredictable.

Modern Kubernetes versions support configurable swap behavior on Linux nodes. When enabled and configured appropriately, swap can give workloads additional memory headroom under pressure. But enabling swap does not increase a container's memory limit, eliminate out-of-memory failures, or guarantee better performance.

This article explains how Kubernetes node swap works, how kubelet configuration affects workloads, and how to evaluate swap safely without ignoring container memory limits.

Understand RAM, Swap, and Kubernetes Memory Limits

RAM is physical memory that the operating system can access directly. Swap is disk-backed storage that Linux can use to hold memory pages that are not currently resident in RAM.

When a node runs low on available memory, Linux may reclaim caches, swap eligible pages, or invoke the out-of-memory killer if memory pressure cannot be resolved.

Kubernetes adds resource accounting and enforcement on top of this behavior. Containers commonly receive memory constraints through their pod resource specifications, which are enforced through Linux control groups, or cgroups.

Consider a workload with the following configuration:

apiVersion: v1
kind: Pod
metadata:
  name: memory-example
spec:
  containers:
    - name: application
      image: nginx:stable
      resources:
        requests:
          memory: "256Mi"
        limits:
          memory: "512Mi"

The memory request influences scheduling decisions. The memory limit establishes the configured upper bound for the container's memory usage under the applicable enforcement rules.

Adding swap to the node does not automatically change either value.

The important distinction is that node swap changes how the operating system can manage memory pressure. It does not remove the need to configure appropriate requests and limits for each workload.

Understand Kubernetes Swap Configuration

Kubernetes swap support depends on the Kubernetes version, operating system, container runtime, cgroup configuration, and kubelet settings.

On Linux nodes, the kubelet's failSwapOn configuration determines whether kubelet startup fails when swap is enabled on the system.

With the default behavior, kubelet generally refuses to start when it detects active swap. Setting failSwapOn: false permits kubelet to start with swap enabled, but it does not by itself guarantee that workloads can use swap.

Workload swap behavior is controlled separately through the kubelet's memorySwap configuration, including its swapBehavior setting.

For example, a kubelet configuration can include:

failSwapOn: false

memorySwap:
  swapBehavior: LimitedSwap

This is an illustrative configuration fragment, not a complete kubelet configuration file. Merge it into the configuration supported by your installed Kubernetes release.

Two settings are especially important:

Always confirm the available values and feature requirements for your Kubernetes version before applying these settings.

Choose the Appropriate Swap Behavior

Kubernetes provides distinct swap behaviors for Linux nodes.

Behavior

Meaning

NoSwap

Workloads are not permitted to use swap

LimitedSwap

Eligible workloads can use swap under the configured limits

NoSwap preserves the traditional no-swap workload behavior even if the node has swap configured.

LimitedSwap permits swap usage under the supported Kubernetes and Linux configuration. Its effective behavior depends on the node's cgroup version and the relevant resource settings.

For example, the Kubernetes implementation uses cgroup v2 support for its swap-accounting behavior. A node using an incompatible configuration should not be assumed to enforce the intended workload limits.

Do not select LimitedSwap solely because the node has free swap space. First determine which workloads can benefit from it and how the operating system will behave when memory pressure increases.

Check the Linux Node Before Enabling Swap

Before modifying kubelet settings, inspect the node's current swap configuration.

On a Linux node, run:

swapon --show

This lists active swap devices and files.

You can also inspect memory and swap usage:

free -h

To check the cgroup version:

stat -fc %T /sys/fs/cgroup/

A result of cgroup2fs indicates a cgroup v2 filesystem at that location. Verify the actual node configuration rather than relying on this command alone if your environment uses a custom mount layout.

Next, inspect the kubelet configuration and service startup parameters. Depending on how the cluster was installed, kubelet settings may come from a configuration file, command-line flags, or distribution-specific configuration management.

For managed Kubernetes services, direct control over node swap may be limited. Check the provider's supported node configuration and operating-system requirements before attempting changes.

Enable Swap Carefully on a Test Node

Swap configuration is an operating-system operation, not a Kubernetes manifest operation.

A Linux administrator might configure a swap file or device and activate it through the system's supported tools. For example, after creating and securing a valid swap file, an administrator can activate it with:

sudo swapon /swapfile

This command assumes that /swapfile already exists, has been created correctly, and meets the operating system's requirements. It is not a complete procedure for creating a safe swap file.

Before activating swap on a Kubernetes node:

  1. Confirm that the operating system and cluster distribution support the configuration.

  2. Verify available disk capacity and storage performance.

  3. Configure the kubelet's swap behavior.

  4. Restart or reconfigure services according to the cluster's operational procedure.

  5. Verify node readiness before scheduling production workloads.

  6. Confirm that the intended workload swap behavior is actually enforced.

For an existing production cluster, apply the change through a controlled node-maintenance process. Drain workloads when appropriate, preserve disruption budgets, and make sure replacement capacity is available before taking nodes out of service.

Do not enable swap across every production node at once. Start with an isolated test node or a non-production node pool.

Configure a Workload With Explicit Memory Resources

Swap is not a substitute for resource requests and limits.

Continue defining realistic resource requirements:

apiVersion: v1
kind: Pod
metadata:
  name: api-worker
spec:
  containers:
    - name: worker
      image: example/api-worker:latest
      resources:
        requests:
          memory: "512Mi"
          cpu: "250m"
        limits:
          memory: "1Gi"
          cpu: "1"

The image is illustrative and must be replaced with an image that exists in your environment.

The request gives the scheduler a basis for placing the workload. The limit constrains the container according to the runtime's memory-enforcement behavior.

With supported swap configurations, a container may be able to use swap for eligible memory pages. That does not mean the application can allocate memory indefinitely or that every allocation will succeed.

When diagnosing memory pressure, investigate whether the application has a leak, retains too much data, or needs a larger resource allocation before relying on swap as a mitigation.

Monitor Swap Usage and Memory Pressure

Enabling swap without monitoring it can hide a resource problem until application latency becomes unacceptable.

Track at least the following signals:

A node can have available swap space while applications perform poorly because the storage device cannot service memory paging quickly enough.

Similarly, swap usage alone does not prove that a workload is unhealthy. Linux may retain swapped-out pages even after the immediate pressure has subsided.

Correlate swap activity with application-level symptoms and node memory pressure rather than alerting solely on a nonzero swap value.

Use the monitoring system already deployed in your cluster, and ensure its metrics accurately represent the kernel and container-runtime configuration in use.

Understand the Performance Trade-Offs

Swap can help absorb temporary memory pressure, but disk-backed memory is substantially slower than RAM in many environments.

Potential benefits include:

Potential costs include:

For example, a batch-processing service that occasionally retains inactive data may tolerate swap better than a real-time API that needs predictable response times.

The correct decision depends on the workload's access patterns, latency objectives, node storage, and memory-pressure characteristics.

Test Swap Under Controlled Memory Pressure

Before rolling out swap, compare workload behavior with and without it.

A useful test procedure is:

  1. Record baseline latency, throughput, memory usage, and restart counts.

  2. Run representative workloads on a node with swap disabled for workloads.

  3. Repeat with the intended swap configuration on an equivalent test node.

  4. Introduce controlled memory pressure in a non-production environment.

  5. Observe swap usage, storage latency, container memory metrics, and application behavior.

  6. Verify that the node remains stable and that resource constraints behave as expected.

Avoid using an uncontrolled memory-exhaustion test on production nodes. Such tests can destabilize the host and affect unrelated workloads.

The test should answer a practical question: does swap improve resilience enough to justify its latency and operational costs?

If the workload repeatedly exhausts its configured memory, the better fix may be application optimization, right-sized resource limits, or additional node capacity.

Common Mistakes to Avoid

Assuming failSwapOn: false enables unrestricted swap for containers. It allows kubelet to operate with system swap enabled; workload swap behavior is configured separately.

Removing memory limits because swap is available. Requests and limits remain important for scheduling, resource accounting, and workload isolation.

Ignoring cgroup compatibility. Verify the cgroup version and the swap-accounting behavior supported by the Kubernetes release and node configuration.

Using swap as a permanent fix for memory leaks. Swap can delay failure without correcting excessive memory retention.

Ignoring storage performance. Paging can increase I/O pressure and cause significant application latency.

Changing every node simultaneously. Test first, use controlled rollouts, and preserve enough capacity for workload recovery.

Summary

Kubernetes node swap can provide additional memory-management flexibility when configured through supported Linux and kubelet settings. The key controls include failSwapOn and memorySwap.swapBehavior, which serve different purposes.

Keep workload requests and limits in place, verify cgroup and runtime compatibility, and monitor application performance alongside node swap usage. Swap is most useful when it addresses a measured resilience requirement, not when it merely conceals insufficient capacity or an application memory problem.

A controlled rollout and realistic memory-pressure testing are essential before relying on swap in production.