Swap memory management [page]deterministic

concepts

Kubernetes can be configured to use swap memory on a [node](#gloss:node), allowing the kernel to free up physical memory by swapping out pages to backing storage. This is useful for multiple use-cases. For example, nodes running workloads that can benefit from using swap, such as those that have large memory footprints but only access a portion of that memory at any given time. It also helps prevent Pods from being terminated during memory pressure spikes, shields nodes from system-level memory spikes that might compromise its stability, allows for more flexible memory management on the node, and much more.

To learn about configuring swap in your cluster, read [Configuring swap memory on Kubernetes nodes](/docs/tutorials/cluster-management/provision-swap-memory/).

## Operating system support

* Linux nodes support swap; you need to configure each node to enable it. By default, the kubelet will not start on a Linux node that has swap enabled. * Windows nodes require swap space. By default, the kubelet does not start on a Windows node that has swap disabled.

## How does it work?

There are a number of possible ways that one could envision swap use on a node. If kubelet is already running on a node, it would need to be restarted after swap is provisioned in order to identify it.

When kubelet starts on a node in which swap is provisioned and available (with the `failSwapOn: false` configuration), kubelet will: - Be able to start on this swap-enabled node. - Direct the Container Runtime Interface (CRI) implementation, often referred to as the container runtime, to allocate zero swap memory to Kubernetes workloads by default.

Swap configuration on a node is exposed to a cluster admin via the [`memorySwap` in the KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1). As a cluster administrator, you can specify the node's behaviour in the presence of swap memory by setting `memorySwap.swapBehavior`.

### Swap behaviors

You need to pick a [swap behavior](/docs/reference/node/swap-behavior/) to use. Different nodes in your cluster can use different swap behaviors.

The swap behaviors you can choose for Linux nodes are:

`NoSwap` (default) : Workloads running as Pods on this node do not and cannot use swap.

`LimitedSwap` : Kubernetes workloads can utilize swap memory.

> Note: If you choose the NoSwap behavior, and you configure the kubelet to tolerate swap space (`failSwapOn: false`), then your workloads don't use any swap.

However, processes outside of Kubernetes-managed containers, such as systemd services (and even the kubelet itself!) can utilize swap.

You can read [configuring swap memory on Kubernetes nodes](/docs/tutorials/cluster-management/provision-swap-memory/) to learn about enabling swap for your cluster.

### Container runtime integration

The kubelet uses the container runtime API, and directs the container runtime to apply specific configuration (for example, in the cgroup v2 case, `memory.swap.max`) in a manner that will enable the desired swap configuration for a container. For runtimes that use control groups, or cgroups, the container runtime is then responsible for writing these settings to the container-level cgroup.

## Observability for swap use

### Node and container level metric statistics

Kubelet now collects node and container level metric statistics, which can be accessed at the `/metrics/resource` (which is used mainly by monitoring tools like Prometheus) and `/stats/summary` (which is used mainly by Autoscalers) kubelet HTTP endpoints. This allows clients who can directly request the kubelet to monitor swap usage and remaining swap memory when using `LimitedSwap`. Additionally, a `machine_swap_bytes` metric has been added to cadvisor to show the total physical swap capacity of the machine. See [this page](/docs/reference/instrumentation/node-metrics/) for more info.

For example, these `/metrics/resource` are supported: - `node_swap_usage_bytes`: Current …(trimmed)