K8S 容器独占 CPU（CPU 绑核）最佳实践，解锁极致性能所需的 3 个核心条件及其代价

你是否遇到过这类场景：一个至关重要的数据 Pod，明明申请了足够的 CPU 资源，可实际运行起来，因为频繁的 OS 上下文切换和跨核心的 Cache Miss，延迟始终降不下来？又或者，你跑的是高频交易系统、NFV 网元，或者需要对延迟极度敏感的那一小撮尖刺型应用，结果被 Linux CFS 默认的调度策略搞得偷偷抖动，甚至"飘"到了远程 NUMA 节点上取内存数据？

CPU 管理器（CPU Manager）就是为了解决这个问题而生的。

读完本文你将能：

1. 清晰地判断：你的业务到底该不该用 static CPU Manager。
2. 自动化操作：把整一套配置步骤吃透，直接复制生产环境的 Pod 配置。
3. 提前踩坑：了解启用了 CPU 独占特性后，在运维侧会产生的代价和必须进行的"堵漏"操作。
4. 增加点谈资：Get 到几个能唬住人的隐藏参数（比如最新的跨核分发选项）。

---

一、场景与前置：你确定你需要这个吗？

先泼盆冷水。

我们维护的绝大多数 Web 应用、中间件（哪怕是高并发的 API 网关）其实完全不需要 CPU 绑核。默认的 Linux CFS 调度器加上正常的 requests/limits 对它们来说足够友好，甚至更优。但是，如果你的 Pod 具备以下特征之一，就可以考虑引入静态策略了：

• 对 CPU 限流极度敏感（比如性能一掉就触发熔断的）。
• 对上下文切换开销极其反感（比如 DPDK 应用、 Envoy Cilium Agent、Redis 高负载场景）。
• Pod 内部署的是老式遗留应用，写死了启动线程数等于整机物理核心数，而不读取容器限制。

当然，不建议在以下场景中使用：

• CPU 超卖环境：绑核的独占特性与超卖的资源共享模型完全不兼容，会造成严重的资源浪费并干扰超卖调度逻辑。
• 通用型或 I/O 密集型应用：绝大多数 Web 服务和中间件对核心切换不敏感，没必要搞这么复杂。

二、原理：一句话讲清楚

在 Kubernetes v1.26 及更高版本中，CPU Manager 特性已经是 Stable/GA 状态，默认启用。

• 策略 none：也就是默认值。cpuset 包含了所有的核心，进程在各个核心之间"飘来飘去"，使用 CFS 配额控制 CPU Limit。
• 策略 static：专门给 Guaranteed QoS 且 CPU request 整数 核心的 Pod 用的。
  当 kubelet 遇到这样的 Pod，会直接从共享池中抽出整数个核心永久分配给 Pod，并且在 /var/lib/kubelet/cpu_manager_state 中记录状态。注意，系统守护进程依然可以在这些独占核心上运行，但其他 Pod 就不行了。

三、4 步实现独占 CPU 核心（生产级可复现）

重要提示：这部分操作要在 Worker Node 上改 kubelet 配置文件，会重启 kubelet，需要提前做好节点驱逐（cordon/drain）。

步骤 1：配置 Worker Node 的 kubelet

登录到目标 Worker 节点，编辑 /var/lib/kubelet/config.yaml：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
# 开启静态策略
cpuManagerPolicy: static
# 关键：必须保留至少一个 CPU 给系统进程
# 写法一（推荐 1.17+）：--reserved-cpus=0-1
reservedSystemCPUs: "0-1"
# 或者用 kubeReserved + systemReserved 凑（更早期写法）

彩蛋 1 ：千万别忘了设 reservedSystemCPUs。CPU Manager 静态策略要求保留 CPU 数必须大于 0，不然 kubelet 会拒绝启动，逻辑是 CPU 预留为零会导致共享池被抽干。

重启 kubelet：

# 建议先驱逐节点，再操作
systemctl restart kubelet

步骤 2：确认节点生效

执行：

cat /var/lib/kubelet/cpu_manager_state

典型输出：

{"policyName":"static","defaultCpuSet":"2-15,17-31,34-47,49-63","checksum":4141502832}

里面 defaultCpuSet 对应的就是分配给普通 Pod 的共享池。

步骤 3：编写 Pod（关键约束）

你必须在 Pod 中满足：

1. 每个容器的 requests == limits。
2. CPU 的资源量必须是整数（比如 2、4、8），不能有毫核（500m）。
3. requests 和 limits 包含 memory 且数值相同，以触发 Guaranteed QoS。

下面是具体的 YAML 文件内容：

apiVersion: v1
kind: Pod
metadata:
  name: exclusive-cpu-demo
spec:
  containers:
  - name: main-app
    image: busybox:1.28
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo 'running'; sleep 10; done"]
    resources:
      requests:
        cpu: 2
        memory: "1Gi"
      limits:
        cpu: 2
        memory: "1Gi"
  nodeSelector:
    kubernetes.io/hostname: <你的工T作节点名>

