HDUO Lab

标签： cgroup

  • 深入 ChaosBlade 陷阱排查：cgroup 状态逃逸引发的永久性 CPU Throttling 与 GameDay 瘫痪实战

    近期在主导一次核心交易链路的 GameDay 时，遇到一起极具讽刺意味的故障：我们在对结算微服务注入 CPU 满载故障以验证 HPA（水平Pod扩容）和限流降级策略后，通过控制台停止了混沌实验。然而，目标微服务并未如期恢复，P99 延迟死死钉在 3000ms 以上，QPS 从日常的 5000 跌至不到 100，业务处于静默熔断状态。最终排查确认：这是由于 ChaosBlade Agent 在实验期间因资源竞争被 Kubelet Evict，导致 cgroup 恢复逻辑被跳过，目标 Pod 的 cpu.cfs_quota_us 被永久锁定在极低值，引发了灾难性的全局 CPU Throttling。

    混沌工程的核心原则是“控制爆炸半径”和“可恢复性”，但如果故障注入工具本身的鲁棒性一塌糊涂，GameDay 就会演变成一场真正的灾难。今天把现场排查逻辑复盘出来，希望能让大家对底层资源隔离和混沌工具的原子性有更深的敬畏。

    现场还原与排查逻辑

    实验结束指令下发后，监控大盘并未如期恢复“全绿”。 第一反应是业务代码里有自旋锁没释放，或者 Go Runtime GC 挂起了。但登录到目标 Node 上查看，系统 Load Average 只有不到 2.0，极其空闲。

    执行 top 并按 P 排序，发现目标 Go 进程的 CPU 占用率不到 1%，但处于 R (Running) 状态的时间极短。 拉取 Prometheus 监控，发现 go_goroutines 数量堆积到了 8 万多，说明请求进来了，但处理极慢。

    排除了应用层死锁后，直奔底层资源隔离指标。执行以下 PromQL 检查容器 CPU 限流情况：

    rate(container_cpu_cfs_throttled_periods_total{pod=~"settlement-svc-.*"}[1m]) 
/ 
rate(container_cpu_cfs_periods_total{pod=~"settlement-svc-.*"}[1m])

    图表极其触目惊心：Throttling 比例高达 99.9%！这意味着容器几乎每个 CPU 调度周期都被内核硬生生掐断。

    立刻切入宿主机，根据 Pod UID 定位到对应的 cgroup 目录，查看当前的 CFS 配额：

    # 获取容器的 cgroup 路径
CGROUP_PATH=$(find /sys/fs/cgroup/cpu/kubepods.slice/ -name "*$(docker inspect -f '{{.Id}}' <container_id>)*")

# 查看当前配额
cat $CGROUP_PATH/cpu.cfs_quota_us
1000

