混沌工程实战：使用 Kubernetes+Chaos Mesh 搭建混沌测试体系

测试开发技术

发布于 2026-01-13 15:41:41

730

一、概述

1.1 背景介绍

混沌工程通过主动注入故障验证系统在异常情况下的行为，发现分布式系统中的未知弱点。Chaos Mesh 是 CNCF 托管的云原生混沌工程平台，提供丰富的故障注入能力，支持 Pod 故障、网络异常、IO 延迟、压力测试等多种实验类型。相比传统的故障演练，Chaos Mesh 通过 Kubernetes CRD 实现故障场景的代码化，支持定时执行、条件触发、自动回滚等高级特性。

在微服务架构下，服务依赖关系复杂，级联故障、雪崩效应等问题难以通过传统测试发现。通过混沌实验可验证熔断降级、超时重试、资源隔离等容错机制的有效性，在故障真实发生前建立信心。Chaos Mesh 的安全边界设计确保实验不会扩散到非目标资源，回滚机制保证实验结束后系统自动恢复。

1.2 技术特点

丰富的故障类型：支持 PodChaos（杀容器/Pod）、NetworkChaos（延迟/丢包/分区）、IOChaos（读写延迟/错误）、StressChaos（CPU/内存压力）、TimeChaos（时钟偏移）、DNSChaos（DNS 劫持）等 10+ 种故障
精准的故障注入：基于 Label Selector、Namespace、PodPhase 等条件精确选择目标 Pod，支持随机选择、固定数量、百分比等策略
安全边界保护：通过 ProtectedNamespace、Admission Webhook 防止误操作系统关键组件，Chaos Controller Manager 需 RBAC 授权才能操作资源
声明式实验编排：Workflow CRD 支持串行/并行执行多个实验步骤，条件分支、暂停等待、循环重复等控制流
可观测性集成：内置 Prometheus 指标导出，记录实验执行历史、影响范围、恢复时长等关键数据，支持 Grafana 可视化
多语言客户端：提供 Go/Python/Java SDK，支持在 CI/CD 流水线中自动化执行混沌实验
物理机支持：Chaosd 组件支持对物理机、虚拟机注入故障，覆盖混合云场景

1.3 适用场景

场景一：验证熔断降级机制，通过注入网络延迟或服务不可用，确认熔断器在规定时间内触发，降级逻辑正确执行
场景二：测试数据库主从切换，模拟主库 Pod 删除，验证应用自动切换到从库，数据一致性检查，切换时长符合 SLA
场景三：压力测试资源限制，注入 CPU/内存压力触发 OOM 或限流，验证 Pod 重启后服务自动恢复，无数据丢失
场景四：网络分区测试，模拟跨可用区网络不通，验证分布式系统的脑裂处理、数据最终一致性
场景五：定时混沌演练，在非高峰时段自动执行混沌实验，持续验证系统韧性，及时发现配置变更引入的脆弱点

1.4 环境要求

组件	版本要求	说明
操作系统	Linux 内核 4.x+	需支持 cgroup、namespace、iptables
Kubernetes	1.20+	Chaos Mesh 3.0+ 要求 K8s 1.20+
Helm	3.5+	推荐使用 Helm 安装 Chaos Mesh
Docker/containerd	1.20+ / 1.5+	容器运行时，需支持 CRI 接口
权限要求	集群管理员	需创建 CRD、ClusterRole 等集群资源
硬件配置	2C4G	Controller Manager 推荐 4C8G

二、详细步骤

2.1 准备工作

2.1.1 系统检查

# 验证 Kubernetes 集群版本
kubectl version --short

# 检查节点状态和内核版本
kubectl get nodes -o wide

# 验证容器运行时
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.containerRuntimeVersion}'

# 检查是否已有混沌实验残留
kubectl get podchaos,networkchaos,iochaos,stresschaos --all-namespaces

# 验证 Helm 版本
helm version

2.1.2 安装依赖

# 添加 Chaos Mesh Helm 仓库
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update

# 创建命名空间
kubectl create namespace chaos-mesh

# 安装 Chaos Mesh（包含 Dashboard）
helm install chaos-mesh chaos-mesh/chaos-mesh \
  --namespace chaos-mesh \
  --set chaosDaemon.runtime=containerd \
  --set chaosDaemon.socketPath=/run/containerd/containerd.sock \
  --set dashboard.create=true \
  --set dashboard.securityMode=false \
  --version 2.6.0

