Chaosblade 节点 CPU 满载演练指南：模拟异常进程占用导致 Node CPU 使用率过高的完整方案

• 运维
• 云原生
• SRE
• AI Agent
• 人工智能

导读

本文基于 Chaosblade 项目的 Kubernetes 故障演练用例 Node_CPU使用率过高_异常进程占用.md，系统讲解如何通过blade create k8s node-cpu fullload向指定节点注入 CPU 满载故障，复现"异常进程大量占用 CPU"这一根因，并完成从资源准备、故障注入、注入验证到实验销毁、恢复验证的完整闭环。读者将掌握 Node 级别 CPU 故障注入的完整命令参数、监控验证方法与恢复流程，可直接用于混沌工程演练与系统韧性验证。

一、用例场景总览：故障现象与根因

该用例归属于 k8s-chaos-skills 技能包中 Node 层级的故障分类目录Node_CPU使用率过高，文件命名中的"异常进程占用"即该用例对应的根因。用例通过向节点注入 CPU 满载来模拟节点上存在异常进程大量占用 CPU 的真实故障，其核心故障现象定义如下：

1. 节点 CPU 使用率持续超过 90%：这是本用例判定故障生效的首要指标；
2. 节点上 Pod 响应变慢，出现超时：CPU 资源被异常进程挤占后，同节点所有 Pod 的用户态进程调度受阻，请求延迟随之上升；
3. Load Average 显著升高：可运行进程队列堆积，系统负载（1/5/15 分钟均值）持续走高。

用例将上述现象归纳为基准事实（baseline facts），作为演练结束后判定"故障是否真实复现、恢复是否彻底"的对照标准：

• 根因：节点上存在异常进程大量占用 CPU，导致节点 CPU 使用率过高，影响同节点上所有 Pod 的性能；
• 必现现象：节点 CPU 使用率持续超过 90%；Load Average 显著升高；同节点 Pod 响应变慢。

理解这一点非常关键：Node 级别的 CPU 故障与 Pod 级别不同，它影响的是整个节点，波及该节点上运行的所有 Pod，因此演练前必须严格确认目标节点上没有承载不可中断的核心服务。

二、资源准备：演练前的两个前提

根据用例文档，开始演练前必须完成两项准备工作：

1. 确认应用 A 已正常运行：演练需要有明确的观测对象（应用 A），用于对比注入前后 Pod 响应延迟的变化。建议预先通过kubectl get pods -o wide确认应用 A 所在 Pod 的 Running 状态，并记录其所在的节点名。
2. 确认监控系统（如 Prometheus）已配置，可观测节点 CPU 指标：这是 k8s-chaos-skills 技能包 SKILL.md 中"安全红线"所强调的"有监控，无监控不演练"原则。Node 级故障缺少监控观测将无法验证注入效果，也无法评估爆炸半径。建议预先确认以下指标可查询：
   • 节点 CPU 使用率（如node_cpu_seconds_total派生出的使用率百分比）；
   • Load Average（如node_load1、node_load5）；
   • 应用 A 的请求延迟（如应用自定义的 P99 指标或网关侧观测）。

另外，演练还应遵循技能包的安全红线：在隔离命名空间或测试集群演练，严禁在生产核心链路注入；注入前明确回滚方案，确保 30 秒内可恢复。

三、演练步骤：向目标节点注入 CPU 满载

3.1 定位运行应用 A 的节点

注入前先用 kubectl 确定应用 A 的 Pod 调度在哪个节点上，作为后续注入目标：

kubectl get pods -n <namespace> -o wide --kubeconfig <path>

从输出中记录目标节点名（Node 列），后续通过--names指定。

3.2 使用 chaosblade 注入节点 CPU 满载

在宿主机具备 blade CLI 的前提下，使用 Node 级别的 CPU 满载命令（完整参数见 chaosblade-commands.md 中"二、Node 级别故障"一节）：

blade create k8s node-cpu fullload \ --names <节点名> \ --cpu-percent <0-100> \ --kubeconfig ~/.kube/config

Node CPU 满载可用的 Flags 与 Pod CPU 满载完全一致，核心参数如下：

参数取值建议：模拟"CPU 使用率持续超过 90%"的故障现象，--cpu-percent建议取 90~100。若希望故障自动解除，可同时设置--timeout（如--timeout 600），否则需在演练后手动销毁实验。

关于该命令的通用 Flags 说明（适用于所有blade create k8s命令）：

常见错误警示：只有cputarget 才存在fullloadaction；node-mem对应的 action 是load（不是fullload），node-disk没有fullload。注入前务必确认 scope-target-action 组合在 chaosblade-commands.md 的 Action 对照表中存在，避免因 action 不存在导致注入失败。

命令执行成功后会返回实验 UID，格式类似：

{"code":200,"success":true,"result":"<blade_uid>"}

请妥善保存该 UID，恢复阶段需要用到。

3.3 场景定位与命令对应关系（源码佐证）

从仓库源码看，node-cpu fullload 命令的使用方式在 exec/kubernetes/spec.go 中有直接示例，可验证上述命令参数的合法性：