步骤 4：验证是否真正独占

进入 Pod 或通过节点系统查看：

# 获取容器 ID
kubectl get pod exclusive-cpu-demo -o yaml | grep containerID

# 登录节点，查看 cpuset
cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod[POD-UID].slice/<容器ID>/cpuset.cpus

输出类似：

4-5

表示这 2 个 CPU 核心已经全部划归此 Pod 独占。容器内的所有进程将永远只能在这两个核上跑。

注意 ：上面通过 cgroup v2 路径查看绑核情况是最精确的方式，但不同操作系统或容器运行时（runc、containerd、cri-o）的 cgroup 路径可能存在差异。如果找不到，可以直接在节点上通过 top 按 1 看 CPU 核心负载分布，或者用 ps -o pid,psr,comm -p <PID> 来确认。

四、适用场景与副作用

1. 适用场景

• 网络数据平面（DPDK、Envoy）：避免 Cache Miss，实现确定性低延迟。
• CPU 敏感的 AI/ML 推理：多核心之间频繁共享 L3 缓存容易造成性能波动，绑核能显著降低抖动。
• 高性能数据库与内存存储：比如大数据分析任务、科学计算、金融证券超低延时交易。
• 遗留应用适配：部分老应用启动时读取节点总 CPU 核心数，导致线程池超配严重，可用绑核"矫正"资源视图。

注意，原生的 kube-scheduler 在做节点选择时不知道 核心的 NUMA 布局，如果你有多 NUMA 跨 Socket 场景，可能还需要一并开启拓扑管理器（Topology Manager）。

2. 副作用：运维必须面对的真相

副作用我分成三类，每一类都需要你对齐团队预期、改掉自动化脚本。

① 资源碎片与浪费

• 一旦某个 CPU 核心被绑定分配给 Guaranteed Pod，它就永远从共享池中消失了。当这个 Pod 销毁后，核心才能丢回共享池。
• 如果你有很多 request: 1 的 Pod 并发创建销毁，CPU 管理器会优先紧凑打包分配，可能导致 CPU 集合严重碎片化，导致后面那些请求大整数 CPU 的 Pod 分配不出完整物理核而失败。

② 调度弹性下降

• Pod 扩容时，如果你的节点只剩下 5 个 CPU 核，而你请求的是 6 核------会调度失败。很可能并没有其他节点能容纳 6 核的 Pod，导致整个应用卡死卡扩容。
• 生产经验：绑定核心的应用的 CPU 利用率你要更敏感地监控，防止几个核心饱和后性能急剧下降。踩过的坑是对 CPU 管理器特性的性能红利很满意，但次月因为碎片化太多，扩容完全起不动新的独占 Pod。

补充一句 ：如果你在节点层面还启用了full-pcpus-only策略选项，static 策略会强制分配完整物理核心（而不是超线程的逻辑核），这对降低跨核冲突有帮助，但同时会进一步加剧碎片化问题。在启用之前，务必评估节点 CPU 拓扑和业务并发量。

③ 运维动作变复杂

• 节点扩/缩容 ：当你需要调整节点规格（比如给云服务器升配 CPU），配置 static 策略的节点会拒绝拉起新 Pod 。原因是 /var/lib/kubelet/cpu_manager_state 里还残留旧的 CPU 拓扑信息。解决方案是节点下线后手动删除 cpu_manager_state 并重启 kubelet。
• 不要热插拔 CPU ：Kubernetes 官方明确声明不支持运行时动态 offlining/onlining CPU，节点 CPU 在线变更后必须 Drain 节点、删除状态文件、重启 kubelet 才能恢复正常。
• 与 sidecar 的冲突：直到 Kubernetes v1.36 才引入 Pod 级别的 Resource Managers 来解决这个问题，此前如果要为业务容器绑定独占核心，就需要给 Pod 里每个容器（包括 sidecar）都申请整数 CPU，不划算又浪费资源。

五、常见坑（我栽过跟头的地方）

坑 1：从 none 改为 static，存量 Pod 不生效

这个问题太常见了，很多人改了节点配置发现存量 Pod 还是绑核失败------因为 CPU Manager 策略只在 kubelet 生成新 Pod 时应用。你必须迁移节点上所有 Pod（delete or drain）才能使新策略全部生效。

坑 2：启用了 static 策略后节点 NotReady

如果你修改节点规格或 CPU 拓扑发生变化，节点会进入 NotReady 状态。log 里能看到 failed to reconcile state 之类的报错，同时调度器往节点调度 Pod 会失败报 UnexpectedAdmissionError。

排查与解决：

先确认是不是 CPU 管理器状态文件里的 CPU 集合与节点实际 CPU 列表不匹配了：

journalctl -u kubelet -n 100 | grep -i "cpu manager"

如果确认是状态文件问题，排空节点上的负载，然后：

