HDUO Lab

标签： GameDay

  • 深入 Chaos Mesh 陷阱排查：IOChaos FUSE 阻塞引发的 Kubelet D状态死锁与 GameDay 爆炸半径失控实战

    结论先行：在某次验证 I/O 降级 SLO 的 GameDay 实战中，使用 Chaos Mesh IOChaos (v2.5.1) 注入磁盘延迟。由于注入器 FUSE 进程 (toda) OOM，遗留死挂载点，导致 Kubelet 采集 Volume 指标时触发 stat 系统调用陷入 D 状态（Uninterruptible Sleep）。最终 PLEG 超时，节点 NotReady。破局方案：执行 umount -l 强卸载死挂载点；长期规范需在 GameDay 平台接入 Prometheus 异常熔断机制，并优先采用基于 eBPF 的 I/O 注入方案。

    GameDay 现场：被击穿的爆炸半径

    近期在落地高可用容灾演练时，SRE 团队设计了一个针对有状态服务（MySQL 集群）的 GameDay。核心 SLO 是：当单节点磁盘 I/O 出现严重毛刺（P99 延迟突破 500ms）时，上层业务的熔断降级机制应在 30 秒内生效，保障整体 API 成功率不低于 99.9%。

    我们通过 Chaos Mesh 下发了 IOChaos，期望在目标 Pod 的数据目录注入 300ms 的延迟：

    apiVersion: chaos-mesh.org/v1alpha1
kind: IoChaos
metadata:
  name: mysql-io-delay
  namespace: db-cluster
spec:
  action: latency
  mode: one
  selector:
    labelSelectors:
      app: mysql
  volumePath: /var/lib/mysql
  delay: '300ms'
  duration: '5m'

    注入下发后前 2 分钟，业务指标按预期平滑降级。但到了第 3 分钟，监控大盘突然雪崩：

    1. 宿主机 Load Average 从日常的 4 飙升至 200+。

    2. 该 Node 上所有微服务的 QPS 跌零，网关大量 504 报错。

    3. K8s 控制面告警：该节点进入 NotReady 状态，触发大面积 Pod Eviction（驱逐）。

    一场本该局限在单个 MySQL Pod 内的故障注入，失控变成了整个 Node 的雪崩。

    现场排查：揪出 D 状态的幕后黑手

    登录宿主机（K8s v1.24.10, Kernel 5.4.x），系统响应极度卡顿，top 命令显示 CPU Sys 态占用并不高，但 iowait 异常。

    查看 Kubelet 日志，发现经典的 PLEG 死亡报错：

    E0915 14:22:31.451921   14212 kubelet.go:1982] "PLEG is not healthy:" ...
W0915 14:23:01.452132   14212 node_status.go:421] "Error updating node status, will retry" err="timeout waiting for PLEG"

    PLEG (Pod Lifecycle Event Generator) 不健康，通常意味着 Kubelet 的某个关键 Sync 循环被彻底阻塞。由于 Load Average 极高，立刻怀疑存在大量 D 状态进程：

    # 抓取所有 D 状态进程
ps -eo state,pid,cmd | awk '$1=="D"'

    输出令人头皮发麻，不仅几十个日常运维 Agent（如 Fluent-bit, Node-Exporter）处于 D 状态，连 kubelet 主进程赫然在列！

    查看 Kubelet 的内核调用栈，寻找阻塞点：

    cat /proc/$(pidof kubelet)/stack

    内核栈输出：

    [<0>] request_wait_answer+0x12e/0x210 [fuse]
[<0>] fuse_simple_request+0x1a9/0x2e0 [fuse]
[<0>] fuse_getattr+0x2cc/0x350 [fuse]
[<0>] vfs_getattr_nosec+0x2a/0x40
[<0>] vfs_getattr+0x26/0x30
[<0>] vfs_statx+0x79/0xe0
[<0>] __do_sys_newstat+0x3d/0x70
[<0>] do_syscall_64+0x5c/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

    真相大白：Kubelet 死锁在了 fuse_getattr 上，也就是尝试去获取某个 FUSE（用户态文件系统）挂载点的信息时，被底层 FUSE 守护进程彻底 Block 了。

    紧急止血：通过 mount | grep fuse 找到对应挂载点，强制卸载。

    umount -f -l /var/lib/kubelet/pods/xxx/volumes/kubernetes.io~empty-dir/data
