cgroup v2 下如何量化 CFS throttling 占比并决定要不要开 cpu.cfs_burst？求一套可复现的验证方法

背景 我在一个 10 节点（8C16G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15）的网关集群跑一个 Go 服务（Gin，net/http，约 40 个协程池化连接），给容器设了 cpu.limit=2、cpu.request=1。业务是短时突发型：平时 QPS 低，整点任务会瞬间冲到 800 QPS 持续 3~5 秒。

现象 平时 P50 稳定在 18ms，但整点突发窗口内 P99 会间歇性飙到 600ms~1.2s，持续 200~800ms 不等，之后回落。CPU 监控（node_exporter 的 container CPU usage）看峰值也就 1.9，没到 limit 的 2，所以一开始以为是下游或 GC，但 Go 侧 GC 日志那个窗口基本没动。

已尝试的排查与结果

1. 看 /sys/fs/cgroup/.../cpu.stat，发现 nr_throttled 在突发窗口明显涨，但 throttled_usec 我只会看绝对值，没算过占比，也没对上时间线；
2. 把 limit 从 2 调到 4，毛刺基本消失，但这让我怀疑是不是「调大 limit 掩盖问题」，而且整点全集群一起涨，怕节点被打满；
3. 查了内核，CONFIG_CFS_BANDWDT 在，但没试过 cpu.cfs_burst_usec，不确定开了有没有副作用、怎么验证生效。

期望得到的答案形态 想要一套可复现、能贴进工单的排查清单：

• 怎么用 cpu.stat 的 nr_throttled / throttled_usec / usage_usec 算出 throttling 占比，并和我自己的 P99 毛刺时间线对齐（具体命令 + 采样频率 + 怎么读）；
• 在 cgroup v2 下 cpu.cfs_burst_usec 的具体写法、单位、上限、以及开了之后怎么验证它真的生效（而不是默默没起作用）；
• 「调大 limit」和「开 burst」这两个方案各自的适用边界和副作用，给我一个能直接抄的判断标准（什么场景选哪个）。 如果方便，能顺带说一句 Go 侧有没有比 Go runtime 更早的「被 CFS 切走」的信号（比如 runtime.NumCPU 看到的核数和实际可用 CPU 不一致）就更好了。