如何让Kubernetes的CPU Manager在资源管理中游刃有余？

k8s中为什么要用CPU Manager？ 默认情况下，kubelet 使用CFS配额来执行 Pod 的 CPU 约束。Kubernetes的Node节点会运行多个Pod，其中会有部分的Pod属于CPU密集型的工作负载。在这种情况下，Pod之间会争抢节点的CPU资源。当争抢剧烈的时候，Pod会在不同的CPU Core之间进行频繁的切换，更糟糕的是在NUMA Node之间的切换。这种大量的上下文切换，会影响程序运行的性能。 什么是cpu密集型？ 通俗来讲就是对cpu依赖很高，操作cpu的频率非常高，充分的使用cpu资源来实现本地计算任务。 另外还有io密集型： io密集型就是讲磁盘/内存的io操作会非常频繁，文件读写、网络请求等，这种一般cpu利用率会非常低 CPU Manager有什么缺点？ CPU Manager特性是节点级别的CPU调度选择，所以无法在集群维度中选择最优的CPU Core组合。同时CPU Manager特性要求Pod是Guaranteed时（Pod中的每个容器必须指定CPU Request和CPU Limit，并且两者要相等）才能生效，且无法适用于所有类型的Pod。 如何开启CPU Manager cpu Manager 在 Kubernetes v1.12 引用为 [beta]，故想要更好的使用它，版本需>=v1.12。 CPU 管理策略通过 kubelet 参数 --cpu-manager-policy 或 KubeletConfiguration 中的 cpuManagerPolicy 字段来指定。支持两种策略： none: 默认策略，表示现有的调度行为。可以理解为不开启cpu manager。 static: 允许为节点上具有某些资源特征的 Pod 赋予增强的 CPU 亲和性和独占性。 none 策略 none 策略显式地启用现有的默认 CPU 亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。通过 CFS 配额来实现 Guaranteed Pods和 Burstable Pods的 CPU 使用限制。 static 策略 static 策略针对具有整数型 CPU requests 的 Guaranteed Pod ，它允许该类 Pod中的容器访问节点上的独占 CPU 资源。这种独占性是使用cpuset cgroup 控制器来实现的。 CPU 管理器定期通过 CRI 写入资源更新，以保证内存中 CPU 分配与 cgroupfs 一致。同步频率通过新增的 Kubelet 配置参数 --cpu-manager-reconcile-period 来设置。如果不指定，默认与 --node-status-update-frequency 的周期（默认10s）相同。 Static 策略的行为可以使用 --cpu-manager-policy-options 参数来微调。该参数采用一个逗号分隔的 key=value 策略选项列表。此特性可以通过 CPUManagerPolicyOptions 特性门控来完全禁用。 更改CPU Manager策略 由于 CPU 管理器策略只能在 kubelet 生成新 Pod 时应用，所以简单地从 "none" 更改为 "static"将不会对现有的 Pod 起作用。因此，为了正确更改节点上的 CPU 管理器策略，请执行以下步骤： 腾空节点。就是将pod都在此节点驱逐，或者索性stop container。 停止 kubelet。 删除旧的 CPU 管理器状态文件。该文件的路径默认为 /var/lib/kubelet/cpu_manager_state。这将清除CPUManager 维护的状态，以便新策略设置的 cpu-sets 不会与之冲突。 编辑 kubelet 配置以将 CPU 管理器策略更改为所需的值。 启动 kubelet。 对需要更改其 CPU 管理器策略的每个节点重复此过程。 说明： CPU 管理器不支持运行时下线和上线 CPUs。此外，如果节点上的 CPUs 集合发生变化，则必须驱逐节点上的 Pod，并通过删除 kubelet 根目录中的状态文件cpu_manager_state来手动重置 CPU Manager。 CPU Manager使用注意事项 此策略管理一个 CPU 共享池，该共享池最初包含节点上所有的 CPU 资源。可独占性 CPU 资源数量等于节点的 CPU 总量减去通过 kubelet --kube-reserved 或 --system-reserved参数保留的 CPU 资源。