systemctl restart kubelet

    节点随即恢复 Ready，Load Average 在 1 分钟内回落。

    为什么一个 Pod 的 IOChaos 会导致宿主机 Kubelet 死锁？

    这涉及 Chaos Mesh IOChaos 的底层实现原理机制与 Kubelet 监控机制的致命冲突。

    1. toda FUSE 劫持机制： 在 Chaos Mesh (v2.5.x 默认机制) 中，IOChaos 的底层是通过注入一个名为 toda 的组件来实现的。toda 基于 FUSE。当你指定 volumePath 时，Chaos-daemon 会将原始目录 move 走，然后用 toda 起一个 FUSE 挂载点在原位置。Pod 内所有的 I/O 请求都会穿透 VFS 发给 FUSE，再由 toda 进程在用户态增加延迟后，转发给底层真实文件系统。

    2. toda 进程的静默死亡： 排查系统日志发现 dmesg -T | grep toda： text Out of memory: Killed process 31415 (toda) total-vm:451232kB, anon-rss:102400kB... 在注入 300ms 延迟后，MySQL 大量 I/O 请求堆积，导致处理这些请求的 toda 进程内存暴涨，触及了宿主机 cgroup 限制，被内核 OOM Killer 强杀。

    3. Kubelet 踩雷： toda 进程死后，FUSE 挂载点 /var/lib/kubelet/pods/.../volumes/... 变成了一个死挂载点 (Orphaned Mount)。没有任何用户态进程来响应这个挂载点上的 VFS 请求。 而 Kubelet 内部集成的 cAdvisor 模块，会定期扫描宿主机上所有 Pod 的 Volume 目录（计算 ephemeral-storage 占用量）。当 Kubelet 发起 stat() 系统调用遍历到这个死挂载点时，由于 FUSE 的特性，内核会一直等待用户态的回复。结果就是：Kubelet 陷入无法被信号中断的 D 状态。 PLEG 线程因 Kubelet 整体卡死而超时，最终判定 Node NotReady。

    GameDay 防御性架构与改造实践

    为了避免演练变成灾难，我们在底层架构与演练平台上做了三项核心改造：

    1. 禁用 FUSE 注入，切换为 eBPF 模式

    FUSE 代理模式在生产环境的脆弱性太高。Chaos Mesh 实际上从较新版本开始提供了实验性的基于 eBPF 的 I/O 注入，或者可以直接使用 ChaosBlade 的基于内核态（SystemTap/eBPF）的 disk delay。 如果必须使用 FUSE，则必须对注入侧进程（toda）的资源进行独立调优，并且绝对禁止作用于 Kubelet 关键路径扫描的目录。

    2. Kubelet 免疫配置优化

    为了防御类似 NFS 夯死、FUSE 异常导致的 Kubelet 雪崩，可以通过配置 Kubelet 参数，降低统计频率或关闭部分非核心目录的扫描，避免单点阻塞拖垮主循环（尽管根本上还是内核层面的限制，但在 Kubernetes 1.25+ 中对 PLEG 的底层逻辑做了部分解耦）。

    3. 建设自动熔断的 GameDay 引擎

    真正的混沌工程绝不是“在生产环境乱搞”，而是高度受控的科学实验。我们在自研的 GameDay 平台中，强制要求配置停止条件 (Halt Conditions)。 通过 webhook 联动 Prometheus，如果在演练期间满足以下 PromQL 任意一条，演练引擎将立即调用 Chaos Mesh API 执行 Delete 操作并触发报警：

    # 熔断策略片段