cat $CGROUP_PATH/cpu.cfs_period_us
100000

    结论非常荒谬：这个 Pod 原本是 Guaranteed QoS，配置了 requests.cpu=4, limits.cpu=4，其 cpu.cfs_quota_us 应该是 400000。现在居然变成了 1000（即 0.01 核）！难怪业务进程形同植物人。

    底层原理解析：ChaosBlade 的致命缺陷

    为什么停止了 ChaosBlade 实验，配额却没有恢复？

    追踪 kubelet 和 chaosblade-tool 的日志，还原了事发现场：

    1. 注入阶段：ChaosBlade 为了模拟 CPU 饥饿/满载，并不是单纯地在容器内拉起一个 stress-ng 跑满 CPU（这无法限制宿主机上其他进程抢占）。它的部分高阶实现会直接入侵目标容器的 cgroup namespace，动态修改 cpu.cfs_quota_us 来限制应用的实际可用 CPU，或者在拉起满载进程的同时调整配额。

    2. 状态保存：在修改 cfs_quota_us 之前，ChaosBlade Agent 会将原始值（400000）保存在本地内存或一个临时状态文件中。

    3. 意外崩溃：在故障注入期间，由于整体 Node CPU 压力剧增，Kubelet 触发了资源保护机制。ChaosBlade 的 DaemonSet Pod 因为没有配置足够高的 PriorityClass（优先级过低），直接被 Kubelet 判定为牺牲品，执行了 Eviction（驱逐）。

    4. 逃逸与死锁：当操作人员在控制台点击“停止实验”时，控制端向集群下发恢复指令，但旧的 Agent 已经死了，新拉起的 Agent 内存中根本没有那个 Pod 的原始 cgroup 状态记录！恢复操作直接被跳过（或静默失败）。目标 Pod 的 cgroup 彻底成了无主孤魂，被永久锁定在 1000。

    这种非原子性的状态管理，是防御性编程的绝对反面教材。

    修复与避坑指南

    现场的临时止血很简单，手动把正确的配额写回 cgroup，或者直接删掉业务 Pod 让 K8S 重新调度重建：

    echo 400000 > /sys/fs/cgroup/cpu/kubepods.slice/kubepod-pod<UID>.slice/docker-<ContainerID>.scope/cpu.cfs_quota_us

    但从架构和 SRE 规范的角度，必须要建立以下护城河：

    1. 混沌组件必须配置最高优先级： Chaos Agent 等同于节点上的 Rootkit，其生命周期必须得到绝对保障。必须为其分配 system-node-critical 级别的 PriorityClass，并配置严苛的 Guaranteed 资源 QoS。绝不允许在实验中途被 Kubelet 驱逐。

    2. 无状态恢复与 eBPF 化： 抛弃那些通过直接篡改不可变基础设施状态（如原地修改 cgroup、原地修改 iptables 规则且不依赖 owner）来注入故障的低级工具。优秀的混沌工具应采用 eBPF（挂载点随进程生命周期绑定，进程死则注入自动失效）或 TC+cgroup-bpf 技术。如果一定要改文件，必须有基于独立 Watchdog 的兜底恢复机制（例如通过 Label 记录原始状态）。

    3. GameDay 旁路熔断监控： 实验脚本不能只看“业务指标是否下降”，必须引入“基础设施一致性校验”。在实验停止的自动化流水线中，增加一步对注入点（cgroup、网络 tc 队列）的物理清理确认。

    同类问题排查清单

    1. CPU Throttling 突增排查：不要只看 Node CPU 使用率。应用变慢但 Load 正常时，第一步永远是 cat /sys/fs/cgroup/cpu/.../cpu.stat，重点关注 nr_throttled 和 throttled_time。

    2. 混沌注入残留排查：网络类实验结束后延迟依然很高，检查 tc qdisc show dev eth0 是否残留 netem 规则；CPU 类检查 cfs_quota_us；IO 类检查 eBPF probe 或 FUSE 挂载点残留。

    3. Agent 生命保障检查：检查所有 DaemonSet 类型的运维组件（Chaos, Fluentd, node-exporter）的 PriorityClass，如果没有配置，在节点资源紧张时它们必然成为导致系统雪崩的定时炸弹。

    4. Cgroup 泄漏检测：定期运行脚本遍历 kubepods.slice 下的僵尸 cgroup 目录，K8S 曾有多个版本存在 Pod 销毁后 cgroup 目录不清理的 Bug，会导致内核内存碎片化及性能剧降。

  • 深入 Chaos Mesh 陷阱排查：StressChaos 击穿 cgroup 触发全局 OOM 与 GameDay 节点雪崩实战

    本文直接给出结论：在进行混沌工程内存注入演练时，如果目标 Pod 未配置硬性 Memory Limit（处于 Burstable/BestEffort 状态），且注入工具（如 Chaos Mesh 的 stress-ng）以极快速度（如 >100MB/s）分配内存，将直接绕过 Kubelet 周期为 10s 的 cAdvisor 驱逐检测，触发宿主机内核全局 OOM（Global Out of Memory）。最终导致核心组件（如 containerd/calico）被 OOM Killer 绞杀，引发 Node NotReady 和不可控的 Pod 驱逐雪崩。解决方案是：强制落地 LimitRange，配置 Kubelet 严格的 enforce-node-allocatable 屏障，并控制注入速率。

    排查过程中，我们正在对核心交易链路进行一次常态化的 GameDay 演练。演练 SLO 是：单节点内某个无状态服务突发内存泄漏（OOMKilled）时，K8S ReplicaSet 能够在一分钟内完成自愈调度，且上游关流平滑，P99 延迟波动不超过 50ms。

    然而，演练按钮按下的第 15 秒，监控大盘直接被红色淹没。目标 Pod 并没有按照预期发生局部重启，而是其所在的整个宿主机节点直接陷入 NotReady 状态，该节点上的 40 多个无关业务 Pod 全部触发 Eviction 驱逐，大面积重调度瞬间击穿了我们的依赖服务，爆炸半径完全失控。

    我不喜欢在 PPT 里讲容灾，GameDay 就是最好的照妖镜。下面还原当时的排查现场与底层根因。

    故障现场：一个 StressChaos 干挂了整片 Node

    我们使用的混沌工程平台是 Chaos Mesh (v2.6.2)，目标环境为 Kubernetes v1.24，宿主机内核为 CentOS 7 的 5.4.x。当时下发的 StressChaos 配置如下：

    apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: memory-leak-injection
  namespace: chaos-testing
