diff --git a/content/zh-cn/docs/tasks/administer-cluster/cpu-management-policies.md b/content/zh-cn/docs/tasks/administer-cluster/cpu-management-policies.md index 95c9c914bd..0883bc1def 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/cpu-management-policies.md +++ b/content/zh-cn/docs/tasks/administer-cluster/cpu-management-policies.md @@ -36,10 +36,16 @@ directives. For detailed information on resource management, please refer to the [Resource Management for Pods and Containers](/docs/concepts/configuration/manage-resources-containers) documentation. + +For detailed information on how the kubelet implements resource management, please refer to the +[Node ResourceManagers](/docs/concepts/policy/node-resource-managers) documentation. --> 有关资源管理的详细信息， 请参阅 [Pod 和容器的资源管理](/zh-cn/docs/concepts/configuration/manage-resources-containers)文档。 +有关 kubelet 如何实现资源管理的详细信息， +请参阅[节点资源管理](/zh-cn/docs/concepts/policy/node-resource-managers)文档。 + ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -52,7 +58,7 @@ If you are running an older version of Kubernetes, please look at the documentat -## CPU 管理策略 {#cpu-management-policies} +## 配置 CPU 管理策略 {#cpu-management-policies} 默认情况下，kubelet 使用 [CFS 配额](https://en.wikipedia.org/wiki/Completely_Fair_Scheduler) 来执行 Pod 的 CPU 约束。 @@ -77,6 +83,22 @@ management policies to determine some placement preferences on the node. 然而，有些工作负载的性能明显地受到 CPU 缓存亲和性以及调度延迟的影响。 对此，kubelet 提供了可选的 CPU 管理策略，来确定节点上的一些分配偏好。 + +## Windows 支持 + +{{< feature-state feature_gate_name="WindowsCPUAndMemoryAffinity" >}} + +可以通过使用 "WindowsCPUAndMemoryAffinity" 特性门控在 Windows 上启用 CPU 管理器支持。 +这个能力还需要容器运行时的支持。 + -### none 策略 {#none-policy} - -`none` 策略显式地启用现有的默认 CPU 亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。 -通过 CFS 配额来实现 [Guaranteed Pods](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/) -和 [Burstable Pods](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/) -的 CPU 使用限制。 - - -### static 策略 {#static-policy} - -`static` 策略针对具有整数型 CPU `requests` 的 `Guaranteed` Pod， -它允许该类 Pod 中的容器访问节点上的独占 CPU 资源。这种独占性是使用 -[cpuset cgroup 控制器](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt)来实现的。 - {{< note >}} -诸如容器运行时和 kubelet 本身的系统服务可以继续在这些独占 CPU 上运行。独占性仅针对其他 Pod。 -{{< /note >}} - -{{< note >}} - -CPU 管理器不支持运行时下线和上线 CPU。此外，如果节点上的在线 CPU 集合发生变化， -则必须驱逐节点上的 Pod，并通过删除 kubelet 根目录中的状态文件 `cpu_manager_state` -来手动重置 CPU 管理器。 +如果节点上的在线 CPU 集发生变化，则必须腾空该节点，并通过删除 kubelet +根目录中的状态文件 `cpu_manager_state` 来手动重置 CPU 管理器。 {{< /note >}} +#### `none` 策略配置 + +该策略没有额外的配置项。 + + +#### `static` 策略配置 + 此策略管理一个 CPU 共享池，该共享池最初包含节点上所有的 CPU 资源。 可独占性 CPU 资源数量等于节点的 CPU 总量减去通过 kubelet `--kube-reserved` 或 `--system-reserved` 参数保留的 CPU 资源。 @@ -265,149 +260,7 @@ pool to become empty. {{< /note >}} -当 `Guaranteed` Pod 调度到节点上时，如果其容器符合静态分配要求， -相应的 CPU 会被从共享池中移除，并放置到容器的 cpuset 中。 -因为这些容器所使用的 CPU 受到调度域本身的限制，所以不需要使用 CFS 配额来进行 CPU 的绑定。 -换言之，容器 cpuset 中的 CPU 数量与 Pod 规约中指定的整数型 CPU `limit` 相等。 -这种静态分配增强了 CPU 亲和性，减少了 CPU 密集的工作负载在节流时引起的上下文切换。 - -考虑以下 Pod 规格的容器： - -```yaml -spec: - containers: - - name: nginx - image: nginx -``` - - -上例的 Pod 属于 `BestEffort` QoS 类，因为其未指定 `requests` 或 `limits` 值。 -所以该容器运行在共享 CPU 池中。 - -```yaml -spec: - containers: - - name: nginx - image: nginx - resources: - limits: - memory: "200Mi" - requests: - memory: "100Mi" -``` - - -上例的 Pod 属于 `Burstable` QoS 类，因为其资源 `requests` 不等于 `limits`，且未指定 `cpu` 数量。 -所以该容器运行在共享 CPU 池中。 - -```yaml -spec: - containers: - - name: nginx - image: nginx - resources: - limits: - memory: "200Mi" - cpu: "2" - requests: - memory: "100Mi" - cpu: "1" -``` - - -上例的 Pod 属于 `Burstable` QoS 类，因为其资源 `requests` 不等于 `limits`。 -所以该容器运行在共享 CPU 池中。 - -```yaml -spec: - containers: - - name: nginx - image: nginx - resources: - limits: - memory: "200Mi" - cpu: "2" - requests: - memory: "200Mi" - cpu: "2" -``` - - -上例的 Pod 属于 `Guaranteed` QoS 类，因为其 `requests` 值与 `limits` 相等。 -同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。 -所以，该 `nginx` 容器被赋予 2 个独占 CPU。 - -```yaml -spec: - containers: - - name: nginx - image: nginx - resources: - limits: - memory: "200Mi" - cpu: "1.5" - requests: - memory: "200Mi" - cpu: "1.5" -``` - - -上例的 Pod 属于 `Guaranteed` QoS 类，因为其 `requests` 值与 `limits` 相等。 -但是容器对 CPU 资源的限制值是一个小数。所以该容器运行在共享 CPU 池中。 - -```yaml -spec: - containers: - - name: nginx - image: nginx - resources: - limits: - memory: "200Mi" - cpu: "2" -``` - - -上例的 Pod 属于 `Guaranteed` QoS 类，因其指定了 `limits` 值，同时当未显式指定时， -`requests` 值被设置为与 `limits` 值相等。 -同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。 -所以，该 `nginx` 容器被赋予 2 个独占 CPU。 - - -#### Static 策略选项 +#### Static 策略选项 {#cpu-policy-static--options} 你可以使用以下特性门控根据成熟度级别打开或关闭选项组： * `CPUManagerPolicyBetaOptions` 默认启用。禁用以隐藏 beta 级选项。 @@ -433,96 +288,8 @@ The following policy options exist for the static `CPUManager` policy: * `distribute-cpus-across-numa`（Alpha，默认隐藏）（1.23 或更高版本） * `align-by-socket`（Alpha，默认隐藏）（1.25 或更高版本） * `distribute-cpus-across-cores` (Alpha，默认隐藏) (1.31 或更高版本) - - -如果使用 `full-pcpus-only` 策略选项，static 策略总是会分配完整的物理核心。 -默认情况下，如果不使用该选项，static 策略会使用拓扑感知最适合的分配方法来分配 CPU。 -在启用了 SMT 的系统上，此策略所分配是与硬件线程对应的、独立的虚拟核。 -这会导致不同的容器共享相同的物理核心， -该行为进而会导致[吵闹的邻居问题](https://en.wikipedia.org/wiki/Cloud_computing_issues#Performance_interference_and_noisy_neighbors)。 - -启用该选项之后，只有当一个 Pod 里所有容器的 CPU 请求都能够分配到完整的物理核心时， -kubelet 才会接受该 Pod。 -如果 Pod 没有被准入，它会被置于 Failed 状态，错误消息是 `SMTAlignmentError`。 - - -如果使用 `distribute-cpus-across-numa` 策略选项， -在需要多个 NUMA 节点来满足分配的情况下， -static 策略会在 NUMA 节点上平均分配 CPU。 -默认情况下，`CPUManager` 会将 CPU 分配到一个 NUMA 节点上，直到它被填满， -剩余的 CPU 会简单地溢出到下一个 NUMA 节点。 -这会导致依赖于同步屏障（以及类似的同步原语）的并行代码出现不期望的瓶颈， -因为此类代码的运行速度往往取决于最慢的工作线程 -（由于至少一个 NUMA 节点存在可用 CPU 较少的情况，因此速度变慢）。 -通过在 NUMA 节点上平均分配 CPU， -应用程序开发人员可以更轻松地确保没有某个工作线程单独受到 NUMA 影响， -从而提高这些类型应用程序的整体性能。 - - -如果指定了 `align-by-socket` 策略选项，那么在决定如何分配 CPU 给容器时，CPU 将被视为在 CPU 的插槽边界对齐。 -默认情况下，`CPUManager` 在 NUMA 边界对齐 CPU 分配，如果需要从多个 NUMA 节点提取出 CPU 以满足分配，将可能会导致系统性能下降。 -尽管该默认策略试图确保从 NUMA 节点的**最小**数量分配所有 CPU，但不能保证这些 NUMA 节点将位于同一个 CPU 的插槽上。 -通过指示 `CPUManager` 在 CPU 的插槽边界而不是 NUMA 边界显式对齐 CPU，我们能够避免此类问题。 -注意，此策略选项不兼容 `TopologyManager` 与 `single-numa-node` 策略，并且不适用于 CPU 的插槽数量大于 NUMA 节点数量的硬件。 - - -如果指定了 `distribute-cpus-across-cores` 策略选项， -静态策略将尝试将虚拟核（硬件线程）分配到不同的物理核上。默认情况下， -`CPUManager` 倾向于将 CPU 打包到尽可能少的物理核上， -这可能导致同一物理核上的 CPU 争用，从而导致性能瓶颈。 -启用 `distribute-cpus-across-cores` 策略后，静态策略将确保 CPU 尽可能分布在多个物理核上， -从而减少同一物理核上的争用，提升整体性能。然而，需要注意的是，当系统负载较重时， -这一策略的效果可能会减弱。在这种情况下，减少争用的好处会减少。 -相反，默认行为可以帮助减少跨核的通信开销，在高负载条件下可能会提供更好的性能。 +* `strict-cpu-reservation` (Alpha，默认隐藏) (1.32 或更高版本) +* `prefer-align-cpus-by-uncorecache` (Alpha, 默认隐藏) (1.32 或更高版本) 可以通过将 `distribute-cpus-across-cores=true` 添加到 `CPUManager` 策略选项中来启用 `distribute-cpus-across-cores` 选项。 -当前，该选项不能与 `full-pcpus-only` 或 `distribute-cpus-across-numa` 策略选项同时使用。 \ No newline at end of file +当前，该选项不能与 `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 将无法启动，并在日志中解释所出现的错误。 + +有关你可以配置的各个选项的行为的模式详细信息，请参阅[节点资源管理](/zh-cn/docs/concepts/policy/node-resource-managers)文档。