K8s CPU limit 引发的 CFS 节流：一次 P99 从 45ms 飙到 2.1s 的延迟事故复盘

一、现象与背景：CPU 没打满，延迟却翻了 46 倍

先交代规模和数字。我们一个 12 节点（8C16G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v1）的网关集群，跑着一个 Go 网关（单实例 4C limit / 1.5C request）。白天稳态 QPS 约 3200，P99 延迟稳定在 45ms 左右。

上周一次压测后，业务方反馈「偶发一批请求卡 2 秒以上」，但监控上 CPU 利用率最高只有 78%（top 看到的 1C/4C 折算），内存、GC、下游 RT 全部正常，没有任何一个指标「看起来像凶手」。事后从网关 access log 里捞出 11 分钟窗口：这 11 分钟里 P99 被拉到 2103ms，P999 到了 4.8s，而同期 cpu.usage 均值只有 2.1C（52%）。CPU 明明没满，延迟却翻了 46 倍——这就是典型的 CFS 节流（throttling）事故。

二、原理与根因：limit 不是「平均 4C」，而是「每 100ms 周期内只给你 400ms」

很多人（包括当时的我）把 resources.limits.cpu: "4" 理解成「这个 Pod 平均能用 4 核」。这是错的。Kubernetes 的 CPU limit 落到内核，本质是 CFS 调度器的带宽配额：

• kubelet 把 limit 换算成 cgroup 的两个参数：cpu.cfs_period_us（周期）和 cpu.cfs_quota_us（配额）。默认周期是 100ms，所以 4C limit 就是每 100ms 内最多用 400ms 的 CPU 时间。
• 一旦这个 100ms 窗口内线程用满了 400ms，CFS 会直接把整个 cgroup 冻结（throttle），剩余时间一个调度帧都不给，直到下一个 100ms 周期才「解冻」重新发额度。

关键的反直觉点在于：配额是按 100ms 切片的，不是滑动的。我们的网关是事件驱动 + 突发型 workload，单核瞬时经常打满。压测后我们调了一个批量序列化逻辑，导致每 100ms 窗口内 CPU 需求峰值超过 400ms，于是频繁触发 throttle。cpu.stat 里能看到铁证：

# cat /sys/fs/cgroup/cpu/kubepods/pod<uid>/cpu.stat
nr_periods            124053
nr_throttled          61208        # 近一半的周期被节流！
throttled_usec        884210331    # 累计被冻结 884 秒

nr_throttled / nr_periods ≈ 49%——接近一半的 100ms 窗口都被冻结过，这才是 P99 飙到 2.1s 的根因。而 top 的利用率是「用了多少 / 给了多少 quota」的折算值，节流期间它不会上涨，所以监控「看起来没事」。利用率指标对 throttle 事故几乎失明，必须看 nr_throttled。

三、具体做法：把节流压下去的四板斧（可复现）

1. 先量化，再动手。 给每个容器挂一个 read-only 的 cpu.stat 采集（cgroup v1 路径如上；cgroup v2 是 cpu.stat 同名字段，在 /sys/fs/cgroup/kubepods.slice/.../cpu.stat）。Prometheus 侧用 cadvisor 的 container_cpu_cfs_periods_throttled_total 和 container_cpu_cfs_throttled_seconds_total 两个指标，告警规则我定的是「单容器 5 分钟 throttled/periods > 10% 就 warning，>30% 就 critical」。

2. 调大周期（治标，最快见效）。 CFS 的节流粒度是 period，周期越大越平滑。kubelet 加参数：

--cpu-cfs-quota-period="500ms"

把 100ms 提到 500ms 后，同样的突发负载在窗口内更不容易「提前用满」，我们实测 nr_throttled/nr_periods 从 49% 掉到 6%，P99 回到 60ms 以内。代价是突发响应变「钝」，对延迟极敏感的小核服务要慎用。

3. 该放 limit 就别放（治本）。 我们的网关 CPU 是突发型而非稳态型，硬 limit 天然不适合。最终做法是把 limits.cpu 去掉，只保留 requests.cpu: 1500m，让 QoS 从 Guaranteed 降到 Burstable——它能在节点有空闲 CPU 时自由突发，不再被 400ms 配额卡死。前提是节点整体要留余量，否则多个 Burstable Pod 互相抢，问题会换个形式复发。

4. 真要硬隔离，就用 CPU Manager static 策略（治本但最重）。 对必须独占物理核的延迟敏感服务：

# kubelet 配置
cpuManagerPolicy: static
cpuManagerPolicyOptions:
  sharedPoolLowerBound: "4000m"   # 低于 4C 的请求走共享池

配合 resources.requests.cpu == limits.cpu == 整数核，内核会把整核 pin 给该容器，彻底绕开 CFS 带宽限制。代价是碎片化：节点必须凑出整核，4C16G 的节点规划要按整核来切。

四、踩过的坑与反直觉之处

• top/利用率对 throttle 失明。 这是最坑的。利用率是折算值，节流时不涨。一定要看 nr_throttled，否则你会一直去查 GC、下游、内存，全查不出来。
• cgroup v1 和 v2 的路径与参数名不一样。 v1 是 cpu.cfs_quota_us / cpu.cfs_period_us，v2 合并成 cpu.max（格式是 quota period，例如 400000 100000，写 max 表示不限制）。我们迁移 v2 后，一个老监控脚本读 v1 路径直接读成 0，告警全静默了两周才有人发现——迁移 cgroup 版本后必须全量回归一遍 cgroup 相关的采集与脚本。
• --cpu-cfs-quota-period 改大不是免费的。 它让突发更平滑，但也让「该快的时候」变慢，对需要低延迟小爆发的服务，盲目调大反而劣化。
• 去掉 limit ≠ 没上限。 Burstable 只是允许突发到节点空闲额度，节点整体超卖时照样会被 CFS 公平调度挤占，P99 仍可能抖。硬隔离只能靠 static + 整核。
• 压测要专门打「突发」而不是「均值」。 我们之前压测只看平均 QPS 和平均延迟，均值完全正常，掩盖了节流。后来改成「每个 100ms 窗口内瞬时打满单核」的突发模型，才把问题逼出来。

五、结论与可复用清单

CPU limit 的本质是 CFS 带宽配额，按 100ms 周期切片，它约束的是「突发能力」而不是「平均吞吐」。突发型 workload 配硬 limit，几乎必然踩 throttle。可复用清单：

1. 监控必加 container_cpu_cfs_periods_throttled_total / ..._throttled_seconds_total，别只盯利用率；告警阈值从 throttled/periods > 10% 起步。
2. 突发型服务优先「只留 request、去掉 limit」，让 QoS 落到 Burstable 自由突发。
3. 真要硬隔离，上 cpuManagerPolicy: static + 整核对齐，并接受节点碎片化的代价。
4. 快速止血可试 --cpu-cfs-quota-period 调大周期，但要对延迟敏感服务做 A/B 验证。
5. 压测用「窗口内瞬时打满」的突发模型，而非平均 QPS，否则 throttle 永远测不出来。
6. cgroup v1→v2 迁移后，全量回归 cgroup 采集路径与脚本，避免静默失效。

一句话记住：CPU 没打满 ≠ 没有 CPU 问题；看 nr_throttled，别看 top。