spec:
  mode: one
  selector:
    labelSelectors:
      app: payment-gateway
  stressors:
    memory:
      workers: 4
      size: '8GB'
      oomScoreAdj: -500 # 企图保护注入进程自身
  duration: '5m'

    直观上看，这个注入的逻辑很简单：通过 chaos-daemon 侵入目标 Pod 的 cgroup namespace，启动 4 个 stress-ng worker，吃掉 8GB 内存。

    但在目标节点的 /var/log/messages 中，我们看到了极其惨烈的内核日志：

    kernel: [123456.789] stress-ng-vm invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=-500
kernel: [123456.790] CPU: 12 PID: 45678 Comm: stress-ng-vm Tainted: G        W         5.4.203-1.el7.elrepo.x86_64
...
kernel: [123456.812] Out of memory: Killed process 3845 (containerd) total-vm:4589312kB, anon-vm:894320kB, file-vm:0kB, shmem-vm:0kB, UID:0 pgtables:2312kB oom_score_adj:-999
kernel: [123456.815] oom_reaper: reaped process 3845 (containerd), now anon-vm:0kB, file-vm:0kB, shmem-vm:0kB

    内核的 OOM Killer 被唤醒，它没有干掉我们的目标业务进程，也没有干掉 stress-ng，而是把节点上的 containerd 给绞杀了。CRI 运行时一挂，Kubelet 随之陷入 PLEG (Pod Lifecycle Event Generator) timeout 死循环，节点状态直接变为 NotReady。

    为什么 100MB/s 的内存注入会击穿 cgroup 防线？

    这里有两个核心悖论：

    1. Kubernetes 的 Kubelet 有 evictionHard 机制（默认 memory.available<100Mi），为什么没提前驱逐 Pod？

    2. 为什么 cgroup 机制没有把目标 Pod 限制住（Cgroup OOM），而是触发了全局内存耗尽（Global OOM）？

    Kubelet 驱逐的"盲区时间"

    Kubelet 的驱逐机制属于用户态行为。它依赖内置的 cAdvisor 组件来周期性地抓取容器资源的利用率，这个指标采集的默认周期（Housekeeping Interval）大约是 10 到 15 秒。 在我们的演练中，stress-ng 通过 mmap() 配合多线程快速触发 Page Fault 分配物理内存，分配速率轻松超过 1GB/s。 当系统剩余可用内存从 2GB 掉到 100MB 以下时，只需不到 2 秒。在这 2 秒内，cAdvisor 根本还没来得及完成下一次指标轮询，Kubelet 完全不知道节点内存已经枯竭，自然无法发起 Eviction 驱逐。

    Cgroup OOM 与 Global OOM 的区别

    如果 Pod 配置了完整的 resources.limits.memory（属于 Guaranteed QoS），cgroup 目录底下的 memory.limit_in_bytes 会有一个明确的上限值。当 stress-ng 吃满这个值时，内核会触发基于该 cgroup 的 OOM（Cgroup OOM），这只会杀死该 Pod 内的进程，对宿主机无害。

    但排查发现，目标 Pod 恰好是一个历史遗留服务，开发只配了 requests，没有配 limits（QoS 为 Burstable）。 这意味着该容器对应的 cgroup 没有任何硬性内存上限（memory.limit_in_bytes = 9223372036854771712，即无限大）。 因此，注入进程直接把整台物理机的物理内存 + Swap 吃光了，最终导致内核触发全局级别的 OOM（Global OOM）。

    内核 OOM Killer 的无差别绞杀逻辑

    触发 Global OOM 后，Linux 内核必须牺牲某个进程来拯救系统。这个死刑判决基于 oom_score（范围 0 ~ 1000），分数越高的进程越先被杀。其计算公式大致为： oom_score = (进程消耗的物理内存百分比 * 10) + oom_score_adj

    我们看看当时的算分情况：

    1. 目标 Java 进程：消耗内存不大，默认 oom_score_adj。

    2. stress-ng 注入进程：消耗了绝大部分内存，本应分数最高。但我们在 YAML 里手贱配置了 oomScoreAdj: -500（为了防止混沌测试进程刚启动就被杀）。这导致它的最终得分大幅降低。

    3. kubelet：官方默认配置了 oom_score_adj = -999，可以说是拿到了"免死金牌"。

    4. containerd / calico-node：在这个版本的集群环境中，部署脚本遗漏了对这些关键系统守护进程配置 oom_score_adj 的下调操作（默认是 0）。

    于是荒诞的一幕出现了：stress-ng 吃光了内存但因为有护身符逃过一劫；containerd 虽然占用不多，但相比有着 -999 护身符的 kubelet 来说，成了分最高的"软柿子"，直接被 OOM Killer 刀了。

    防御性 GameDay 的架构加固方案

    不要把演练变成灾难，我们需要在底座和混沌工程平台两端加上硬性约束（Guardrails）。

    1. 补齐 Kubelet 节点级别的资源硬防线 (Cgroup 层)

    仅仅靠用户态的 Kubelet 驱逐是不够的，必须利用 Kubelet 的 Node Allocatable 特性，在内核 cgroup 层面画好红线。

    在 Kubelet 参数中增加以下配置：

    --enforce-node-allocatable=pods