# 等待所有组件就绪
kubectl wait --for=condition=available --timeout=300s \
  deployment/chaos-controller-manager \
  deployment/chaos-dashboard \
  -n chaos-mesh

# 验证 CRD 安装
kubectl get crd | grep chaos-mesh.org

说明：chaosDaemon.runtime 根据实际容器运行时选择（docker/containerd/crio），socketPath 需与节点实际路径匹配。生产环境建议启用 dashboard.securityMode 并配置认证。

2.2 核心配置

2.2.1 配置安全边界

# protected-namespaces.yaml
apiVersion:v1
kind:ConfigMap
metadata:
name:chaos-mesh
namespace:chaos-mesh
data:
# 受保护的命名空间，禁止注入故障
protected-namespaces:|
    - kube-system
    - kube-public
    - kube-node-lease
    - chaos-mesh
    - istio-system
    - monitoring

# 应用配置
kubectl apply -f protected-namespaces.yaml

# 重启 Controller Manager 生效
kubectl rollout restart deployment/chaos-controller-manager -n chaos-mesh

2.2.2 配置 RBAC 权限

# chaos-operator-role.yaml
apiVersion:rbac.authorization.k8s.io/v1
kind:ClusterRole
metadata:
name:chaos-operator
rules:
-apiGroups:["chaos-mesh.org"]
resources:["*"]
verbs:["create","get","list","watch","update","delete"]
-apiGroups:[""]
resources:["pods","pods/log","pods/exec"]
verbs:["get","list","watch"]
-apiGroups:["apps"]
resources:["deployments","statefulsets"]
verbs:["get","list"]
---
apiVersion:rbac.authorization.k8s.io/v1
kind:ClusterRoleBinding
metadata:
name:chaos-operator-binding
roleRef:
apiGroup:rbac.authorization.k8s.io
kind:ClusterRole
name:chaos-operator
subjects:
-kind:ServiceAccount
name:chaos-operator
namespace:default
---
apiVersion:v1
kind:ServiceAccount
metadata:
name:chaos-operator
namespace:default

# 创建专用 ServiceAccount
kubectl apply -f chaos-operator-role.yaml

参数说明：

chaos-mesh.org API Group：所有混沌实验 CRD 的权限
pods/log、pods/exec：部分实验类型（如 IOChaos）需执行命令注入故障
限制权限范围：生产环境应创建多个 ServiceAccount，分别授予不同命名空间的操作权限

2.2.3 暴露 Dashboard

# dashboard-ingress.yaml
apiVersion:networking.k8s.io/v1
kind:Ingress
metadata:
name:chaos-dashboard
namespace:chaos-mesh
annotations:
    nginx.ingress.kubernetes.io/rewrite-target:/
spec:
ingressClassName:nginx
rules:
-host:chaos.example.com
    http:
      paths:
      -path:/
        pathType:Prefix
        backend:
          service:
            name:chaos-dashboard
            port:
              number:2333

# 应用 Ingress
kubectl apply -f dashboard-ingress.yaml

# 或使用端口转发（开发测试）
kubectl port-forward -n chaos-mesh svc/chaos-dashboard 2333:2333

# 访问 Dashboard
# http://localhost:2333

2.3 启动和验证

2.3.1 创建测试应用

# test-app.yaml
apiVersion:apps/v1
kind:Deployment
metadata:
name:web-server
namespace:default
spec:
replicas:3
selector:
    matchLabels:
      app:web-server
template:
    metadata:
      labels:
        app:web-server
    spec:
      containers:
      -name:nginx
        image:nginx:1.25
        ports:
        -containerPort:80
        resources:
          requests:
            cpu:100m
            memory:128Mi
          limits:
            cpu:500m
            memory:512Mi
---
apiVersion:v1
kind:Service
metadata:
name:web-server
namespace:default
spec:
selector:
    app:web-server
ports:
-port:80
    targetPort:80

# 部署测试应用
kubectl apply -f test-app.yaml

# 验证应用运行
kubectl get pods -l app=web-server
kubectl run curl-test --image=curlimages/curl --rm -it --restart=Never -- curl -I http://web-server