haltConditions:
  - name: "Node Load 异常熔断"
    query: "node_load1{instance='$NODE_IP'} > 50"
    duration: "30s"
  - name: "全局 5xx 错误率飙升"
    query: "sum(rate(istio_requests_total{response_code=~\"5.*\"}[1m])) / sum(rate(istio_requests_total[1m])) > 0.05"
    duration: "10s"

    常见问题

    Q: 如何快速定位宿主机上哪些进程卡在了哪个死挂载点？ A: 首先通过 dmesg | grep "blocked for more than" 查看内核警告。然后执行 mount | grep fuse 列出嫌疑挂载点。如果直接使用 df -h 卡住，可以使用 cat /proc/mounts（读取内存，不会触发 stat）来排查死挂载的具体路径。

    Q: Chaos Mesh 的 NetworkChaos 会有类似的爆炸半径扩散问题吗？ A: NetworkChaos 底层原理是操作网络命名空间中的 TC (Traffic Control) 和 iptables。只要 Pod 是独立的 Network Namespace（没有使用 hostNetwork: true），网络注入通常被严格限制在 Pod 级别，极少出现穿透到宿主机导致 Node NotReady 的情况，其安全性远高于基于挂载的 IOChaos。

    Q: 遇到 D 状态进程，除了重启物理机，还有没有优雅的恢复办法？ A: D 状态是内核层面的等待，常规的 kill -9 无效。如果是 NFS/Ceph/FUSE 这类网络或代理文件系统导致的 D 状态，强行卸载挂载点（umount -f -l <路径>）通常是唯一解。如果是本地物理磁盘硬件损坏导致的 D 状态，基本只能等待 I/O 超时或硬件复位。

  • 深入 Chaos Mesh 陷阱排查：TC netem 队列溢出引发的静默丢包与 GameDay 失控实战

    在进行高并发场景的混沌工程（Chaos Engineering）演练时，网络延迟注入常因 Linux 内核 tc netem 默认队列长度（1000）的硬限制，在超过 QPS * 延迟时间 的吞吐下演变为静默丢包风暴。这会导致预期内的延迟降级被放大为级联雪崩。破局点在于遵循排队论（Little’s Law）调整 qdisc 队列上限，或在高并发链路转向 L7 层故障注入，并建立基于底层的爆炸半径监控。

    故障现场：失控的 GameDay

    在某次支付核心链路的 GameDay 演练中，SRE 团队计划验证断路器（Circuit Breaker）在弱网环境下的 SLO 表现。 演练目标：向支付网关（Payment Gateway）所在的 Pod 注入固定 100ms 的网络延迟。 预期指标：接口 P99 延迟升高至 120ms 左右，部分请求触发熔断，降级链路生效，整体成功率保持在 99.9% 以上。 环境配置：Kubernetes v1.24.10, 操作系统 Alinux 3 (Kernel 5.10), Chaos Mesh v2.6.2。

    通过 Chaos Mesh 下发 NetworkChaos 资源后，监控面板瞬间亮起红灯：

    1. 支付网关的上游 Nginx 出现海量 504 Gateway Timeout 和 502 Bad Gateway。

    2. 支付网关自身的 P99 延迟飙升至 3~5 秒，远超预期的 120ms。

    3. 容器 CPU 出现毛刺，节点 Load Average 飙升。

    4. 业务成功率暴跌至 70%，被迫紧急触发 Chaos Mesh 的 Pause 机制，演练以严重事故（SEV）收场。

    抽丝剥茧：消失的报文与 TCP RTO 退避

    排查过程中，我们首先怀疑是底层网络插件（Cilium/Calico）与 Chaos Mesh 的 eBPF 探针产生了冲突。但在复现环境中，资源水位一切正常。

    为了拿到第一手现场，我们在复现期间通过 nsenter 进入了目标 Pod 的网络命名空间：

    # 获取目标 Pod 的 PID
PID=$(crictl inspectp $(crictl pods --name payment-gateway-0 -q) | jq .info.pid)

# 进入 Pod 的网络命名空间
nsenter -t $PID -n

# 检查网卡设备的 qdisc 规则与统计
tc -s qdisc show dev eth0

    终端输出了令人头皮发麻的指标：

    qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
 Sent 1450230 bytes 1230 pkt (dropped 84503, overlimits 0 requeues 0) 
 backlog 14000b 1000p requeues 0

    注意看 dropped 84503 和 backlog 14000b 1000p。 这意味着 tc netem 模块正在疯狂丢包。这不仅是“延迟”，这是毁灭性的“断网”。

    伴随着底层丢包，应用层的 TCP 连接开始进入漫长的超时重传（RTO 退避）机制。通过抓包（tcpdump）分析，发现大量的 TCP 报文触发了 200ms、400ms、800ms 的指数级重传退避，直接导致应用层的 P99 延迟被放大到秒级。大量积压的半连接和重传报文耗尽了应用的 worker 线程池，最终导致网关假死。

    为什么单纯的网络延迟注入会演变成毁灭性的丢包风暴？

    要理解这个陷阱，必须深入 Linux 内核的流量控制子系统（Traffic Control）和排队论。

    Chaos Mesh 的 NetworkChaos 底层依赖于 Linux Kernel 的 netem (Network Emulator) 调度器。当你执行延迟注入时，Chaos Mesh 的 chaos-daemon 实际上是在 Pod 的 veth 设备上执行了类似如下的命令：

    tc qdisc add dev eth0 root netem delay 100ms

    陷阱在于 netem 的默认队列长度限制（limit）。 在内核源码 net/sched/sch_netem.c 中，当一个数据包进入 netem 队列（netem_enqueue）时，内核会计算当前队列长度：

    static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
             struct sk_buff **to_free)
{
    struct netem_sched_data *q = qdisc_priv(sch);
    /* ... 延迟计算逻辑 ... */