--system-reserved=cpu=2,memory=4Gi,ephemeral-storage=10Gi
--kube-reserved=cpu=1,memory=2Gi,ephemeral-storage=5Gi

    原理解析：开启 enforce-node-allocatable=pods 后，Kubelet 会在宿主机上创建一个顶级的 kubepods cgroup，并将所有的 Pod 都挂载在这个 cgroup 之下。该 cgroup 的最大内存限制被硬编码为 Node Capacity - kube-reserved - system-reserved。 这样，哪怕所有 Pod 都没有配 Limit，它们联合起来能消耗的最大内存也会被死死按在 kubepods 的 cgroup 隔离带里。一旦越界，内核只会触发 kubepods 这个 cgroup 层级的 OOM，绝对不会影响到处于 system.slice 下的 containerd 和 sshd。

    2. 收拢 Chaos Mesh 爆炸半径：限制注入速率与打分

    在执行 Memory StressChaos 时，严禁使用过低的 oomScoreAdj，同时必须限制 worker 的内存分配速率。可以利用 stress-ng 的底层参数，不要让其"毕其功于一役"地申请内存。

    修改后的安全演练 YAML：

    apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: safe-memory-leak
spec:
  mode: one
  selector:
    labelSelectors:
      app: payment-gateway
  stressors:
    memory:
      workers: 1
      size: '2GB'
      # 移除 oomScoreAdj，让 stress-ng 接受正常的 OOM 制裁
      options:
        - '--vm-keep'    # 持续保持内存占用而不是反复分配/释放
        - '--vm-bytes' 
        - '2G'

    3. 拦截违规负载：强制引入 LimitRange 与 Mutating Webhook

    运维必须兜底。为了防止开发再次上线只有 requests 没有 limits 的“定时炸弹”，在所有 namespace 强制下发 LimitRange，对没有配置 limits 的 Pod 进行自动补全：

    apiVersion: v1
kind: LimitRange
metadata:
  name: enforce-limits
