期待已久：K8S终于迎来交换内存Beta支持！

关注【云原生百宝箱】公众号，获取更多云原生消息

Kubernetes 1.22 版本开始支持在 Linux 节点上使用交换内存的 Alpha 特性，而在 1.28 版本中升级为 Beta 版本并进行了许多改进。之前版本的 Kubernetes 不支持 Linux 系统上的交换内存，但随着 Alpha 版本和后续的改进，Kubernetes 项目团队投入大量精力支持交换内存的 Beta 版本，使其更稳定、健壮和用户友好。

此功能的使用方法包括激活 kubelet 上的 NodeSwap 特性门控，并配置 memorySwap.swapBehavior 选项来定义节点使用交换内存的方式。

1.22前不支持交换内存

在之前的版本中，Kubernetes 不支持在 Linux 上使用交换内存，因为涉及交换时很难提供保证和解释 pod 内存利用率。作为 Kubernetes 早期设计的一部分，交换支持被认为超出了范围，如果在节点上检测到交换，则默认情况下 kubelet 将无法启动。

以下是一些关于 Kubernetes 1.22版本以前禁用内存交换的考虑：

1. 性能： 内存交换可能对容器的性能产生负面影响。当容器中的进程试图访问已经被交换出去的内存时，系统需要将其从磁盘交换回内存，这会导致性能下降。
1. 不确定性： 内存交换可能会引入不确定性。容器应该在其配置的内存限制范围内运行。如果发生了内存交换，容器的实际可用内存可能会受到不可控因素的影响，从而导致应用程序运行不稳定。
1. 资源保证： Kubernetes 在调度和管理容器时会依赖 cgroups 和 Linux 内核功能来确保资源隔离和限制。内存交换可能破坏了这种隔离性，使得 Kubernetes 对容器资源的管理变得更加困难。
1. 安全性考虑： 内存交换可能会使得敏感信息泄露到交换分区，这可能对安全性造成威胁。

然而，有许多需要使用交换内存的用例[1] 将受益于支持交换的 Kubernetes 节点，包括提高节点稳定性、更好地支持内存开销高但工作集较小的应用程序、内存受限设备的使用以及内存灵活性。

1.22开始支持交换内存

Kubernetes 1.22 版本为交换内存引入了一项 Alpha 支持[2]，用于为在 Linux 节点上运行的 Kubernetes 工作负载逐个节点地配置交换内存使用。现在，在 1.28 版中，对 Linux 节点上的交换内存的支持已升级为 Beta 版，并有许多新的改进。

在 1.22 版之前，Kubernetes 不提供对 Linux 系统上交换内存的支持。这是由于在涉及交换内存时保证和计算 Pod 内存利用率的固有困难。因此，交换内存支持被认为超出了 Kubernetes 的初始设计范围，并且如果在节点上检测到交换内存， kubelet 的默认行为是无法启动。

在 1.22 版中，Linux 的交换特性以 Alpha 阶段初次引入。这代表着一项重大进步，首次为 Linux 用户提供了尝试交换内存特性的机会。然而，作为 Alpha 版本，它尚未开发完成，并存在一些问题，包括对 cgroup v2 支持的不足、指标和 API 统计摘要不足、测试不足等等。

Kubernetes 有许多交换内存用例[3]，并适用于大量用户。因此，Kubernetes 项目内的节点特别兴趣小组投入了大量精力来支持 Linux 节点上的交换内存特性的 Beta 版本。 与 Alpha 版本相比，启用交换内存后 kubelet 的运行更加稳定和健壮，更加用户友好，并且解决了许多已知缺陷。 这次升级到 Beta 版代表朝着实现在 Kubernetes 中完全支持交换内存的目标迈出了关键一步。

如何使用此特性？

通过**激活 kubelet 上的

NodeSwap

特性门控**，可以在已配置交换内存的节点上使用此特性。此外，你必须禁用

failSwapOn

设置，或者停用已被弃用的

--fail-swap-on

命令行标志。

可以配置

memorySwap.swapBehavior

选项来定义节点使用交换内存的方式。例如：

# 将此段内容放入 kubelet 配置文件
memorySwap:
  swapBehavior: UnlimitedSwap

swapBehavior

的可用配置选项有：

• UnlimitedSwap（默认）：Kubernetes 工作负载可以根据请求使用尽可能多的交换内存，最多可达到系统限制。
• **LimitedSwap**：Kubernetes 工作负载对交换内存的使用受到限制。只有 BurstableQoS Pod [4] 才允许使用交换内存。

如果未指定

memorySwap

的配置并且启用了特性门控，则默认情况下， kubelet 将应用与

UnlimitedSwap

设置相同的行为。

**请注意，仅 cgroup v2 支持

NodeSwap

。**针对 Kubernetes v1.28，不再支持将交换内存与 cgroup v1 一起使用。

使用 kubeadm 安装支持交换内存的集群

开始之前

此演示需要安装 kubeadm 工具，安装过程按照 kubeadm 安装指南[5]中描述的步骤进行操作。如果节点上已启用交换内存，则可以继续创建集群。如果未启用交换内存，请参阅提供的启用交换内存说明。

创建交换内存文件并开启交换内存功能

我将演示创建 4GiB 的未加密交换内存。

dd if=/dev/zero of=/swapfile bs=128M count=32
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
swapon -s # 仅在该节点被重新启动后启用该交换内存文件

要在引导时启动交换内存文件，请将诸如

/swapfile swap swap defaults 0 0

的内容添加到

/etc/fstab

文件中。

在 Kubernetes 集群中设置开启交换内存的节点

