控制节点上的 CPU 管理策略

Kubernetes 将 Pod 在节点上执行的许多方面对用户进行了抽象。这是有意为之的。然而，一些工作负载需要更强的延迟和/或性能保证才能正常运行。kubelet 提供了启用更复杂的工作负载放置策略的方法，同时保持抽象不受显式放置指令的影响。

有关资源管理的详细信息，请参阅 Pod 和容器的资源管理文档。

有关 kubelet 如何实现资源管理的详细信息，请参阅 节点资源管理器文档。

准备工作

你需要拥有一个 Kubernetes 集群，并且 kubectl 命令行工具已配置为与你的集群通信。建议在至少有两个不是控制平面主机的节点上运行本教程。如果你还没有集群，可以使用 minikube 创建一个，或者使用这些 Kubernetes 游乐场之一

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

要检查版本，请输入 kubectl version。

如果你运行的是旧版本的 Kubernetes，请查阅你实际运行的版本的文档。

配置 CPU 管理策略

默认情况下，kubelet 使用 CFS 配额来强制执行 Pod CPU 限制。当节点运行许多 CPU 密集型 Pod 时，工作负载可能会移动到不同的 CPU 核心，具体取决于 Pod 是否受到限制以及在调度时哪些 CPU 核心可用。许多工作负载对这种迁移不敏感，因此无需任何干预即可正常运行。

然而，在 CPU 缓存亲和性和调度延迟显著影响工作负载性能的工作负载中，kubelet 允许使用替代的 CPU 管理策略来确定节点上的一些放置偏好。

Windows 支持

CPU 管理器支持可以在 Windows 上通过使用 WindowsCPUAndMemoryAffinity 功能门启用，并且它需要容器运行时中的支持。一旦功能门启用，请按照以下步骤配置 CPU 管理器策略。

配置

CPU 管理器策略通过 --cpu-manager-policy kubelet 标志或 KubeletConfiguration 中的 cpuManagerPolicy 字段设置。有两种支持的策略

• none：默认策略。
• static：允许具有特定资源特征的 Pod 在节点上获得更高的 CPU 亲和性和独占性。

CPU 管理器通过 CRI 定期写入资源更新，以协调内存中的 CPU 分配与 cgroupfs。协调频率通过新的 Kubelet 配置值 --cpu-manager-reconcile-period 设置。如果未指定，则默认为与 --node-status-update-frequency 相同的持续时间。

可以通过 --cpu-manager-policy-options 标志对静态策略的行为进行微调。该标志接受逗号分隔的 key=value 策略选项列表。如果禁用 CPUManagerPolicyOptions 功能门，则无法微调 CPU 管理器策略。在这种情况下，CPU 管理器仅使用其默认设置运行。

除了顶级 CPUManagerPolicyOptions 功能门之外，策略选项分为两组：alpha 质量（默认隐藏）和 beta 质量（默认可见）。这些组分别由 CPUManagerPolicyAlphaOptions 和 CPUManagerPolicyBetaOptions 功能门守护。与 Kubernetes 标准不同，这些功能门守护着选项组，因为为每个单独的选项添加功能门会过于繁琐。

更改 CPU 管理器策略

由于 CPU 管理器策略只能在 kubelet 启动新 Pod 时应用，因此简单地从“none”更改为“static”不会应用于现有 Pod。因此，为了正确更改节点上的 CPU 管理器策略，请执行以下步骤

1. 排空节点。
2. 停止 kubelet。
3. 删除旧的 CPU 管理器状态文件。此文件的路径默认为 /var/lib/kubelet/cpu_manager_state。这会清除 CPUManager 维护的状态，以便新策略设置的 cpu-sets 不会与它冲突。
4. 编辑 kubelet 配置以将 CPU 管理器策略更改为所需值。
5. 启动 kubelet。

对所有需要更改 CPU 管理器策略的节点重复此过程。跳过此过程将导致 kubelet 因以下错误而崩溃

could not restore state from checkpoint: configured policy "static" differs from state checkpoint policy "none", please drain this node and delete the CPU manager checkpoint file "/var/lib/kubelet/cpu_manager_state" before restarting Kubelet

none 策略配置

此策略没有额外的配置项。

static 策略配置

此策略管理一个共享的 CPU 池，该池最初包含节点中的所有 CPU。独占可分配的 CPU 数量等于节点中的 CPU 总数减去 kubelet --kube-reserved 或 --system-reserved 选项保留的任何 CPU。从 1.17 开始，CPU 保留列表可以通过 kubelet --reserved-cpus 选项显式指定。由 --reserved-cpus 指定的显式 CPU 列表优先于由 --kube-reserved 和 --system-reserved 指定的 CPU 保留。这些选项保留的 CPU 将以整数形式从初始共享池中按物理核心 ID 升序获取。此共享池是任何 BestEffort 和 Burstable Pod 中的容器运行的 CPU 集。Guaranteed Pod 中具有分数 CPU requests 的容器也在共享池中的 CPU 上运行。只有同时属于 Guaranteed Pod 且具有整数 CPU requests 的容器才被分配独占 CPU。

静态策略选项

你可以使用以下特性门控根据其成熟度级别来开启或关闭选项组：

• CPUManagerPolicyBetaOptions 默认启用。禁用以隐藏 Beta 级选项。
• CPUManagerPolicyAlphaOptions 默认禁用。启用以显示 Alpha 级选项。你仍然需要使用 CPUManagerPolicyOptions kubelet 选项启用每个选项。

静态 CPUManager 策略存在以下策略选项

• full-pcpus-only (GA，默认可见) (1.33 或更高版本)
• distribute-cpus-across-numa (beta，默认可见) (1.33 或更高版本)
• align-by-socket (alpha，默认隐藏) (1.25 或更高版本)
• distribute-cpus-across-cores (alpha，默认隐藏) (1.31 或更高版本)
• strict-cpu-reservation (beta，默认可见) (1.32 或更高版本)
• prefer-align-cpus-by-uncorecache (beta，默认可见) (1.34 或更高版本)

可以通过在 CPUManager 策略选项中添加 full-pcpus-only=true 来启用 full-pcpus-only 选项。同样，可以通过在 CPUManager 策略选项中添加 distribute-cpus-across-numa=true 来启用 distribute-cpus-across-numa 选项。当两者都设置时，它们是“累加的”，这意味着 CPU 将以完整的物理 CPU 块而非单个核心的方式在 NUMA 节点之间分布。align-by-socket 策略选项可以通过向 CPUManager 策略选项中添加 align-by-socket=true 来启用。它也与 full-pcpus-only 和 distribute-cpus-across-numa 策略选项累加。

可以通过将 distribute-cpus-across-cores=true 添加到 CPUManager 策略选项来启用 distribute-cpus-across-cores 选项。目前，它不能与 full-pcpus-only 或 distribute-cpus-across-numa 策略选项一起使用。

可以通过在 CPUManager 策略选项中添加 strict-cpu-reservation=true 来启用 strict-cpu-reservation 选项，然后删除 /var/lib/kubelet/cpu_manager_state 文件并重新启动 kubelet。

可以通过将 prefer-align-cpus-by-uncorecache 添加到 CPUManager 策略选项来启用 prefer-align-cpus-by-uncorecache 选项。如果使用了不兼容的选项，kubelet 将因日志中解释的错误而无法启动。

有关你可以配置的各个选项行为的更多详细信息，请参阅 节点资源管理器文档。