2.3.2 执行第一个混沌实验

# pod-kill-experiment.yaml
apiVersion:chaos-mesh.org/v1alpha1
kind:PodChaos
metadata:
name:web-server-pod-kill
namespace:default
spec:
action:pod-kill
mode:one
selector:
    namespaces:
    -default
    labelSelectors:
      app:web-server
duration:"30s"
scheduler:
    cron:"@every 2m"

# 应用实验
kubectl apply -f pod-kill-experiment.yaml

# 观察 Pod 被杀死和重启
kubectl get pods -l app=web-server -w

# 查看实验状态
kubectl describe podchaos web-server-pod-kill

# 查看实验事件
kubectl get events --field-selector involvedObject.name=web-server-pod-kill

# 删除实验（停止定时执行）
kubectl delete podchaos web-server-pod-kill

预期结果：

NAME                          READY   STATUS    RESTARTS   AGE
web-server-7d4b6c8f9d-abc12   1/1     Running   0          5m
web-server-7d4b6c8f9d-def34   0/1     Terminating   0      3m  # 被 Chaos Mesh 杀死
web-server-7d4b6c8f9d-ghi56   1/1     Running   0          5m
web-server-7d4b6c8f9d-jkl78   0/1     ContainerCreating   0  1s  # Deployment 自动重建

三、示例代码和配置

3.1 完整配置示例

3.1.1 NetworkChaos - 网络延迟实验

# network-delay.yaml
apiVersion:chaos-mesh.org/v1alpha1
kind:NetworkChaos
metadata:
name:web-server-network-delay
namespace:default
spec:
action:delay
mode:all
selector:
    namespaces:
    -default
    labelSelectors:
      app:web-server
delay:
    latency:"200ms"
    correlation:"50"
    jitter:"50ms"
duration:"5m"
direction:to
target:
    mode:all
    selector:
      namespaces:
      -default
      labelSelectors:
        app:backend-service

参数说明：

action: delay：注入网络延迟，其他选项包括 loss（丢包）、duplicate（重复包）、corrupt（损坏包）、partition（网络分区）
latency: "200ms"：基础延迟时长
correlation: "50"：延迟相关性（0-100），值越高延迟越稳定
jitter: "50ms"：延迟抖动范围
direction: to：流量方向，to 表示目标 Pod 发出的流量，from 表示进入目标 Pod 的流量
target：可选，指定受影响的目标服务（不指定则影响所有流量）

3.1.2 IOChaos - 磁盘故障实验

# io-delay.yaml
apiVersion:chaos-mesh.org/v1alpha1
kind:IOChaos
metadata:
name:mysql-io-delay
namespace:default
spec:
action:delay
mode:one
selector:
    namespaces:
    -default
    labelSelectors:
      app:mysql
volumePath:/var/lib/mysql
path:"/var/lib/mysql/**/*"
delay:"200ms"
percent:50
duration:"5m"
containerNames:
-mysql

参数说明：

action: delay：IO 延迟，其他选项包括 errno（返回错误码）、attrOverride（修改文件属性）
volumePath：注入故障的挂载点路径
path：受影响的文件路径，支持通配符
percent: 50：50% 的 IO 操作受影响
containerNames：指定容器名称（Pod 内多容器场景）

3.1.3 StressChaos - 压力测试

# stress-cpu.yaml
apiVersion:chaos-mesh.org/v1alpha1
kind:StressChaos
metadata:
name:web-server-cpu-stress
namespace:default
spec:
mode:one
selector:
    namespaces:
    -default
    labelSelectors:
      app:web-server
stressors:
    cpu:
      workers:2
      load:80
    memory:
      workers:1
      size:"512MB"
duration:"3m"
containerNames:
-nginx

参数说明：

cpu.workers: 2：启动 2 个 CPU 压力进程
cpu.load: 80：每个进程占用 80% CPU
memory.size：分配并占用的内存大小
压力通过 stress-ng 工具实现，Chaos Daemon 注入到目标容器

3.2 实际应用案例

案例一：验证熔断器配置

场景描述：应用使用 Istio/Envoy 配置熔断策略，连续 5 次 5xx 错误后熔断 30 秒。通过注入网络故障触发熔断，验证降级逻辑。

实现代码：