spec:
  limits:
  - default:
      memory: "2Gi" # 强制加上 Limit，将容器锁定在 Cgroup OOM 范畴
    defaultRequest:
      memory: "512Mi"
    type: Container

    常见问题 (FAQ)

    Q1：进行 CPU 混沌注入（CPU Stress）时，是否也会遇到这种节点雪崩的风险？ 相对可控。CPU 是可压缩资源（Compressible Resource），而内存是不可压缩资源。即使 CPU 被 stress-ng 打满，内核通过 CFS (Completely Fair Scheduler) 仍能保证关键进程（如 kubelet，通常在启动时会拉高 nice 优先级或单独的 cpuset）获得时间片。但如果大量生成陷入内核态（D状态）的压测进程，耗尽了 PID 或者导致 Syscall 卡死，依然可能拖垮节点。

    Q2：如何确认节点是因为 Global OOM 崩溃，而不是因为 Kubelet 驱逐引起的重启？ 直接登录现场宿主机（如果还能登入），或者查看采集的系统日志：执行 dmesg -T | grep -i oom-killer 或 cat /var/log/messages | grep "Out of memory"。如果有大量针对非目标进程的 Killed process 日志，且没有 Kubelet Evicting Pod 的审计事件，那大概率就是发生了击穿 cgroup 的 Global OOM。

    Q3：在 Cgroup v2 环境下，内存混沌注入的行为会有变化吗？ Cgroup v2 引入了更平滑的内存控制机制，比如 memory.high（软限流，触达后会大力压制进程运行并强制内存回收）和 memory.max（硬限流，等同于 v1 的 limit_in_bytes）。如果在 v2 集群下配合 Kubelet 的 MemoryQoS 特性，未配 Limit 的 Pod 在吃光内存前，会先触发 memory.high 的限流惩罚，这在一定程度上延缓了内存飙升速度，能给 cAdvisor 和 Kubelet 留出更多时间执行优雅驱逐（Eviction）。

  • 深入 CFS 带宽控制陷阱排查：cfs_quota_us 截断引发的无故 Throttling 与容器 P99 抖动实战

    某次线上核心交易网关出现诡异的 P99 延迟抖动。现象极其反直觉：QPS 稳在 3000 左右，容器 CPU 使用率（Prometheus container_cpu_usage_seconds_total）常年盘旋在 30% – 40%，宿主机的 Load Average 不超过 2。但在业务监控上，平时 15ms 的接口，P99 经常毫无征兆地飙升到 150ms 甚至 300ms 以上。结论先行：这是最典型的 CFS 带宽控制（Bandwidth Control）机制与多线程并发模型错配引发的惨案。不要一看到 CPU 使用率低就去查网络和 IO，在 K8s 环境下，瞎配 CPU Limit 导致的频繁 Throttling，才是杀戮 P99 延迟的隐形凶手。

    案发现场：被无视的 CPU 节流

    排查过程中，业务开发坚持认为是底层物理机网络抖动，因为“我的 CPU 连一半都没跑到”。我没有废话，直接登入出问题的节点，找到对应 Pod 的 cgroup 路径，拉出 CFS 的统计数据：

    # 找到容器对应的 cgroup 路径并查看 cpu.stat
$ cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podxxx.slice/docker-xxx.scope/cpu.stat
nr_periods 135028
nr_throttled 48291
throttled_time 4381948291000

    数据极其刺眼：nr_periods 是经过的调度周期数，nr_throttled 是被限流的周期数。近 35% 的调度周期内该容器被 CFS 强制“冻结”了！累计限流时间（throttled_time）高达几千秒。

    开发人员满脸疑惑：“CPU 限额（Limit）设了 2 核，平时只用不到 1 核，凭什么限流？”

    这就是很多不理解内核调度器的开发者最容易踩的坑。K8s 中的 CPU Limit 底层是通过 CFS 的 cpu.cfs_period_us 和 cpu.cfs_quota_us 来实现的。默认情况下，cfs_period_us 为 100,000 微秒（100ms）。Limit 设为 2 核，意味着 cfs_quota_us 为 200,000 微秒。 重点来了：配额是按线程在 CPU 上的运行时间累加计算的。

    该业务是一个 Go 写的网关程序，且没有正确设置 GOMAXPROCS。宿主机是 64 核的物理机，Go 运行时默认全量探测，启动了 64 个 P（Processor）和一堆 M（系统线程）。 当一波微突发流量到达时，几十个 Goroutine 被唤醒，几十个底层线程瞬间在几十个物理核上并发执行。 假设有 64 个线程同时全速运行，消耗完 200,000 微秒的 CPU 额度需要多久？ 200,000 / 64 = 3,125 微秒，也就是 3.1 毫秒。

    这意味着，在每一个 100ms 的调度周期里，应用在头 3.1ms 就把双核的额度挥霍一空，接下来的 96.9ms 内，CFS 调度器会冷酷无情地将该容器的所有线程全部挂起（Throttled）。如果在挂起期间有新的网络请求到达，只能乖乖在 Socket 缓冲区里躺着，等待下一个 100ms 周期的到来。这就完美解释了为什么业务 P99 经常暴增到 100ms、200ms 以上。

    在 Prometheus 中计算均值时，3.1ms 的极度繁忙和 96.9ms 的绝对静止被抹平，你看到的 CPU 使用率就是风平浪静的 30%（即 2 个核的 30%）。用宏观的平均指标去衡量微秒级的内核调度，无异于刻舟求剑。

    底层机制与修复策略

    这种因为微突发（Micro-burst）引发的 CFS Throttling，在多线程/协程语言（Go、Java）中极为普遍。要彻底解决这个 P99 杀手，通常有以下几条路径：

    1. 校准运行时并发度（必须做） 绝对不要让容器里的应用感知到宿主机的全局 CPU 数量。对于 Go 应用，强依赖 go.uber.org/automaxprocs 库，在 init() 阶段自动解析 cgroup 的 cpu.cfs_quota_us 并正确设置 GOMAXPROCS。对于 Java 8+，确保开启 -XX:+UseContainerSupport（默认开启）。 把线程池规模压制在 Limit 范围内，避免“一哄而上”导致的配额瞬时秒光。

    2. 放大 CPU Limit，改用 Request 保障（推荐） 在微服务架构下，过度细粒度的 CPU Limit 往往弊大于利。对于延迟敏感型在线业务，推荐的做法是：

    • Request 设为真实日常峰值使用量（保证调度水位和可压缩资源底线）。

    • Limit 留出极大的冗余，甚至干脆不设（Limit=0）。 只要你的节点层面做了足够容量规划并配合 Load 驱逐策略，让容器利用空闲 CPU 应对瞬间并发，收益远大于严格 Limit 带来的稳定假象。

    3. 启用内核 CFS Burst 特性（需要较新内核） 在 Linux 5.14 及以上内核（或者部分大厂自己 Backport 的 4.14/4.19 内核中），内核引入了 CFS Burst 特性（由华为工程师贡献）。它允许容器将过去没用完的 CPU 配额“攒”起来，放到未来应对突发流量。

    # 查看是否支持 burst 特性
ls /sys/fs/cgroup/cpu/cpu.cfs_burst_us

    如果集群支持且 Kubelet 开启了相应 Feature Gate，利用这个特性可以极大地缓解微突发引发的节流问题。

    总结

    永远不要迷信“CPU 没打满就不会卡”这种浅薄经验。在 CFS 调度器眼里，时间是以微秒为单位切割的。给多线程高并发应用套上严苛的 CPU Limit，等于给一辆法拉利装上了 10 升的油箱和 100 公里的限速器。

    同类问题速查清单

    1. 快速定性：执行 cat /sys/fs/cgroup/cpu/$(docker inspect --format '{{.HostConfig.CgroupParent}}/{{.Id}}' $CONTAINER_ID)/cpu.stat，若 nr_throttled / nr_periods 比例大于 5%，必须介入处理。

    2. 运行时配置检查：检查 Go 的 GOMAXPROCS 或 Java 的 CPU 探测机制，确认容器内进程看到的 CPU 核数是否等于 Request/Limit 设定的核数，而非宿主机物理核数。

    3. Kubelet 全局开关：在某些纯内部高优计算集群，若受困于此问题且版本老旧，可评估在 Kubelet 启动参数中添加 --cpu-cfs-quota=false 彻底关闭 CPU Limit 强制隔离（危险操作，需配套严密的节点负载熔断机制）。

    4. PromQL 监控巡检：日常监控需配置告警 rate(container_cpu_cfs_throttled_periods_total[5m]) / rate(container_cpu_cfs_periods_total[5m]) > 0.1，抓住潜在的 P99 衰退节点。

  • 深入 CFS 调度器陷阱排查：cgroup quota 微突发引发的无辜节流与 P99 延迟雪崩实战

    在 K8s 容器环境中，CPU 使用率不到 20% 却频繁出现 P99 延迟毛刺，根本原因是 CFS 带宽控制（cfs_quota_us）在微突发场景下的过度节流（Throttling）。解决方案：要么升级内核至 5.14+ 开启 CPU Burst 特性，要么对核心时延敏感型服务启用 Kubelet static CPU Manager 策略以独占物理核并绕过 quota 限制，辅以 NUMA 节点绑定。

    排查过程中，我们遇到一个典型且极其隐蔽的性能陷阱：一个用 Go 编写的高并发 API 服务，Pod 配置为 requests: 4, limits: 4，Prometheus 监控显示其 CPU 利用率峰值从未超过 1.5 核。然而，业务端频繁报出超时，网关层统计的 P99 延迟从平稳的 20ms 间歇性飙升至 300ms 以上。

    没有 GC 停顿，网络抓包无丢包，存储 IO 处于极低水位。唯一的异常落在 cgroup 的 CPU 调度统计上。

    执行以下命令查看该 Pod 对应容器的底层调度指标：

    # 进入容器对应的 cgroup 目录 (路径依 Cgroup v1/v2 及容器运行时有所不同)
cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-pod<uid>.slice/docker-<cid>.scope/cpu.stat

    输出令人吃惊：

    nr_periods 542100
nr_throttled 184520
throttled_time 4851230000000

    超过 34% 的调度周期（nr_throttled / nr_periods）发生了节流（Throttling），累计被限制运行的时间高达 4851 秒。容器被系统强制“按下了暂停键”。

    为什么 CPU 使用率极低也会触发 CFS 节流（Throttling）？

    要理解这个诡异现象，必须剖析 Linux 内核完全公平调度器（CFS）的带宽控制（Bandwidth Control）机制。

    在 Kubernetes 中，设置 CPU limits 本质上是在配置 cgroup 的 cpu.cfs_period_us 和 cpu.cfs_quota_us。 默认情况下：

    • cpu.cfs_period_us = 100000（100 毫秒），即调度周期。

    • 对于 limits: 4，cpu.cfs_quota_us = 400000（400 毫秒）。

    “微突发（Micro-burst）”导致的无辜节流： Go 程序的协程（Goroutine）极多。假设在某个 100ms 的调度周期初始，网关突然打来一波并发请求，Go runtime 唤醒了 16 个 OS 线程来处理。 这 16 个线程在多核宿主机上并行执行，虽然每个线程仅仅执行了 25ms，但总计消耗的 CPU 时间为 16 * 25ms = 400ms。

    此时，距离当前 100ms 周期结束还有 100ms - 25ms = 75ms，但 400ms 的 quota 已经被瞬间耗尽。 CFS 调度器的直接反应是：强制剥夺该 cgroup 内所有线程的执行权，挂起等待下一个 100ms 周期。 这就导致了业务请求在这 75ms 内得不到任何 CPU 资源，直接反映为 P99 延迟无端增加 70~80ms，且多次叠加后引发雪崩。而在更高维度的 Prometheus 监控中（通常是 15s 或 1m 抓取一次），这种 100ms 级别内的剧烈波动被彻底抹平了，导致 CPU 使用率看起来极其“健康”。

    破局方案与底层调优实战

    为了彻底解决 CFS 调度导致的延迟毛刺，我们分层级实施了以下架构改造，拒绝简单的“无脑放大 limits”。

    1. 终极解法：内核 CPU Burst 特性 (Kernel >= 5.14)

    在较新的内核版本中（部分大厂针对 Kernel 4.19/5.4 已 backport 该特性），内核引入了 cpu.cfs_burst_us。它允许容器将历史周期内未用完的 quota 累积起来，应对突发流量。 通过向容器注入类似配置，允许最大爆发额度（比如额外允许 400ms）：

    echo 400000 > /sys/fs/cgroup/cpu/kubepods.slice/.../cpu.cfs_burst_us

    这一机制类似于令牌桶算法，有效吸收了微突发流量。开启后，nr_throttled 归零，P99 延迟恢复平滑。

    2. K8S 侧解法：启用 CPU Manager 的 Static 策略

    如果内核版本较低（如 CentOS 7 的 3.10 或标准 Ubuntu 20.04 的 5.4），我们必须规避 CFS quota。手段是通过 Kubelet 的 CPU Manager 将容器进程与物理 CPU 进行绑核（cpuset），并移除 cgroup quota 限制。

    修改 kubelet 配置文件 /var/lib/kubelet/config.yaml：

    cpuManagerPolicy: static
