Kubernetes环境下Pod无法充分利用节点CPU资源问题咨询

API 探路者

2026-8-26

问题根因

该问题不是Kubernetes存在硬编码默认CPU上限导致，核心是Kubernetes默认CPU调度权重配置和原生Docker存在差异，结合现有资源配置方式触发：
Kubernetes通过cgroup的cpu.shares参数控制CPU调度相对权重，权重值和Pod配置的resources.requests.cpu成正比，每1核CPU request对应1024的shares值。该权重仅在节点CPU出现资源竞争时生效，CPU完全空闲时，任何Pod都可以占用全部空闲资源。
如果你没有给P1 Pod显式配置CPU request，或是LimitRange仅配置了CPU limit上限、没有设置合理的默认request值，P1会被分配极低的shares值（最低为2），属于BestEffort QoS等级，CPU调度优先级最低。
这个逻辑完全匹配你观察到的所有现象：

Pod内执行stress --cpu x可以占满x核：纯CPU压测时节点无其他竞争负载，shares权重不生效，Pod可以使用全部空闲CPU
P1副本数越多单PodCPU占比越低：随着P1数量上升，集群整体业务负载升高，每个节点上的kube-proxy、CNI插件、监控日志Agent、MOM服务本身的CPU开销同步上升，节点CPU进入竞争状态，低shares的P1只能分到很少的CPU时间片
原生Docker部署可以占满CPU：原生Docker启动容器时默认分配1024的shares值（对应1核权重），调度权重足够高，资源竞争时可以拿到足够的CPU时间
调整ResourceQuota、高CPU上限的LimitRange无效：这两个配置仅控制CPU硬上限，不影响调度权重，你的问题本质是资源竞争时调度优先级不足，不是被硬限制了CPU上限。

修复方案

按优先级调整以下配置即可解决：

给P1 Pod显式配置合理的CPU request和limit
这是最核心的修复项，不要依赖LimitRange的隐式默认值，直接在P1的工作负载（Deployment/StatefulSet）Pod模板中配置资源参数：
- resources.requests.cpu配置为业务实际需要的基准CPU核数，对应会给Pod分配足够高的shares值
- resources.limits.cpu配置为节点可分配的最大CPU核数，放开CPU硬上限
  配置示例（以8核工作节点为例）：
```
resources:
  requests:
    cpu: "4"  # 4核request对应4096的shares值，调度权重足够高
  limits:
    cpu: "8"  # 和节点可分配CPU核数一致，允许Pod用满全部CPU
```
配置后P1会变为Burstable（request < limit）或Guaranteed（request = limit）QoS等级，CPU调度权重会大幅提升，资源竞争时可以分到足够的时间片。

检查修正LimitRange配置
确认P1所在namespace的LimitRange配置了合理的默认CPU request值，避免后续创建的Pod因为漏写request参数被分配低调度权重，配置示例：

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit-range
spec:
  limits:
  - default:
      cpu: "8"
    defaultRequest:
      cpu: "4" # 配置默认CPU request，避免shares值过低
    type: Container

（可选，适用于专属节点场景）开启静态CPU管理策略
如果运行P1的工作节点是专属节点，仅部署P1业务，可以修改kubelet配置开启static CPU管理策略，让Guaranteed QoS等级的P1绑定专属CPU物理核心，消除调度延迟，进一步提升CPU利用率：
- 编辑kubelet配置文件（默认路径/var/lib/kubelet/config.yaml），添加/修改以下配置：
```
cpuManagerPolicy: static
systemReserved:
  cpu: "500m" # 为节点系统组件预留0.5核
kubeReserved:
  cpu: "500m" # 为Kubernetes系统组件预留0.5核
```
- 执行systemctl restart kubelet重启kubelet生效，注意该配置仅对重启后新创建的Pod生效。
（可选，适用于低延迟业务场景）调整CFS调度粒度
如果业务对CPU调度延迟敏感，可以调整kubelet的cpuCFSQuotaPeriod参数到更小值（比如10ms），降低CFS调度的时间片粒度，减少突发负载下的调度等待时间，该参数需要对应Linux内核版本支持。

内容的提问来源于stack exchange，提问作者avolast