return `blade create k8s node-cpu fullload --names cn-hangzhou.192.168.0.205 --cpu-percent 80 --kubeconfig ~/.kube/config`

即在 k8s 场景下，node-cpu目标配合fullload动作、--names指定节点名、--cpu-percent控制负载比例的用法是项目内置的标准注入路径。

四、注入验证：确认故障真实生效

注入完成后，严格按照用例文档的三条标准进行验证：

1. 查看节点 CPU 使用率监控，确认持续超过 90%：在 Prometheus 或 Grafana 中观察目标节点 CPU 使用率曲线，要求持续（而非瞬时尖峰）超过 90%；
2. 查看 Load Average，确认显著升高：观察节点node_load1/node_load5指标，确认负载显著高于注入前基线；
3. 确认应用 A 的请求延迟增大：调用应用 A 的接口并观察响应时间，或查看应用侧延迟指标，确认出现明显变慢甚至超时。

三条验证标准与用例的"必现现象"一一对应，可同时佐证：故障确实注入成功、故障影响范围确实波及同节点 Pod、以及监控体系观测有效。

五、注入恢复与恢复验证：演练闭环

5.1 注入恢复

演练结束后销毁实验，解除 CPU 满载：

blade destroy <UID>

若实验中设置了--timeout，到达指定秒数后故障也会自动解除。紧急情况下也可批量销毁所有实验（见 chaosblade-commands.md 实验管理命令）：

blade status --type create | grep "^UID" | awk '{print $2}' | xargs -I {} blade destroy {}

5.2 恢复验证

恢复后对照基准事实反向验证：

1. 查看节点 CPU 使用率监控，确认恢复到正常水平：CPU 使用率回落至注入前基线附近，不再持续超过 90%；
2. 确认应用 A 的请求延迟恢复正常：延迟指标回到基线，不再出现超时。

只有当注入验证全部通过、且恢复验证也全部通过时，这次演练才算完整闭环。建议按技能包 SKILL.md 中"第三步：用例执行"的要求输出演练报告，记录用例决策树路径（Node > CPU使用率过高 > 异常进程占用）、注入结果、恢复结果与改进建议。

六、实战注意事项与扩展玩法

6.1 爆炸半径控制

Node 级别 CPU 故障是"共享宿主机资源"型故障，影响范围为整个节点上的所有 Pod。因此在注入前必须确认：

• 目标节点不承载etcd、kube-apiserver 等控制平面组件（技能包安全红线明确禁止对控制平面注入）；
• 目标节点上没有其他不可中断的业务服务；
• 不在业务高峰期演练。

6.2 节点磁盘场景的常见混淆

部分演练者容易把fullload用到磁盘目标上，这是常见错误：node-disk只有fill（磁盘空间填充）和burn（磁盘 IO 负载）两个 action，没有fullload。CPU 满载只适用于cputarget，本用例使用的正是node-cpu fullload这一唯一正确组合。

6.3 持续化演练：Operator YAML 方式

如需通过 Operator 方式（kubectl apply）执行持续化演练，可按 chaosblade-commands.md 提供的 YAML 模板构造 Node CPU 满载实验，node 级别使用names而非labels定位目标：

apiVersion: chaosblade.io/v1alpha1 kind: ChaosBlade metadata: name: node-cpu-fullload spec: experiments: - scope: node target: cpu action: fullload desc: "节点 CPU 满载 90%" matchers: - name: names value: ["<node-name>"] flags: - name: cpu-percent value: "90"

创建与销毁实验分别使用kubectl apply -f experiment.yaml与kubectl delete chaosblade node-cpu-fullload，查看状态使用kubectl get chaosblade <experiment-name> -o yaml。

6.4 宿主机 blade CLI 不可用时的替代路径

当宿主机 blade CLI 未安装或版本不兼容时，可通过kubectl exec在集群内的 chaosblade-tool Pod 中执行相同命令，参数与本地 CLI 完全一致：

# 1. 发现 tool Pod（DaemonSet 方式部署，如 app=otel-c-tool） kubectl get pods -n chaosblade -l app=otel-c-tool --kubeconfig=<path> # 2. 通过 tool Pod 注入 Node CPU 满载 kubectl exec <pod> -n chaosblade -- \ blade create k8s node-cpu fullload \ --names <node-name> \ --cpu-percent 90 \ --kubeconfig=<path> # 3. 从返回 JSON 中提取 blade_uid，恢复时执行 kubectl exec <pod> -n chaosblade -- blade destroy <blade_uid> --kubeconfig=<path>

七、演练结果判定速查

依据 chaosblade-commands.md 中的场景速查，该用例对应的最小命令可概括为blade create k8s node-cpu fullload --cpu-percent 90 --names <node>；配合blade status/blade destroy完成实验生命周期管理。掌握本用例后，即可在隔离测试环境中安全复现"异常进程占用导致节点 CPU 使用率过高"这一高频生产故障，并验证监控告警、自动弹性与故障恢复机制的有效性。

• 运维
• 云原生
• SRE
• AI Agent
• 人工智能