3. CPU Manager Policy 概述：static 与 none 策略的差异及适用场景

CPU Manager 是 kubelet 中负责 CPU 资源分配的核心组件，其策略直接决定了 Pod 中容器能够获得的 CPU 拓扑与性能隔离程度。Kubernetes 默认提供两种内置策略：none 和 static。理解这两种策略的差异，是进行 CPU 敏感型工作负载性能调优的第一步。

3.1 策略核心差异对比

下表从分配粒度、CPU 亲和性、性能隔离性、适用负载类型等维度，对两种策略进行系统性对比：

3.2 none 策略详解

none 策略是 kubelet 的默认策略，其行为与传统的 Linux CFS（Completely Fair Scheduler）完全一致。kubelet 仅通过 cgroups 中的 cpu.shares 和 cpu.cfs_quota_us 来限制容器的 CPU 使用上限，但不对容器进程绑定任何特定的物理 CPU 核心。

none 策略的优势在于资源利用率高，适合大多数无状态微服务和批处理作业。但其代价是性能波动较大，当节点上存在 CPU 密集型 Pod 时，延迟敏感型应用的尾延迟会显著恶化。

3.3 static 策略详解

static 策略专为需要 CPU 性能保障的 Guaranteed QoS Pod 设计。当 Pod 满足以下条件时，kubelet 会为其分配一组独占的物理 CPU 核心：

• Pod 中所有容器的 cpu.requests 等于 cpu.limits。
• CPU 资源值必须为整数（如 1、2、4），不支持小数。
• Pod 的 QoS 等级为 Guaranteed。

static 策略的核心分配流程如下：

1. kubelet 启动时扫描节点 CPU 拓扑，将核心分为“预留池”和“可分配池”。
2. 预留池（--reserved-cpus 或 system-reserved/kube-reserved）用于系统进程和 kubelet 组件。
3. 当符合条件的 Guaranteed Pod 被调度到节点时，kubelet 从可分配池中选取整数个核心。
4. 通过 cpuset cgroup 将选中的核心绑定到容器内的所有进程。
5. 容器进程从此只能在这些核心上运行，其他 Pod 的进程无法使用这些核心。

3.4 策略选择决策流程

下图展示了在实际集群中如何根据工作负载特征选择 CPU Manager 策略：

3.5 配置示例与验证

在 kubelet 配置文件中启用 static 策略：

# /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cpuManagerPolicy: "static"          # 可选 "none" 或 "static"
cpuManagerReconcilePeriod: "10s"    # 策略协调周期
topologyManagerPolicy: "best-effort" # 可选配合拓扑管理器
reservedSystemCPUs: "0,1"           # 预留前两个核心给系统

验证 static 策略是否生效：

# 查看 Pod 的 cpuset 分配
kubectl exec -it <pod-name> -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

# 预期输出示例：显示绑定的核心列表
2-3

# 查看 kubelet 日志确认策略分配
journalctl -u kubelet | grep "cpuManager"
# 输出示例：I0912 10:15:30.123456   12345 cpu_manager.go:456] 
# [cpumanager] static policy: assigned container <container-id> 
# to cpuset [2-3]

3.6 适用场景总结

根据实际生产环境经验，以下场景推荐使用对应的策略：