HDUO Lab

标签： 故障注入

  • 深入 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）。

  • 深入 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 容易引发次生灾害。

  • 深入混沌工程内核：从 TC/eBPF 故障注入到 SLO 自动化验证实战

    混沌工程绝不是毫无章法的“拔网线”。本文直接拆解基于 Chaos Mesh (v2.6.2) 的底层故障注入原理（Linux tc 与 eBPF 机制），并给出一套将故障注入与 Prometheus SLO 报警集成的自动化 GameDay 验证闭环方案。记住：没有可观测性度量和自动恢复兜底的故障注入，纯粹是在搞破坏。

    为什么你的故障注入总是不及预期？深入 TC 与 eBPF 机制

    很多研发拿着现成的 YAML 一把梭，看到 Pod 报错就以为混沌实验成功了。但在真实的排查场景中，如果不清楚底层到底“烂”在哪个系统调用或网络栈层级，你根本无法验证微服务的超时重试和熔断机制是否真正生效。

    1. 网络延迟注入：Netem 与 Namespace 的戏法

    当你下发一个针对某个 Pod 的网络延迟（NetworkChaos）时，控制面并不会去修改交换机配置。底层的 chaos-daemon 会通过 Kubelet 拿到目标容器的 PID，然后利用 nsenter 钻进该容器的网络命名空间（Network Namespace），利用 Linux 内核自带的 Traffic Control (tc) 和 netem 模块进行流量整形。

    某次验证超时熔断时，发现注入 200ms 延迟后应用依然秒回。直接登录 Node，钻入目标 Pod 命名空间查看真实流控规则：

    # 获取目标 Pod 容器的主进程 PID
PID=$(crictl inspect <container_id> | jq .info.pid)

# 进入容器的网络命名空间查看 tc 规则
nsenter -t $PID -n tc -s qdisc show dev eth0

    正常被注入延迟的网卡，你能看到类似如下的输出：

    qdisc netem 1: root refcnt 2 limit 1000 delay 200.0ms  10.0ms 25%
 Sent 10234 bytes 81 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

    如果输出是 qdisc pfifo_fast 0:，说明 tc 规则根本没打上。通常是因为 CNI 插件（如 Cilium 的某些 BPF 模式）绕过了宿主机的 veth pair，或者内核没有加载 sch_netem 模块（modprobe sch_netem 可解）。

    2. 磁盘 IO 故障：eBPF 对 VFS 的精准拦截

    早期的 IO 故障注入靠在容器里跑 dd 把磁盘带宽打满，这种做法极度粗暴，且容易引发宿主机的 IO 风暴，波及同节点其他核心 Pod（典型的爆炸半径失控）。

    现代混沌工程（如 Chaos Mesh 的 IOChaos）在内核态使用 eBPF 实现精准注入。要求宿主机内核至少在 4.17+（推荐 5.4+ 以获得稳定的 BPF 特性）。其原理是将一段 BPF 字节码挂载到内核的 VFS（虚拟文件系统）层面上，例如通过 kprobe 拦截 vfs_read 和 vfs_write 函数。

    当目标进程发起读写请求时，BPF 程序会被触发，强制在内核态 bpf_ktime_get_ns() 循环等待（制造延迟），或者直接修改系统调用返回值，返回 -EIO (Input/output error)（制造读写失败）。这种方式只针对特定 PID 和特定目录生效，彻底切断了对宿主机全局的干扰。

    SLO 验证闭环：用数据说话，拒绝肉眼盯盘

    GameDay（故障演练日）的核心不是制造恐慌，而是验证系统的容错边界是否符合 SLO（服务级别目标）。我们通常以 Error Budget（错误预算）消耗率为核心判定标准。

    在演练前，必须确保 Prometheus 中有定义严谨的 SLO 监控指标。例如，核心交易链路的 P99 延迟 SLO 定义为 200ms。

    # 记录规则：计算订单服务 P99 延迟
