k8s为pod进行cpu绑核以进一步提高性能

场景：

在k8s中，对于游戏训练等任务场景下，游戏worker模拟真实玩家时，性能对cpu依赖程度很高，此时如果对pod进行cpu绑核能够一定程度上再提高性能

配置步骤

• 1、驱逐节点:kubectl drain <NODE_NAME>
• 2、停止 kubelet:systemctl stop kubelet
• 3、修改 kubelet 参数:–cpu-manager-policy=“static”
• 4、删除旧的 CPU 管理器状态文件:rm var/lib/kubelet/cpu_manager_state
• 5、启动 kubeletsystemctl start kubelet

对需要更改其 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-manager-policy参数解析

cpu-manager-policy有两种策略：none和static

• none 策略

  none 策略显式地启用现有的默认 CPU 亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。 通过 CFS 配额来实现 Guaranteed Pods 和 Burstable Pods 的 CPU 使用限制。

• static 策略

  static 策略针对具有整数型 CPU requests 的 Guaranteed Pod， 它允许该类 Pod 中的容器访问节点上的独占 CPU 资源。这种独占性是使用 cpuset cgroup 控制器来实现的。

注意

当启用 static 策略时，要求使用 --kube-reserved 和/或 --system-reserved 或 --reserved-cpus 来保证预留的 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 资源。

原因：