控制节点上的 CPU 管理策略

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

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

开始之前

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

• Killercoda
• 使用 Kubernetes

如果您运行的是较旧版本的 Kubernetes，请查看您实际运行的版本的文档。

CPU 管理策略

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

但是，在 CPU 缓存亲和性和调度延迟会显着影响工作负载性能的工作负载中，kubelet 允许使用替代的 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 集不会与它冲突。
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 策略明确启用现有的默认 CPU 亲和性方案，除了操作系统调度程序自动执行的操作之外，不提供任何亲和性。 使用 CFS 配额强制执行 保证型 Pod 和 突发型 Pod 的 CPU 使用限制。

静态策略

static 策略允许具有整数 CPU 请求 的 保证型 Pod 中的容器访问节点上的独占 CPU。这种排他性使用 cpuset cgroup 控制器 强制执行。

此策略管理一个共享的 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 升序获取。 此共享池是在 最佳努力型 和 突发型 Pod 中运行的任何容器的 CPU 集。具有分数 CPU 请求 的 保证型 Pod 中的容器也在共享池中的 CPU 上运行。只有既是 保证型 Pod 的一部分又具有整数 CPU 请求 的容器才会被分配独占 CPU。

当满足静态分配要求的容器的 保证型 Pod 被调度到节点时，CPU 将从共享池中移除并放置到容器的 cpuset 中。CFS 配额不用于限制这些容器的 CPU 使用率，因为它们的用法受调度域本身限制。换句话说，容器 cpuset 中的 CPU 数量等于 Pod 规范中指定的整数 CPU 限制。 这种静态分配提高了 CPU 亲和性，并减少了由于 CPU 密集型工作负载的节流而导致的上下文切换。

考虑以下 Pod 规范中的容器

spec:
  containers:
  - name: nginx
    image: nginx

此 Pod 在 最佳努力型 QoS 类中运行，因为没有指定资源 请求 或 限制。它在共享池中运行。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

此 Pod 在 突发型 QoS 类中运行，因为资源 请求 不等于 限制，并且未指定 cpu 数量。它在共享池中运行。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "100Mi"
        cpu: "1"

此 Pod 在 突发型 QoS 类中运行，因为资源 请求 不等于 限制。它在共享池中运行。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"

此 Pod 在 保证型 QoS 类中运行，因为 请求 等于 限制。并且容器的 CPU 资源资源限制为大于或等于 1 的整数。nginx 容器被授予 2 个独占 CPU。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "1.5"
      requests:
        memory: "200Mi"
        cpu: "1.5"

此 Pod 在 保证型 QoS 类中运行，因为 请求 等于 限制。但容器的 CPU 资源资源限制为分数。它在共享池中运行。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"

此 Pod 在 保证型 QoS 类中运行，因为只指定了 限制，并且在未显式指定的情况下，请求 设置为等于 限制。并且容器的 CPU 资源资源限制为大于或等于 1 的整数。nginx 容器被授予 2 个独占 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 或更高版本）

如果指定了full-pcpus-only策略选项，静态策略将始终分配完整的物理核心。默认情况下，如果没有此选项，静态策略将使用拓扑感知的最佳拟合分配来分配 CPU。在启用 SMT 的系统上，策略可以分配单个虚拟核心，这些核心对应于硬件线程。这会导致不同的容器共享相同的物理核心；这种行为反过来会导致噪声邻居问题。启用此选项后，只有在所有容器的 CPU 请求都可以通过分配完整的物理核心来满足时，pod 才会被 kubelet 接收。如果 pod 未通过接收，它将被置于 Failed 状态，并显示消息SMTAlignmentError。

如果指定了distribute-cpus-across-numa策略选项，静态策略将在需要多个 NUMA 节点来满足分配的情况下，将 CPU 均匀分布到 NUMA 节点。默认情况下，CPUManager 将 CPU 打包到一个 NUMA 节点，直到它被填满，任何剩余的 CPU 都会简单地溢出到下一个 NUMA 节点。这会导致依赖于屏障（以及类似同步原语）的并行代码出现不必要的瓶颈，因为这种类型的代码往往只运行得和其最慢的 worker 一样快（由于至少在一个 NUMA 节点上可用 CPU 较少而导致速度变慢）。通过将 CPU 均匀分布到 NUMA 节点，应用程序开发人员可以更轻松地确保没有单个 worker 比其他 worker 更受 NUMA 影响，从而提高这些类型应用程序的整体性能。

如果指定了align-by-socket策略选项，在决定如何将 CPU 分配给容器时，CPU 将被视为在套接字边界对齐。默认情况下，CPUManager 在 NUMA 边界对齐 CPU 分配，如果需要从多个 NUMA 节点中提取 CPU 来满足分配，这可能会导致性能下降。虽然它试图确保所有 CPU 都从最少数量的 NUMA 节点分配，但不能保证这些 NUMA 节点位于同一个套接字上。通过指示CPUManager 在套接字边界而不是 NUMA 边界显式对齐 CPU，我们可以避免此类问题。请注意，此策略选项与TopologyManager single-numa-node 策略不兼容，并且不适用于套接字数量大于 NUMA 节点数量的硬件。

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