控制节点上的 CPU 管理策略

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

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

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

开始之前

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

• iximiuz Labs
• Killercoda
• KodeKloud

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

如果你运行的是旧版本的 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。这将清除 CPU 管理器维护的状态，以便新策略设置的 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 集合。具有分数 CPU requests 的 Guaranteed Pod 中的容器也运行在共享池中的 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 (GA，默认可见) (1.35 或更高版本)
• prefer-align-cpus-by-uncorecache (GA，默认可见) (1.36 或更高版本)

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

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

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

通过将 prefer-align-cpus-by-uncorecache 添加到 CPUManager 策略选项中，可以启用 prefer-align-cpus-by-uncorecache 选项。如果使用了不兼容的选项，Kubelet 将启动失败，并报错显示在日志中。

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

接下来

• 阅读关于 Pod 级资源管理器 的内容。