record: job:request_latency:p99
expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service="order-svc"}[1m])) by (le))

    在 GameDay 流程中，自动化脚本的逻辑应该是：

    1. 持续轮询拉取当前 P99 延迟，确认 Baseline 正常（如 50ms）。

    2. 下发 NetworkChaos，注入 150ms 延迟。

    3. 观测 P99 延迟指标是否在 1 分钟内攀升至 200ms 左右。

    4. 核心断言：断言上游 API Gateway 的 5xx 错误率是否上升。如果上游配置了合理的 100ms 超时和重试熔断，上游应用应触发熔断策略，而不会被下游彻底拖死导致线程池耗尽（防止级联雪崩）。

    GameDay 实战剧本：千万别忘了防御性恢复

    这里给出一个验证数据库主备切换的真实网络隔离注入配置片段。注意其中的 duration 和 mode 参数，这是防御性编程在混沌工程中的体现。

    apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: db-partition-gameday
  namespace: sre-chaos
spec:
  action: partition
  mode: fixed
  value: "1" # 仅影响 1 个目标 Pod（爆炸半径控制）
  selector:
    namespaces:
      - production
    labelSelectors:
      "app": "mysql-cluster"
      "role": "master"
  direction: both
  target:
    selector:
      namespaces:
        - production
      labelSelectors:
        "app": "order-service"
  # 极其重要：强制 60 秒后自动恢复。严禁在没有自动恢复时间的配置下执行演练！
  duration: "60s"

    排查心法：演练过程中如果发现系统挂了且无法自愈，第一反应是直接删除 Chaos 资源（kubectl delete networkchaos db-partition-gameday -n sre-chaos）。如果 chaos-controller-manager 组件本身在这个时候假死卡住了，立刻在宿主机执行兜底恢复脚本： find /proc -maxdepth 1 -regex '/proc/[0-9]+' -exec nsenter -t {} -n tc qdisc del dev eth0 root 2>/dev/null \; （强制清理节点上所有的 tc 限制，简单粗暴但救命）。

    常见问题

    Q1: 生产环境做混沌实验，如果控制面（Controller）挂了，故障一直存在怎么兜底？ 控制面宕机会导致 duration 到期后无法自动清理。成熟的落地方案必须在 Node 层面部署一层“看门狗（Watchdog）”。可以写一个 DaemonSet，每 10 秒去 APIServer 检查特定 Chaos 对象是否存在，如果 APIServer 超时无响应，或者 Chaos 对象已被标记删除但底层规则还在，DaemonSet 直接在本地执行 tc qdisc del 或 bpf-loader unload 强制清理底层规则，确保业务绝对存活。

    Q2: 使用 PodChaos 注入了 CPU 满载（Stress）故障，为什么进容器敲 top 命令看到的 CPU 使用率并没有飙升？ 这是容器隔离性带来的经典视图问题。top 命令读取的是 /proc/stat，默认情况下容器内挂载的是宿主机的 /proc 系统（除非你使用了 lxcfs 这类用户态文件系统）。因此 top 看到的是整个宿主机的 CPU 状态。要确认容器是否被压满，应该在宿主机查看目标容器对应的 cgroup 统计指标：cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-pod.slice/cpuacct.usage_percpu。

    Q3: 注入 IO 故障后，为什么 Node 节点内核直接发生 Panic 重启了？ eBPF 的能力虽然强大，但拦截诸如 vfs_read/write 属于非常底层的内核操作。在特定的 Linux 内核版本（尤其是一些云厂商魔改的 4.19.x 分支）中，bpf 钩子与系统现有的某些内核模块（如特定的存储驱动）会产生竞态条件。遇到内核 Panic，首先通过 kdump 捕获 vmcore，用 crash 工具查看堆栈调用树（Backtrace），通常能看到 bpf_prog_XXX 导致了空指针解引用。解决办法是：升级内核至稳定版（如 5.4.x），或改用相对高层的应用级注入方案。