控制节点上的 CPU 管理策略

Kubernetes 将 Pod 在节点上执行的许多方面对用户进行了抽象。这是刻意设计的。但是，某些工作负载需要更强的延迟和/或性能保证才能正常运行。kubelet 提供了启用更复杂的工作负载放置策略的方法，同时保持抽象性，避免显式放置指令。

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

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

开始之前

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

• Killercoda
• 使用 Kubernetes 进行练习

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

配置 CPU 管理策略

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

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

Windows 支持

可以使用 WindowsCPUAndMemoryAffinity 特性门控在 Windows 上启用 CPU 管理器支持，并且它需要在容器运行时中提供支持。启用特性门控后，请按照以下步骤配置 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 进入 crashlooping，并出现以下错误

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 开始，可以使用 kubelet --reserved-cpus 选项显式指定 CPU 预留列表。--reserved-cpus 指定的显式 CPU 列表优先于 --kube-reserved 和 --system-reserved 指定的 CPU 预留。 这些选项预留的 CPU 以整数数量按物理核心 ID 升序从初始共享池中获取。此共享池是 BestEffort 和 Burstable Pod 中的任何容器运行的 CPU 集。具有小数 CPU 请求的 Guaranteed Pod 中的容器也运行在共享池中的 CPU 上。 只有属于 Guaranteed Pod 且具有整数 CPU 请求的容器才会被分配独占 CPU。

静态策略选项

你可以根据以下特性门控的成熟度级别来切换选项组的开启和关闭

• CPUManagerPolicyBetaOptions 默认启用。禁用以隐藏 beta 级别的选项。
• CPUManagerPolicyAlphaOptions 默认禁用。启用以显示 alpha 级别的选项。您仍然需要使用 CPUManagerPolicyOptions kubelet 选项启用每个选项。

以下是静态 CPUManager 策略的可用策略选项：

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

可以通过向 CPUManager 策略选项添加 full-pcpus-only=true 来启用 full-pcpus-only 选项。同样，可以通过向 CPUManager 策略选项添加 distribute-cpus-across-numa=true 来启用 distribute-cpus-across-numa 选项。当两者都设置时，它们是“累加”的，即 CPU 将以完整物理 CPU (full-pcpus) 为单位分发到 NUMA 节点上，而不是单个核心。可以通过向 CPUManager 策略选项添加 align-by-socket=true 来启用 align-by-socket 策略选项。它也是 full-pcpus-only 和 distribute-cpus-across-numa 策略选项的累加。

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

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

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

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