Kubernetes v1.26 [stable]按照设计，Kubernetes 对 Pod 执行相关的很多方面进行了抽象，使得用户不必关心。然而，为了正常运行，有些工作负载要求在延迟和/或性能方面有更强的保证。为此，kubelet 提供方法来实现更复杂的负载放置策略，同时保持抽象，避免显式的放置指令。
有关资源管理的详细信息，请参阅 Pod 和容器的资源管理文档。
有关 kubelet 如何实现资源管理的详细信息，请参阅节点资源管理文档。
你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：
你的 Kubernetes 服务器版本必须不低于版本 v1.26.要获知版本信息，请输入 kubectl version.
如果你正在运行一个旧版本的 Kubernetes，请参阅与该版本对应的文档。
默认情况下，kubelet 使用 CFS 配额 来执行 Pod 的 CPU 约束。当节点上运行了很多 CPU 密集的 Pod 时，工作负载可能会迁移到不同的 CPU 核，这取决于调度时 Pod 是否被扼制，以及哪些 CPU 核是可用的。许多工作负载对这种迁移不敏感，因此无需任何干预即可正常工作。
然而，有些工作负载的性能明显地受到 CPU 缓存亲和性以及调度延迟的影响。对此，kubelet 提供了可选的 CPU 管理策略，来确定节点上的一些分配偏好。
Kubernetes v1.32 [alpha]（默认禁用）可以通过使用 "WindowsCPUAndMemoryAffinity" 特性门控在 Windows 上启用 CPU 管理器支持。这个能力还需要容器运行时的支持。
CPU 管理策略通过 kubelet 参数 --cpu-manager-policy
或 KubeletConfiguration
中的 cpuManagerPolicy 字段来指定。支持两种策略：
CPU 管理器定期通过 CRI 写入资源更新，以保证内存中 CPU 分配与 cgroupfs 一致。同步频率通过新增的 Kubelet 配置参数 --cpu-manager-reconcile-period 来设置。如果不指定，默认与 --node-status-update-frequency 的周期相同。
Static 策略的行为可以使用 --cpu-manager-policy-options 参数来微调。该参数采用一个逗号分隔的 key=value 策略选项列表。如果你禁用 CPUManagerPolicyOptions
特性门控，则你不能微调 CPU 管理器策略。这种情况下，CPU 管理器仅使用其默认设置运行。
除了顶级的 CPUManagerPolicyOptions 特性门控，策略选项分为两组：Alpha 质量（默认隐藏）和 Beta 质量（默认可见）。这些组分别由 CPUManagerPolicyAlphaOptions 和 CPUManagerPolicyBetaOptions 特性门控来管控。不同于 Kubernetes 标准，这里是由这些特性门控来管控选项组，因为为每个单独选项都添加一个特性门控过于繁琐。
由于 CPU 管理器策略只能在 kubelet 生成新 Pod 时应用，所以简单地从 "none" 更改为 "static"将不会对现有的 Pod 起作用。因此，为了正确更改节点上的 CPU 管理器策略，请执行以下步骤：
/var/lib/kubelet/cpu_manager_state。这将清除 CPUManager 维护的状态，以便新策略设置的 cpu-sets 不会与之冲突。对需要更改其 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
如果节点上的在线 CPU 集发生变化，则必须腾空该节点，并通过删除 kubelet根目录中的状态文件 cpu_manager_state 来手动重置 CPU 管理器。
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 集合。Guaranteed Pod 中的容器，如果声明了非整数值的 CPU requests，也将运行在共享池的 CPU 上。只有 Guaranteed Pod 中，指定了整数型 CPU requests 的容器，才会被分配独占 CPU 资源。
当启用 static 策略时，要求使用 --kube-reserved 和/或 --system-reserved 或--reserved-cpus 来保证预留的 CPU 值大于零。这是因为零预留 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 (Beta, 默认可见) (1.34 或更高版本)可以通过将 full-pcpus-only=true 添加到 CPUManager 策略选项来启用 full-pcpus-only 选项。同样地，可以通过将 distribute-cpus-across-numa=true 添加到 CPUManager 策略选项来启用 distribute-cpus-across-numa 选项。当两者都设置时，它们是“累加的”，因为 CPU 将分布在 NUMA 节点的 full-pcpus 块中，而不是单个核心。可以通过将 align-by-socket=true 添加到 CPUManager 策略选项来启用 align-by-socket 策略选项。同样，也能够将 distribute-cpus-across-numa=true 添加到 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 将无法启动，并在日志中解释所出现的错误。
有关你可以配置的各个选项的行为的模式详细信息，请参阅节点资源管理文档。