rm -f /var/lib/kubelet/cpu_manager_state
systemctl restart kubelet

就能恢复正常。

顺便提一嘴 ，Kubernetes v1.32 引入了 strict-cpu-reservation 选项，可以强制静态策略不用 reservedSystemCPUs 里的核心，避免 Burstable/BestEffort Pod 意外抢占系统预留核心。这是个 Alpha 特性，需要同时开启 CPUManagerPolicyOptions 和 CPUManagerPolicyAlphaOptions 特性门控，我才开始测试，生产慎用。

坑 3：InitContainer 导致 CPU 泄露

这是个 kubelet 的老 bug（GitHub Issue #112228）：如果 InitContainer 申请了整数 CPU，但它销毁后这些 CPU 有时不会被回收给共享池。现象就是节点明明有剩余资源，调度器却报 UnexpectedAdmissionError，新 Pod 就是起不来。解决方案还是去删除 cpu_manager_state 然后重启 kubelet。

坑 4：线程数超限问题

你给 Pod 绑定了 2 核，但应用（比如 Java、Node）自己创建了 50 个线程。虽然在 cpuset 限制下这些线程仍然只能在这 2 核上运行，但会导致严重上下文切换和调度延迟，完全抵消了绑核带来的性能收益。确保你的应用线程池配置 ≤ 绑核数，留有余地。

六、高阶调优：把收益再拔高一个层次（惊喜彩蛋）

1. 配合 Topology Manager 实现真正的 NUMA 亲和

如果业务对跨 NUMA 访存很敏感，千万记得开启静态策略的 kubelet 参数：

--topology-manager-policy=single-numa-node  # 或者 strict

强制分配 CPU 和内存来自同一个 NUMA 节点，彻底消除 Remote Access 延迟。

2. 分布式绑核：distribute-cpus-across-cores

Kubernetes v1.31 引入了 Alpha 特性 distribute-cpus-across-cores。默认情况下静态策略倾向于紧凑打包在少数物理核上，可能导致核心间资源共享（比如 L3 缓存和执行单元）引发争用。开启该选项后，CPU 管理器会把 CPU 尽可能散布到多的物理核上，为高负载应用提供更平稳的性能。

但注意，这个策略选项不能与 full-pcpus-only 或 distribute-cpus-across-numa 选项一起使用，而且处于 Alpha 阶段，配置前务必根据测试数据再决策。

3. Pod-Level Resource Managers（v1.36 Alpha）

以前给业务容器绑核，必须给 Pod 里的所有 sidecar 也申请整数 CPU。Kubernetes v1.36 的 Pod-Level Resource Managers 允许你在 Pod 层面直接声明整体资源预算，然后让核心业务容器继承独占且对齐 NUMA 的 CPU，sidecar 在 Pod 内部的共享池中运行，互不干扰。这个 Alpha 特性值得重点关注。

七、我推荐的生产配置清单

搜了全网这么多教程，我自己扎下心来总结的一套稳妥、高效的生产配置原则，直接拿去抄：

• 预留系统核心 ：reservedSystemCPUs 明确标出 2 至 4 个核心给 kubelet、容器运行时、系统守护进程和中断处理。
• 启用可观测性 ：监控 cpu_manager_shared_pool_size_millicores 和 cpu_manager_exclusive_cpu_allocation_count 指标，观察共享池大小变化和独占核心分配情况。
• 节点池隔离 ：单独创建一个专用池 cpu-sensitive-pool 并配置 static CPU 管理器策略，把高敏感的 Pod 调度到该池，普通业务 Pod 放在默认池。
• 准入控制检查：利用准入 Webhook 或策略引擎确保申请独占核心的 Pod 满足整数 CPU、request=limit 的条件，避免刚体跑的 Pod 实际没用上独占特性还坑了调度器。
• 周期性审计 ：定期检查 cpu_manager_state 文件，确认碎片化程度，必要时 Drain 节点重置 CPU 分配，把碎片释放出来。

八、最后的碎碎念

Kubernetes CPU Manager 是个好东西，尤其是 static 策略，但它不是万金油，也不是设好参数就一劳永逸的东西。我看到身边很多团队一涌入就开 static，结果不仅没有提升性能，反而因为资源碎片和 sidecar 共享问题，让整个集群的调度体验变得糟糕透顶。

所以我的建议是：先用默认 none 细调 requests/limits，如果压测发现抖动太大真的无法忍受，再用 static 绑核，同时也留好监控和备用的扩缩容策略。

这文档里的哪一项最戳中你的痛点？是 CPU 绑核后的碎片问题，还是 sidecar 核心申请的浪费？大家在评论区一起聊聊------下一期我可以专门来个 K8S 性能隔离专题，把 Topology Manager 和 1.36 的 Pod-Level 资源管理模式掰开揉碎写给你看。

如果觉得这篇文章帮到了你，动动手指点个收藏转发，让更多被调度器折磨的兄弟们看到。