节点资源管理器

为了支持延迟敏感型和高吞吐量的工作负载，Kubernetes 提供了一套资源管理器。这些管理器的目标是协调和优化节点的资源分配，以满足配置了特定 CPU、设备和内存（巨页）资源需求的 Pod。

硬件拓扑对齐策略

拓扑管理器 是一个 kubelet 组件，旨在协调负责这些优化的一组组件。整体资源管理过程由您指定的策略控制。要了解更多信息，请阅读控制节点上的拓扑管理策略。

为 Pod 分配 CPU 的策略

一旦 Pod 被绑定到一个节点，该节点上的 kubelet 可能需要复用现有硬件（例如，在多个 Pod 之间共享 CPU）或通过专门分配某些资源来分配硬件（例如，为 Pod 独占使用分配一个或多个 CPU）。

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

然而，在 CPU 缓存亲和性和调度延迟显着影响工作负载性能的工作负载中，kubelet 允许使用替代的 CPU 管理策略来确定节点上的一些放置偏好。这是使用 CPU 管理器及其策略实现的。有两种可用的策略

• none：none 策略显式启用现有的默认 CPU 亲和性方案，除了操作系统调度程序自动执行的操作之外，不提供任何亲和性。使用 CFS 配额强制执行Guaranteed Pod 和Burstable Pod的 CPU 使用限制。
• static：static 策略允许具有整数 CPU requests 的 Guaranteed Pod 中的容器访问节点上的独占 CPU。这种独占性是使用 cpuset cgroup 控制器强制执行的。

CPU 管理器不支持在运行时离线和上线 CPU。

静态策略

静态策略启用更精细的 CPU 管理和独占 CPU 分配。此策略管理一个共享的 CPU 池，该池最初包含节点中的所有 CPU。可独占分配的 CPU 数量等于节点中的 CPU 总数减去 kubelet 配置设置的任何 CPU 预留。这些选项保留的 CPU 以物理核心 ID 的升序从初始共享池中以整数数量获取。此共享池是任何 BestEffort 和 Burstable Pod 中的容器运行的 CPU 集。具有小数 CPU requests 的 Guaranteed Pod 中的容器也在共享池中的 CPU 上运行。只有既是 Guaranteed Pod 的一部分且具有整数 CPU requests 的容器才会分配到独占 CPU。

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

考虑以下 Pod 规约中的容器

spec:
  containers:
  - name: nginx
    image: nginx

上面的 Pod 在 BestEffort QoS 类中运行，因为没有指定资源 requests 或 limits。它在共享池中运行。

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

上面的 Pod 在 Burstable QoS 类中运行，因为资源 requests 不等于 limits，并且未指定 cpu 数量。它在共享池中运行。

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

上面的 Pod 在 Burstable QoS 类中运行，因为资源 requests 不等于 limits。它在共享池中运行。

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。

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 资源的资源限制是一个小数。它在共享池中运行。

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

上面的 Pod 在 Guaranteed QoS 类中运行，因为仅指定了 limits，并且在未明确指定时，requests 设置为等于 limits。并且容器的 CPU 资源的资源限制是一个大于或等于 1 的整数。nginx 容器被授予 2 个独占 CPU。

静态策略选项

可以使用 CPU 管理器策略选项来微调静态策略的行为。以下策略选项适用于静态 CPU 管理策略：{{/* 按字母顺序排列的选项 */}}

align-by-socket（alpha，默认隐藏）

按物理封装/插槽边界对齐 CPU，而不是逻辑 NUMA 边界（自 Kubernetes v1.25 起可用）distribute-cpus-across-cores（alpha，默认隐藏）

在不同的物理内核之间分配虚拟内核（有时称为硬件线程）（自 Kubernetes v1.31 起可用）distribute-cpus-across-numa（alpha，默认隐藏）

将 CPU 分散到不同的 NUMA 域，旨在在选定的域之间实现均匀平衡（自 Kubernetes v1.23 起可用）full-pcpus-only（beta，默认可见）

始终分配完整的物理内核（自 Kubernetes v1.22 起可用）strict-cpu-reservation（alpha，默认隐藏）