# circuit-breaker-test.yaml
apiVersion:chaos-mesh.org/v1alpha1
kind:NetworkChaos
metadata:
name:backend-unavailable
namespace:default
spec:
action:loss
mode:all
selector:
    namespaces:
    -default
    labelSelectors:
      app:backend-service
loss:
    loss:"100"
    correlation:"100"
duration:"2m"
direction:from

# 启动实验
kubectl apply -f circuit-breaker-test.yaml

# 并发请求触发熔断
for i in {1..100}; do
  kubectl exec -it curl-test -- curl -s -o /dev/null -w "%{http_code}\n" http://frontend-service &
done

# 观察 Istio Envoy 指标
kubectl exec -it <frontend-pod> -c istio-proxy -- curl localhost:15000/stats | grep upstream_rq

# 清理实验
kubectl delete networkchaos backend-unavailable

运行结果：

# 前 5 次请求返回 503（backend 不可达）
503
503
503
503
503
# 熔断器打开，后续请求立即返回 503（不再请求 backend）
503
503
...
# 30 秒后熔断器半开，尝试恢复
200

案例二：数据库主从切换演练

场景描述：PostgreSQL 主从架构，使用 Patroni 管理高可用。模拟主库 Pod 删除，验证从库自动晋升，应用连接切换时长。

实现步骤：

准备监控脚本

#!/bin/bash
# monitor-db-switch.sh
whiletrue; do
  PRIMARY=$(kubectl exec -it postgres-0 -- patronictl list | grep Leader | awk '{print $2}')
  QUERY_TIME=$(kubectl exec -it app-pod -- psql -h postgres -U user -d db -c "SELECT now();" 2>&1 | grep ERROR || echo"OK")
  echo"$(date '+%H:%M:%S') | Primary: $PRIMARY | Query: $QUERY_TIME"
  sleep 1
done

执行 PodChaos 实验

# db-failover-test.yaml
apiVersion:chaos-mesh.org/v1alpha1
kind:PodChaos
metadata:
name:postgres-primary-kill
namespace:default
spec:
action:pod-kill
mode:one
selector:
    namespaces:
    -default
    labelSelectors:
      app:postgres
      role:master
duration:"10s"

分析切换过程

# 启动监控
./monitor-db-switch.sh &

# 执行实验
kubectl apply -f db-failover-test.yaml

# 观察输出
# 10:30:00 | Primary: postgres-0 | Query: OK
# 10:30:05 | Primary: postgres-0 | Query: ERROR connection refused
# 10:30:08 | Primary: postgres-1 | Query: ERROR connection refused
# 10:30:12 | Primary: postgres-1 | Query: OK
# 结论：切换时长 12 秒，其中 7 秒不可用

案例三：Workflow 编排复杂实验

场景描述：串行执行网络延迟 → 磁盘压力 → Pod 杀死，模拟多重故障场景，验证系统综合韧性。

实现步骤：

# complex-workflow.yaml
apiVersion:chaos-mesh.org/v1alpha1
kind:Workflow
metadata:
name:complex-chaos-workflow
namespace:default
spec:
entry:the-entry
templates:
-name:the-entry
    templateType:Serial
    deadline:30m
    children:
    -workflow-network-delay
    -workflow-io-stress
    -workflow-pod-kill
    -workflow-suspend
    -workflow-final-check

-name:workflow-network-delay
    templateType:NetworkChaos
    deadline:5m
    networkChaos:
      direction:to
      action:delay
      mode:all
      selector:
        labelSelectors:
          app:web-server
      delay:
        latency:"500ms"
      duration:"3m"

-name:workflow-io-stress
    templateType:IOChaos
    deadline:5m
    ioChaos:
      action:delay
      mode:one
      selector:
        labelSelectors:
          app:web-server
      volumePath:/var/log
      path:"/var/log/**/*"
      delay:"100ms"
      percent:80
      duration:"3m"

-name:workflow-pod-kill
    templateType:PodChaos
    deadline:2m
    podChaos:
      action:pod-kill
      mode:one
      selector:
        labelSelectors:
          app:web-server

-name:workflow-suspend
    templateType:Suspend
    deadline:2m
    suspend:
      duration:"1m"