清晰起见，这里给出启用交换内存特性的集群的 kubeadm 配置文件示例

kubeadm-config.yaml

。

---
apiVersion: "kubeadm.k8s.io/v1beta3"
kind: InitConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failSwapOn: false
featureGates:
  NodeSwap: true
memorySwap:
  swapBehavior: LimitedSwap

接下来使用

kubeadm init --config kubeadm-config.yaml

创建单节点集群。 **在初始化过程中，如果 kubelet

failSwapOn

设置为 true，则会出现一条警告，告知节点上启用了交换内存特性。我们计划在未来的版本中删除此警告。**

如何通过 LimitedSwap 确定交换内存限额？

交换内存的配置（包括其局限性）是一项挑战。不仅容易出现配置错误，而且作为系统级属性，任何错误配置都可能危及整个节点而不仅仅是特定的工作负载。为了减轻这种风险并确保节点的健康，我们在交换内存的 Beta 版本中实现了对缺陷的自动配置。

**使用

LimitedSwap

，不属于 Burstable QoS 类别的 Pod（即

BestEffort

Guaranteed

QoS Pod）被禁止使用交换内存。**

BestEffort

QoS Pod 表现出不可预测的内存消耗模式，并且缺乏有关其内存使用情况的信息，因此很难完成交换内存的安全分配。相反，

Guaranteed

QoS Pod 通常用于根据工作负载的设置精确分配资源的应用，其中的内存资源立即可用。为了维持上述安全和节点健康保证，当

LimitedSwap

生效时，这些 Pod 将不允许使用交换内存。

在详细计算交换内存限制之前，有必要定义以下术语：

• nodeTotalMemory：节点上可用的物理内存总量。
• totalPodsSwapAvailable：节点上可供 Pod 使用的交换内存总量（可以保留一些交换内存供系统使用）。
• containerMemoryRequest：容器的内存请求。

**交换内存限制配置为：

(containerMemoryRequest / nodeTotalMemory) × totalPodsSwapAvailable

换句话说，容器能够使用的交换内存量与其内存请求、节点的总物理内存以及节点上可供 Pod 使用的交换内存总量呈比例关系。

值得注意的是，对于 Burstable QoS Pod 中的容器，可以通过设置内存限制与内存请求相同来选择不使用交换内存。以这种方式配置的容器将无法访问交换内存。

此特性如何工作？

我们可以想象可以在节点上使用交换内存的多种可能方式。当节点上提供了交换内存并可用时， SIG 节点建议[6] kubelet 应该能够遵循如下的配置：

• 在交换内存特性被启用时能够启动。
• 默认情况下，kubelet 将指示容器运行时接口（CRI）不为 Kubernetes 工作负载分配交换内存。

节点上的交换内存配置通过 KubeletConfiguration 中的

memorySwap

[7] 向集群管理员公开。作为集群管理员，你可以通过设置

memorySwap.swapBehavior

来指定存在交换内存时节点的行为。

kubelet使用 CRI（容器运行时接口）[8] API 来指示 CRI 配置特定的 cgroup v2 参数（例如

memory.swap.max

），配置方式要支持容器所期望的交换内存配置。接下来，CRI 负责将这些设置写入容器级的 cgroup。

如何对交换内存进行监控？

Alpha 版本的一个显著缺陷是无法监控或检视交换内存的使用情况。这个问题已在 Kubernetes 1.28 引入的 Beta 版本中得到解决，该版本现在提供了通过多种不同方法监控交换内存使用情况的能力。

kubelet 的 Beta 版本现在支持收集节点级指标统计信息[9]，可以通过

/metrics/resource

和

/stats/summary

kubelet HTTP 端点进行访问。这些信息使得客户端能够在使用 LimitedSwap 时直接访问 kubelet 来监控交换内存使用情况和剩余交换内存情况。此外，cadvisor 中还添加了

machine_swap_bytes

指标，以显示机器上总的物理交换内存容量。

注意事项

在系统上提供可用交换内存会降低可预测性。由于交换内存的性能比常规内存差，有时差距甚至在多个数量级，因而可能会导致意外的性能下降。此外，交换内存会改变系统在内存压力下的行为。由于启用交换内存允许 Kubernetes 中的工作负载使用更大的内存量，而这一用量是无法预测的，因此也会增加嘈杂邻居和非预期的装箱配置的风险，因为调度程序无法考虑交换内存使用情况。

启用交换内存的节点的性能取决于底层物理存储。当使用交换内存时，与固态硬盘或 NVMe 等更较快的存储介质相比，在每秒 I/O 操作数（IOPS）受限的环境（例如具有 I/O 限制的云虚拟机）中，性能会明显变差。

**因此，我们不提倡针对有性能约束的工作负载或环境使用交换内存。此外，建议使用

LimitedSwap

，因为这可以显著减轻给节点带来的风险。**

集群管理员和开发人员应该在生产场景中使用交换内存之前对其节点和应用进行基准测试，我们需要你的帮助[10]！

安全风险

在没有加密的系统上启用交换内存会带来安全风险，因为关键信息（例如代表 Kubernetes Secret 的卷）可能会被交换到磁盘[11]。如果未经授权的个人访问磁盘，他们就有可能获得这些机密数据。为了减轻这种风险， Kubernetes 项目强烈建议你对交换内存空间进行加密。但是，处理加密交换内存不是 kubelet 的责任； 相反，它其实是操作系统配置通用问题，应在该级别解决。管理员有责任提供加密交换内存来减轻这种风险。

此外，如前所述，启用