防止所有 Pod（无论其服务质量等级如何）在保留的 CPU 上运行（自 Kubernetes v1.32 起可用）prefer-align-cpus-by-uncorecache（alpha，默认隐藏）

以尽力而为的方式按非核心（最后一级）缓存边界对齐 CPU（自 Kubernetes v1.32 起可用）

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

• CPUManagerPolicyBetaOptions（默认启用）。禁用以隐藏 beta 级选项。
• CPUManagerPolicyAlphaOptions（默认禁用）。启用以显示 alpha 级选项。您仍然必须使用 kubelet 配置文件中的 cpuManagerPolicyOptions 字段启用每个选项。

有关您可以配置的各个选项的更多详细信息，请继续阅读。

full-pcpus-only

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

distribute-cpus-across-numa

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

align-by-socket

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

distribute-cpus-across-cores

如果指定了 distribute-cpus-across-cores 策略选项，静态策略将尝试跨不同的物理核心分配虚拟核心（硬件线程）。默认情况下，CPUManager 倾向于将 CPU 打包到尽可能少的物理核心上，这可能会导致同一物理核心上的 CPU 之间发生争用，并导致性能瓶颈。通过启用 distribute-cpus-across-cores 策略，静态策略可确保 CPU 分布在尽可能多的物理核心上，从而减少同一物理核心上的争用，并提高整体性能。但是，重要的是要注意，当系统负载较重时，此策略可能效果不佳。在这种情况下，减少争用的好处会减少。相反，默认行为有助于减少核心间通信开销，从而在负载较高的情况下可能提供更好的性能。

strict-cpu-reservation

KubeletConfiguration 中的 reservedSystemCPUs 参数，或者已弃用的 kubelet 命令行选项 --reserved-cpus，定义了操作系统系统守护程序和 kubernetes 系统守护程序的显式 CPU 集合。有关此参数的更多详细信息，请参见显式保留 CPU 列表页面。默认情况下，此隔离仅针对具有整数 CPU 请求的保证型 Pod 实现，而不适用于突发型和尽力而为型 Pod（以及具有小数 CPU 请求的保证型 Pod）。准入仅将 CPU 请求与可分配的 CPU 进行比较。由于 CPU 限制高于请求，因此默认行为允许突发型和尽力而为型 Pod 占用 reservedSystemCPUs 的容量，并导致主机操作系统服务在实际部署中发生饥饿。如果启用了 strict-cpu-reservation 策略选项，静态策略将不允许任何工作负载使用 reservedSystemCPUs 中指定的 CPU 核心。

prefer-align-cpus-by-uncorecache

如果指定了 prefer-align-cpus-by-uncorecache 策略，静态策略将为各个容器分配 CPU 资源，以便分配给容器的所有 CPU 共享相同的非核心缓存块（也称为末级缓存或 LLC）。默认情况下，CPUManager 将紧密地打包 CPU 分配，这可能导致容器被分配来自多个非核心缓存的 CPU。此选项使 CPUManager 能够以最大化非核心缓存高效使用的方式分配 CPU。分配是在尽力而为的基础上执行的，旨在在同一非核心缓存中关联尽可能多的 CPU。如果容器的 CPU 要求超过单个非核心缓存的 CPU 容量，则 CPUManager 会尽量减少使用的非核心缓存的数量，以保持最佳的非核心缓存对齐。特定的工作负载可以从减少缓存级别的跨缓存延迟和嘈杂邻居中受益。如果 CPUManager 无法在节点具有足够资源的情况下进行最佳对齐，则仍将使用默认的打包行为来允许容器进入。

内存管理策略

Kubernetes 内存管理器 启用了为 Guaranteed QoS 类中的 Pod 提供保证内存（和巨页）分配的功能。

内存管理器采用提示生成协议，为 Pod 提供最合适的 NUMA 亲和性。内存管理器将这些亲和性提示反馈给中央管理器（拓扑管理器）。基于提示和拓扑管理器策略，Pod 将被拒绝或允许进入节点。

此外，内存管理器确保 Pod 请求的内存是从最少数量的 NUMA 节点分配的。

其他资源管理器

各个管理器的配置将在专门的文档中详细说明

• 设备管理器