    if (likely(sch->q.qlen < sch->limit)) {
        return qdisc_enqueue_tail(skb, sch);
    }
    // 队列满了，直接丢弃！
    return qdisc_drop(skb, sch, to_free);
}

    默认情况下，netem 的 limit 被硬编码或初始化为 1000 个数据包。

    引入排队论中的利特尔法则（Little’s Law）：L = λW

    • L：系统中的平均请求数（在这里是队列中积压的数据包数量）

    • λ：请求到达率（在此场景下为网卡的 PPS，即每秒数据包吞吐量）

    • W：请求在系统中停留的时间（在这里是我们注入的 100ms 延迟，即 0.1s）

    在我们的高并发支付网关场景中，日常吞吐量约为 15,000 QPS，算上 TCP ACK 和分片，实际 PPS 超过 20,000。 将这些数据代入公式： L = 20,000 pkt/s * 0.1 s = 2,000 pkt

    这意味着，为了仅仅维持住 100ms 的延迟而不丢包，netem 队列中时刻需要容纳至少 2000 个数据包。而默认的 limit 只有 1000。 结果显而易见：多出来的包，全部触发了 qdisc_drop。 一个本意是验证延迟 SLO 的 GameDay，因为底层的物理限制，演变成了一场规模庞大的丢包雪崩。

    架构级防御与 GameDay 设计最佳实践

    发现问题后，我们必须在 Chaos 工程体系中实施防御性设计，防止类似的基础设施参数截断导致测试失真。

    1. 显式调整 tc netem limit 参数

    对于确需在网络层（L3/L4）进行大流量延迟注入的场景，必须重写或调整 qdisc 限制。部分混沌工程工具可能未直接暴露 limit 参数，可以通过以下方式介入： 如果使用原生 tc，务必带上计算后的 limit：

    # 假设预估最大 PPS 为 50000，延迟 200ms (0.2s)
# 理论队列深度 L = 50000 * 0.2 = 10000
# 留出 20% 冗余，设定 limit 为 12000
tc qdisc add dev eth0 root netem limit 12000 delay 200ms

    在 Chaos Mesh 中，若 CRD 不支持动态扩展限额，可利用 Direction: to 与 Target 选择器，将注入目标限制在特定的下游弱依赖 IP 或端口上，从而大幅度降低匹配该 qdisc 规则的真实 PPS（λ），规避队列溢出。

    2. 高并发链路转向 L7 故障注入

    对于 QPS 动辄破万的 RPC/HTTP 微服务网关，在 L3/L4 模拟延迟极易触碰内核栈瓶颈。最佳实践是利用 Service Mesh（如 Istio / Envoy）的 L7 Fault Injection。 L7 注入发生在用户态，通过挂起协程/线程来模拟延迟，不消耗内核 qdisc 队列，彻底消除了底层丢包的副作用。

    apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-route
spec:
  hosts:
  - payment-service
  http:
  - fault:
      delay:
        percentage:
          value: 100.0
        fixedDelay: 0.1s
    route:
    - destination:
        host: payment-service

    3. 构建基于旁路指标的“硬刹车”机制

    在 GameDay 中，必须建设基于基础设施指标的自动化 Abort 机制。不能仅盯业务大盘。应将 Node Exporter 的 node_network_transmit_drop_total 或底层 tc 的 drop 速率接入 Prometheus 告警。一旦发现注入期间网卡 drop 速率陡增，混沌平台应通过 Webhook 自动中止演练。

    常见问题

    Q1：进行网络故障注入时，为什么有时会导致 Kubernetes Node 直接变成 NotReady 状态？ 这是典型的“爆炸半径穿透”。如果在注入时没有严格指定网卡（如误将规则挂载到了宿主机的 eth0 或 cni0 桥接网上），或者未配置白名单，故障规则会拦截 Kubelet 与 API Server 的心跳通信（默认 10250 端口及 6443 端口）。Kubelet 无法上报状态，Node 就会被标记为 NotReady，随后触发惨烈的 Pod 全局大驱逐（Eviction Storm）。

    Q2：当混沌工程控制面（如 Chaos Controller）宕机，导致注入的故障无法恢复，应如何自救？ 这是防御性演练必须考虑的极端场景。底座必须备有“一键逃生”脚本，通过 Ansible 或 K8s DaemonSet 绕过控制面，直接到底层 Node 节点清理网络命名空间内的规则。逃生核心命令为： for pid in $(crictl ps -q | xargs crictl inspectp | grep pid | awk '{print $2}'); do nsenter -t $pid -n tc qdisc del dev eth0 root; done

    Q3：网络丢包注入（Loss）和网络延迟注入（Delay）在内核层的消耗有什么区别？ 延迟注入（Delay）需要内核将报文暂存在内存队列中直到时间到期，极度消耗队列长度（limit）和内存资源（backlog），受排队论直接影响；而丢包注入（Loss）是通过内部的随机数生成器（如 prandom_u32()）判断命中后直接 kfree_skb 释放内存，对队列深度的压力极小。因此，高并发下注入 Delay 远比注入 Loss 容易引发次生灾害。