Kubernetes Pod CPU使用率低于request仍被节流相关问题咨询

核心问题回复 #

问题1：空闲request额度分配规则 #

可以分配。Kubernetes的CPU request是调度层面的保障阈值，不是节点层面的硬资源预留。节点上的CPU时间会按照各Pod CPU request的权重做优先级分配，只要你的Pod没有用满自身的request配额，这部分空闲CPU时间完全可以分配给其他不超过自身CPU limit的Pod使用，不会触发节流。

问题2：CPU资源收回时的节流逻辑 #

• 该场景不会触发两个Pod同时节流：有request保障的Pod优先级高于仅使用Burst超额份额的Pod。当你的Pod后续需要使用自身request配额内的CPU时，内核会优先将之前借给其他Burst Pod的CPU时间收回，只要你的Pod CPU使用率没有超过自身配置的limit，就不会被节流。
• 仅超出自身CPU limit的Pod会被节流：如果其他Pod的CPU用量没有超过自身limit，只是占用了超过自身request的burst份额，只会被降低调度优先级，不会被节流；只有其用量超过自身limit时才会触发CFS节流。
• 该场景不会触发集群自动新增节点：集群自动扩容的触发条件是存在无法调度到现有节点的Pending Pod，运行时的CPU资源争抢不会触发扩容逻辑。

低于request仍被节流的其他可能诱因 #

排除CFS配额BUG的前提下，常见诱因包括：

• CPU绑核与NUMA架构不匹配：如果节点开启了CPU管理器的静态绑核策略，但Pod的CPU request不是整数，或者调度到了跨NUMA节点的CPU核心，跨NUMA访问带来的 latency 会被内核统计为CPU等待时间，看起来就像被节流。
• 容器进程的内核态CPU占用未被统计到用户态使用率：日常观测的容器CPU使用率通常只统计用户态CPU耗时，如果进程有大量syscall、中断处理等内核态CPU开销，总占用其实已经超过limit但用户态显示很低，就会出现低于request却被节流的错觉。
• CPU shares权重配置异常：如果节点上部署了很多BestEffort类型的无request/limit配置的Pod，他们的CPU shares权重极低，但如果短时间内集中占用CPU，也可能导致低优先级的Burstable Pod即使在request额度内也出现调度等待。
• cgroup v1的内核统计BUG：部分老版本内核即使修复了CFS配额的过度节流问题，仍存在CPU节流统计值偏高的BUG，实际没有发生节流，只是监控指标展示错误。
• 同Pod内多容器资源争抢：如果Pod内有多个容器，其中一个容器占用CPU超过自身limit被节流，也可能导致整个Pod的业务表现出现卡顿，被误判为整个Pod被节流。

排查建议 #

• 执行kubectl describe pod <pod名称>确认Pod的QoS等级，以及每个容器的request/limit配置是否匹配业务预期
• 用kubectl exec进入容器执行top命令，分别查看用户态(%us)、内核态(%sy)、IO等待(%wa)的CPU占比，确认是否存在未被统计的隐藏CPU开销
• 查看节点的NUMA拓扑和Pod的CPU绑核配置，确认是否存在跨NUMA调度的问题

内容的提问来源于stack exchange，提问作者Devendra Singh khurana