你正在查看的文档所针对的是 Kubernetes 版本： v1.29

Kubernetes v1.29 版本的文档已不再维护。你现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击 最新版本。

Kubernetes 1.28：在 Linux 上使用交换内存的 Beta 支持

作者：Itamar Holder (Red Hat)

译者：Wilson Wu (DaoCloud)

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

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

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

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

如何使用此特性？

通过激活 kubelet 上的 NodeSwap 特性门控，可以在已配置交换内存的节点上使用此特性。 此外，你必须禁用 failSwapOn 设置，或者停用已被弃用的 --fail-swap-on 命令行标志。

可以配置 memorySwap.swapBehavior 选项来定义节点使用交换内存的方式。例如：

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

swapBehavior 的可用配置选项有：

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

如果未指定 memorySwap 的配置并且启用了特性门控，则默认情况下， kubelet 将应用与 UnlimitedSwap 设置相同的行为。

请注意，仅 cgroup v2 支持 NodeSwap。针对 Kubernetes v1.28，不再支持将交换内存与 cgroup v1 一起使用。

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

开始之前

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

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

我将演示创建 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 节点建议 kubelet 应该能够遵循如下的配置：

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

节点上的交换内存配置通过 KubeletConfiguration 中的 memorySwap 向集群管理员公开。 作为集群管理员，你可以通过设置 memorySwap.swapBehavior 来指定存在交换内存时节点的行为。

kubelet 使用 CRI （容器运行时接口）API 来指示 CRI 配置特定的 cgroup v2 参数（例如 memory.swap.max）， 配置方式要支持容器所期望的交换内存配置。接下来，CRI 负责将这些设置写入容器级的 cgroup。

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

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

kubelet 的 Beta 版本现在支持收集节点级指标统计信息， 可以通过 /metrics/resource 和 /stats/summary kubelet HTTP 端点进行访问。 这些信息使得客户端能够在使用 LimitedSwap 时直接访问 kubelet 来监控交换内存使用情况和剩余交换内存情况。 此外，cadvisor 中还添加了 machine_swap_bytes 指标，以显示机器上总的物理交换内存容量。

注意事项

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

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

因此，我们不提倡针对有性能约束的工作负载或环境使用交换内存。 此外，建议使用 LimitedSwap，因为这可以显著减轻给节点带来的风险。

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

安全风险

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

此外，如前所述，启用 LimitedSwap 模式时，用户可以选择通过设置内存限制与内存请求相同来完全禁止容器使用交换内存。 这种设置会阻止相应的容器访问交换内存。

展望未来

Kubernetes 1.28 版本引入了对 Linux 节点上交换内存的 Beta 支持， 我们将继续为这项特性的正式发布而努力。 我希望这将包括：

  • 添加根据 kubelet 在主机上检测到的内容来设置系统预留交换内存量的功能。
  • 添加对通过 cgroup 在 Pod 级别控制交换内存用量的支持。
    • 这一点仍在讨论中。
  • 收集测试用例的反馈。
    • 我们将考虑引入新的交换内存配置模式，例如在节点层面为工作负载设置交换内存限制。

如果进一步学习？

你可以查看当前文档以了解如何在 Kubernetes 中使用交换内存。

如需了解更多信息，以及协助测试和提供反馈，请参阅 KEP-2400 及其设计提案。

参与其中

随时欢迎你的反馈！SIG Node 定期举行会议并可以通过 Slack（#sig-node 频道） 或 SIG 的 邮件列表 进行联系。 Slack 还提供了专门讨论交换内存的 #sig-node-swap 频道。

如果你想提供帮助或提出进一步的问题，请随时联系 Itamar Holder（Slack 和 GitHub 账号为 @iholder101）。