-name:workflow-final-check
    templateType:Task
    deadline:5m
    task:
      container:
        name:check
        image:curlimages/curl:latest
        command:
        -sh
        --c
        -|
          for i in {1..10}; do
            CODE=$(curl -s -o /dev/null -w "%{http_code}" http://web-server)
            if [ "$CODE" != "200" ]; then
              echo "Health check failed: $CODE"
              exit 1
            fi
            sleep 1
          done
          echo "All checks passed"

# 执行 Workflow
kubectl apply -f complex-workflow.yaml

# 查看执行状态
kubectl get workflow complex-chaos-workflow -w

# 查看每个步骤状态
kubectl describe workflow complex-chaos-workflow

# 清理
kubectl delete workflow complex-chaos-workflow

四、最佳实践和注意事项

4.1 最佳实践

4.1.1 实验设计原则

原则一：小范围开始，逐步扩大

# 第一阶段：单个 Pod
spec:
mode:one

# 第二阶段：固定数量
spec:
mode:fixed
value:"2"

# 第三阶段：百分比
spec:
mode:fixed-percent
value:"30"

# 第四阶段：全部 Pod
spec:
mode:all

原则二：建立观测基线

# 实验前记录正常指标
kubectl exec -it prometheus-0 -- promtool query instant \
  'rate(http_requests_total[5m])'

# 实验中对比异常指标
kubectl exec -it prometheus-0 -- promtool query instant \
  'rate(http_requests_errors[5m])'

原则三：定义明确的成功标准

熔断器在 5 秒内触发
降级接口可用性 > 99%
数据库切换时长 < 30 秒
无数据丢失或不一致

4.1.2 安全防护措施

措施一：配置资源选择器保护

# 使用 fieldSelectors 精确选择
spec:
selector:
    namespaces:
    -default
    labelSelectors:
      app:web-server
      environment:staging# 避免误操作生产环境
    fieldSelectors:
    -key:spec.nodeName
      operator:In
      values:
      -node-01
      -node-02

措施二：启用 Admission Webhook 审计

# chaos-mesh values.yaml
webhook:
certManager:
    enabled:true
failurePolicy:Fail# 验证失败则拒绝实验
timeoutSeconds:5
FailureInjectionNamespaces:
-default
-staging

措施三：配置自动恢复机制

spec:
  duration:"5m"  # 强制 5 分钟后自动停止
  scheduler:
    cron:"@every 1h"
    concurrencyPolicy:Forbid  # 禁止并发执行
    startingDeadlineSeconds:300

4.1.3 持续演练策略

策略一：定时自动化演练

# 每周五凌晨 2 点执行
spec:
  scheduler:
    cron:"0 2 * * 5"

策略二：集成 CI/CD 流水线

# GitLab CI 示例
chaos-test:
stage:test
script:
-kubectlapply-fchaos/network-delay.yaml
-sleep300
-kubectldelete-fchaos/network-delay.yaml
-./scripts/verify-metrics.sh
only:
-schedules

策略三：游戏日(Game Day)演练

每月组织跨团队演练，模拟真实故障场景
记录问题发现、沟通协作、恢复时长
输出改进计划并跟踪落实

4.2 注意事项

4.2.1 配置注意事项

⚠️ 警告：生产环境必须配置 protectedNamespaces、启用 Webhook 验证、限制 RBAC 权限，避免误操作核心组件。

❗ 注意事项一：duration 未配置时实验永久生效，必须手动删除 CRD 资源才能恢复
❗ 注意事项二：mode: all 可能影响所有符合条件的 Pod，务必通过 labelSelectors 精确限定范围
❗ 注意事项三：IOChaos 和 StressChaos 依赖 Chaos Daemon 在节点执行特权操作，需谨慎授权

4.2.2 常见错误

错误现象	原因分析	解决方案
Experiment stuck in "Running"	duration 过期但未自动清理	手动删除 CRD 资源或重启 Controller Manager
No pods selected	Label Selector 不匹配	使用 kubectl get pods -l <selector> 验证
Permission denied	ServiceAccount 权限不足	检查 RBAC 配置，授予 chaos-mesh.org API 权限
IOChaos not working	容器运行时配置错误	验证 chaosDaemon.socketPath 与节点实际路径匹配
Workflow execution failed	某个步骤超时或失败	查看 Workflow 事件，调整 deadline 参数

4.2.3 兼容性问题

版本兼容：Chaos Mesh 2.6+ 要求 Kubernetes 1.20+，使用旧版 K8s 需安装 2.5.x
平台兼容：ARM 架构需使用专用镜像 chaos-mesh/chaos-mesh:v2.6.0-arm64
组件依赖：TimeChaos 需内核支持 PTP_SYS_OFFSET，部分云环境虚拟机不支持

五、故障排查和监控

5.1 故障排查

5.1.1 日志查看

# 查看 Controller Manager 日志
kubectl logs -n chaos-mesh deployment/chaos-controller-manager --tail=100 -f

# 查看 Chaos Daemon 日志（节点级组件）
kubectl logs -n chaos-mesh daemonset/chaos-daemon -c chaos-daemon --tail=100

# 查看 Dashboard 日志
kubectl logs -n chaos-mesh deployment/chaos-dashboard --tail=100 -f

# 查看实验执行记录
kubectl get events --field-selector involvedObject.kind=PodChaos -n default

# 查看 Workflow 步骤日志
kubectl logs -n default workflow-complex-chaos-workflow-<pod-name>

5.1.2 常见问题排查

问题一：实验创建成功但未生效

# 诊断命令
kubectl describe podchaos web-server-pod-kill

# 检查 Controller Manager 日志
kubectl logs -n chaos-mesh deployment/chaos-controller-manager | grep "web-server-pod-kill"

# 验证 Label Selector
kubectl get pods -l app=web-server --show-labels

解决方案：

检查 Selector 是否匹配目标 Pod
验证目标命名空间未在 protectedNamespaces 列表
确认 duration 未过期

问题二：IOChaos 返回 Permission Denied

# 诊断命令
kubectl logs -n chaos-mesh daemonset/chaos-daemon | grep "io chaos"

# 检查 Chaos Daemon 权限
kubectl exec -it -n chaos-mesh chaos-daemon-<pod> -- ls -la /run/containerd/containerd.sock

解决方案：

验证 chaosDaemon.socketPath 配置正确
检查节点容器运行时类型（docker/containerd）
确认 Chaos Daemon 有访问 socket 的权限

问题三：Workflow 卡在某个步骤

症状：Workflow 状态显示 Running，但某个 Template 长时间未完成

排查：

# 查看 Workflow 详情
kubectl describe workflow complex-chaos-workflow

# 查看当前执行的步骤
kubectl get podchaos,networkchaos,iochaos -n default

解决：调整步骤的 deadline 参数，或手动删除卡住的 Chaos 资源

5.1.3 调试模式

# 开启 Controller Manager 调试日志
kubectl set env -n chaos-mesh deployment/chaos-controller-manager LOG_LEVEL=debug

# 开启 Chaos Daemon 详细日志
kubectl set env -n chaos-mesh daemonset/chaos-daemon LOG_LEVEL=debug

# 查看 Chaos Daemon 执行的具体命令
kubectl exec -it -n chaos-mesh chaos-daemon-<pod> -- cat /var/log/chaos-daemon.log

5.2 性能监控

5.2.1 关键指标监控

# 实验执行统计
kubectl get podchaos,networkchaos,iochaos,stresschaos --all-namespaces

# Controller Manager 资源使用
kubectl top pod -n chaos-mesh -l app.kubernetes.io/component=controller-manager

# Chaos Daemon 资源使用（每个节点）
kubectl top pod -n chaos-mesh -l app.kubernetes.io/component=chaos-daemon

# 查看实验执行时长
kubectl get workflow complex-chaos-workflow -o jsonpath='{.status.startTime}'
kubectl get workflow complex-chaos-workflow -o jsonpath='{.status.endTime}'

5.2.2 监控指标说明

指标名称	正常范围	告警阈值	说明
chaos_mesh_experiments	-	异常率 >10%	实验执行成功率统计
chaos_daemon_cpu_usage	<500m	>1000m	Daemon 消耗 CPU，高值可能影响节点
chaos_controller_reconcile_duration	<1s	>5s	Controller 协调循环耗时
workflow_step_duration	按步骤定义	超时	Workflow 每个步骤执行时长
target_pod_restart_count	-	增长异常	目标 Pod 重启次数，区分正常重启和异常

5.2.3 监控告警配置

# prometheus-rule.yaml
apiVersion:monitoring.coreos.com/v1
kind:PrometheusRule
metadata:
name:chaos-mesh-alerts
namespace:chaos-mesh
spec:
groups:
-name:chaos-mesh
    interval:30s
    rules:
    -alert:ChaosExperimentFailed
      expr:|
        chaos_mesh_experiments{phase="Failed"} > 0
      for:1m
      labels:
        severity:warning
      annotations:
        summary:"混沌实验执行失败"
        description:"实验 {{ $labels.name }} 执行失败"

    -alert:ChaosDaemonHighCPU
      expr:|
        sum(rate(container_cpu_usage_seconds_total{pod=~"chaos-daemon.*"}[5m])) by (pod) > 1
      for:5m
      labels:
        severity:warning
      annotations:
        summary:"Chaos Daemon CPU 使用率过高"
        description:"节点 {{ $labels.pod }} 的 Chaos Daemon CPU 使用超过 1 核"

    -alert:WorkflowStepTimeout
      expr:|
        time() - chaos_mesh_workflow_step_start_time > chaos_mesh_workflow_step_deadline
      for:1m
      labels:
        severity:critical
      annotations:
        summary:"Workflow 步骤执行超时"
        description:"Workflow {{ $labels.workflow }} 步骤 {{ $labels.step }} 超时"

5.3 备份与恢复

5.3.1 备份策略

#!/bin/bash
# chaos-backup.sh
# 功能：备份所有混沌实验定义

BACKUP_DIR="/backup/chaos-mesh/$(date +%Y%m%d)"
mkdir -p "${BACKUP_DIR}"

# 备份所有 Chaos 资源
for kind in podchaos networkchaos iochaos stresschaos timechaos dnschaos kernelchaos; do
  kubectl get ${kind} --all-namespaces -o yaml > "${BACKUP_DIR}/${kind}.yaml"
done

# 备份 Workflow
kubectl get workflow --all-namespaces -o yaml > "${BACKUP_DIR}/workflows.yaml"

# 备份 Schedule（定时任务）
kubectl get schedule --all-namespaces -o yaml > "${BACKUP_DIR}/schedules.yaml"

# 备份配置
kubectl get cm -n chaos-mesh chaos-mesh -o yaml > "${BACKUP_DIR}/config.yaml"

# 压缩备份
tar -czf "${BACKUP_DIR}.tar.gz""${BACKUP_DIR}"

echo"Backup completed: ${BACKUP_DIR}.tar.gz"

5.3.2 恢复流程

停止所有正在运行的实验

# 删除所有 Chaos 资源
kubectl delete podchaos --all --all-namespaces
kubectl delete networkchaos --all --all-namespaces
kubectl delete iochaos --all --all-namespaces
kubectl delete stresschaos --all --all-namespaces
kubectl delete workflow --all --all-namespaces

恢复实验定义

# 解压备份
tar -xzf /backup/chaos-mesh/20240315.tar.gz -C /tmp

# 恢复资源（不会立即执行，需手动触发）
kubectl apply -f /tmp/20240315/

验证恢复

# 检查资源状态
kubectl get podchaos,networkchaos,workflow --all-namespaces

# 测试单个实验
kubectl apply -f /tmp/20240315/podchaos.yaml
kubectl describe podchaos <name>

清理残留状态

# 检查是否有卡住的实验
kubectl get events --all-namespaces | grep chaos

# 重启 Controller Manager
kubectl rollout restart deployment/chaos-controller-manager -n chaos-mesh

六、总结

6.1 技术要点回顾

✅ 混沌工程价值：主动故障注入发现系统弱点，建立容错机制信心，降低真实故障影响
✅ Chaos Mesh 能力：丰富的故障类型覆盖 Pod/网络/IO/压力等场景，声明式配置易于自动化
✅ 安全边界设计：Protected Namespace、RBAC、Admission Webhook 多层防护，避免误操作核心组件
✅ 实验编排：Workflow 支持串行/并行/条件/循环，构建复杂故障场景，模拟真实生产问题
✅ 可观测性：内置 Prometheus 指标、事件记录、执行历史，支持实验效果量化分析

6.2 进阶学习方向

物理机混沌工程：使用 Chaosd 对虚拟机、裸金属服务器注入故障，覆盖混合云场景
- 学习资源：https://chaos-mesh.org/docs/simulate-physical-machine-chaos/
- 实践建议：从网络延迟、磁盘满开始，逐步扩展到内核故障、时钟偏移
混沌工程平台化：基于 Chaos Mesh 构建企业级混沌工程平台，集成审批流、权限管控、实验模板库
- 学习资源：https://github.com/chaos-mesh/chaos-mesh/tree/master/examples
- 实践建议：设计实验分级制度（L0 安全实验、L1 影响有限、L2 高风险），配置自动回滚
故障注入与可观测性联动：实验触发时自动创建 Grafana Annotation，关联监控指标和实验事件
- 学习资源：Grafana Annotation API
- 实践建议：开发 Chaos Mesh Webhook，实验开始/结束时调用 Grafana API 标记时间点

6.3 参考资料

Chaos Mesh 官方文档 - 完整的安装、配置、故障类型说明
混沌工程原则 - Netflix 提出的混沌工程方法论
Chaos Mesh GitHub - 源码、Issue、Roadmap
CNCF Chaos Engineering Landscape - 云原生混沌工程工具全景
《Chaos Engineering》 - O'Reilly 出版的混沌工程实践指南

附录

A. 命令速查表

# 安装和管理
helm install chaos-mesh chaos-mesh/chaos-mesh -n chaos-mesh --version 2.6.0
helm upgrade chaos-mesh chaos-mesh/chaos-mesh -n chaos-mesh
helm uninstall chaos-mesh -n chaos-mesh

# 实验管理
kubectl apply -f experiment.yaml                # 创建实验
kubectl get podchaos,networkchaos --all-namespaces  # 查看所有实验
kubectl describe podchaos <name>                # 查看实验详情
kubectl delete podchaos <name>                  # 停止实验
kubectl get events --field-selector involvedObject.kind=PodChaos  # 查看实验事件

# Workflow 管理
kubectl apply -f workflow.yaml                  # 创建 Workflow
kubectl get workflow                            # 查看 Workflow 状态
kubectl describe workflow <name>                # 查看执行详情
kubectl delete workflow <name>                  # 删除 Workflow

# 日志和调试
kubectl logs -n chaos-mesh deployment/chaos-controller-manager -f
kubectl logs -n chaos-mesh daemonset/chaos-daemon -c chaos-daemon -f
kubectl exec -it -n chaos-mesh chaos-daemon-<pod> -- sh

B. 配置参数详解

PodChaos Actions：

pod-kill：杀死 Pod（SIGKILL）
pod-failure：Pod 不可用（修改 Pod 状态）
container-kill：杀死容器（SIGKILL）

NetworkChaos Actions：

delay：网络延迟，参数：latency、jitter、correlation
loss：丢包，参数：loss、correlation
duplicate：重复包，参数：duplicate、correlation
corrupt：包损坏，参数：corrupt、correlation
partition：网络分区，参数：direction、target
bandwidth：带宽限制，参数：rate、limit、buffer

IOChaos Actions：

delay：IO 延迟，参数：delay、percent
errno：返回错误码，参数：errno、percent
attrOverride：修改文件属性，参数：attr

StressChaos Stressors：

cpu：CPU 压力，参数：workers、load
memory：内存压力，参数：workers、size

C. 术语表

术语	英文	解释
混沌工程	Chaos Engineering	通过主动注入故障验证系统韧性的方法论
故障注入	Fault Injection	向系统引入异常行为（网络延迟、Pod 崩溃等）
韧性	Resilience	系统在故障情况下保持服务可用的能力
稳态	Steady State	系统正常运行时的基线指标状态
爆炸半径	Blast Radius	故障影响范围，混沌实验应控制爆炸半径
游戏日	Game Day	团队集中演练故障场景的活动
自动回滚	Auto Rollback	实验结束后自动恢复系统到正常状态
Workflow	工作流	编排多个混沌实验的执行顺序和依赖关系

好了，今天的分享就到这吧，觉得有用的话，别忘了点赞、在看、转发给身边需要的程序员朋友吧～

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2026-01-11，如有侵权请联系 cloudcommunity@tencent.com 删除

系统

本文分享自测试开发技术微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！