topologyManagerPolicy: single-numa-node

    Pod 配置规范： 必须保证 QoS 为 Guaranteed，即 requests 必须等于 limits，且值为整数。

    resources:
  requests:
    cpu: "4"
    memory: "8Gi"
  limits:
    cpu: "4"
    memory: "8Gi"

    此时 Kubelet 会通过 cgroup 的 cpuset.cpus 分配 4 个独占的逻辑核（例如 4-7），由于是独占，底层不再依赖 cfs_quota_us 限制，从而彻底根除 Throttling。

    3. 极客进阶：防御中断风暴与 NUMA 错位

    仅仅使用 cpuset 绑核并不完美。即使应用独占了 CPU 4-7，依然可能被网卡中断（Hard IRQ）和软中断（Softirq）抢占。通过 perf sched 或 mpstat 可以看到上下文切换（CS）依然很高。

    隔离内核调度（Isolcpus 配合 IRQ Affinity）： 修改宿主机 Grub 内核启动参数，将部分 CPU 从内核默认调度域中剔除：

    GRUB_CMDLINE_LINUX="... isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-7"

    同时调整中断亲和性，避免网卡队列中断落到被隔离的核上：

    # 将中断限制在 0-3 核上处理
for irq in $(ls /proc/irq/); do
    echo 0-3 > /proc/irq/$irq/smp_affinity_list 2>/dev/null
done

    这就为高吞吐、低延迟的核心业务打造了一条纯粹的“物理超车道”。

    常见问题 (FAQ)

    Q1：K8s 中设置 requests == limits 会带来什么调度层面的影响？ A：除了触发 Guaranteed QoS 避免 OOM 驱逐外，在 CPU 调度层面，如果不开启 Kubelet CPU Manager static 策略，它依然受制于 CFS Quota 限制。只有在 static 策略下，整核的 requests==limits 才会触发底层 cpuset 独占逻辑，从而完全绕开 CFS 周期结算，这对时延敏感型（Latency-sensitive）应用至关重要。

    Q2：绑核（Taskset/cpuset）后，为什么还会出现 CPU 缓存未命中（Cache Miss）飙升？ A：通常是因为 NUMA 节点未对齐。如果分配的 CPU 核在 NUMA Node 0，但进程访问的内存被分配在 NUMA Node 1，跨 QPI/UPI 总线访问内存会导致严重的延迟。解决方案是在 Kubelet 开启 topologyManagerPolicy: single-numa-node，强制 CPU 和内存在同一 NUMA 节点内分配。

    Q3：内核参数 kernel.sched_min_granularity_ns 对高并发有什么直接作用？ A：该参数定义了 CFS 调度中一个任务在被抢占前能够保证运行的最小时间片段（默认一般为 3ms-10ms）。在极其密集的上下文切换场景（如成千上万个轻量级连接），适当调大该值可以减少上下文切换带来的开销，提升系统总吞吐量（Throughput），但代价是牺牲了一定的调度响应时延（Latency）。调整时需通过 perf 工具严格评估收益。

    Q4：为什么在高并发数据库（如 MySQL/Redis）的宿主机上，极不推荐混部 RT（实时）调度策略的进程？ A：RT 任务（如 SCHED_FIFO / SCHED_RR）优先级高于所有的 CFS 普通任务。如果一个存在死循环或长时间未主动 yield 的 RT 进程跑满单核，不仅会饿死同核上的 MySQL 工作线程，甚至可能导致内核态的软狗（Soft Lockup）超时引发内核 panic。控制 RT 任务的爆炸半径，必须严格配置 kernel.sched_rt_runtime_us 和 kernel.sched_rt_period_us。