K8s 容器 CFS throttling 让 Kafka poll 循环变慢、触发 max.poll.interval 误踢：cfs_throttled 指标很低时怎么证明就是节流在拖 poll？预警该挂哪个指标？

背景

K8s 1.28 / cgroup v2 / 内核 5.15，共享节点 16C64G，一个 Go 1.22 的 Kafka 消费者 Pod：cpu.request=1 / cpu.limit=2（Burstable，成本原因没给独占）。Kafka 3.5（3 broker，KRaft），topic 16 分区、消费组 8 实例，消费逻辑是 poll() → 下游 RPC（P99 约 200ms）→ 落库。稳态 CPU 利用率 50%~70%（按 limit 折算），看起来离 limit 还远。

现象

• broker 端日志周期性出现 Member X has failed, leaving group，客户端侧对应 max.poll.interval.ms=600000 超时被 evict，然后整组 rebalance，重复消费 + 消费延迟尖峰，一周 3~5 次；
• 诡异的是：cpu.stat 里 nr_throttled 平均每分钟只有 2~8 次、throttled_usec 累计占比不到 1%，按站内常见的「throttle 占比高 = 根因」判据，这根本不算显著 throttle；
• 但 pprof 显示被 evict 前后，poll 循环里「两次 consumer.poll() 返回之间的墙钟时间」p99 从 800ms 拉到 5s+，而同窗口下游 RPC 的 p99 没变——慢的不是业务处理，是 poll 循环本身被「切片」了，怀疑是 CFS 按 100ms 周期硬切，把长 poll 循环的 CPU 时间摊到了好几个周期里，墙钟被放大，最终顶穿了 max.poll.interval；
• 已排除：GC（Go 服务，gc 占比 <5%）、下游抖动（RPC 侧指标平稳）、rebalance 风暴（session 正常，不是 heartbeat 超时）、HPA 扩缩（该时段副本数没变）。

已尝试

1. 把 limit 从 2 抬到 3，evict 频率从一周 4 次降到 1 次（方向对，但成本不想要）；
2. 把 max.poll.interval.ms 从 60s 抬到 180s：evict 没了，但被踢前的「假死窗口」从 1 分钟变成 3 分钟，消费延迟尖峰反而更大；
3. 看了 nr_throttled / throttled_usec：占比低，按惯例不该是根因，可抬 limit 又确实有效——判据和现象对不上。

期望得到的答案形态

1. 怎么定量证明「poll 循环被 CFS 切片」而不是别的：具体到 cgroup v2 该看哪几个文件/指标（cpu.stat？cpu.pressure？），怎么和 poll 循环的墙钟 p99 对齐时间轴；throttled_usec 占比低但照样顶穿 max.poll.interval，这个自相矛盾怎么解释（是不是因为 max.poll.interval 卡的是「单次 poll 间隔的墙钟」，throttle 只要发生在 poll 返回前的最后一段就致命，占比天然被稀释）？
2. 预警该挂哪个指标：是 throttled_usec / elapsed 的比值、还是 poll 循环墙钟 p99 / 下游 RPC p99 的差值、还是 PSI 的 some 延迟？阈值怎么定才有提前量（在 evict 前 N 分钟告警）？
3. 治本的取舍：抬 limit vs cpu.burst（cgroup v2 cpu.burst 在 K8s PodSpec 里没有字段，怎么落地）vs 把 poll 循环拆成独立 goroutine + 短 poll 小 batch，哪条路对「Burstable 成本约束」最划算？

引用依据：

• 站内已有人踩过 CFS quota 顶穿延迟的坑，但都是「单次请求延迟」视角，没覆盖「poll 循环墙钟被切片 → max.poll.interval 误踢」这个链路；
• HPA 触发 rebalance 的讨论很多，但「CFS 节流 → poll 变慢 → 误踢 → rebalance」这条链，我检索下来还没看到系统拆解。