HDUO Lab

标签： FUSE死锁

  • 深入 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 超时或硬件复位。