Chaos Mesh 混沌工程实战：从零构建韧性测试体系

云栈社区集结了大量深耕云原生技术的开发者，今天我们就来深入探讨，如何利用 CNCF 旗下的 Chaos Mesh 为你的系统主动注入故障，检验“韧性”的成色。

在现代微服务架构下，服务间的依赖关系错综复杂，级联故障和雪崩效应往往难以通过传统测试手段发现。混沌工程的价值，就在于通过主动注入故障，提前暴露分布式系统中的未知弱点，验证容错机制是否真的有效。Chaos Mesh 作为 CNCF 托管的云原生混沌工程平台，提供了一整套丰富的故障注入能力，覆盖 Pod 故障、网络异常、IO 延迟、压力测试等多种实验类型。它最大的不同在于，通过 Kubernetes CRD 将故障场景代码化，支持定时执行、条件触发乃至自动回滚，让原本“心惊胆战”的故障演练，变成一套可编排、可观测、可控的标准化流程。同时，其完善的安全边界设计，也确保实验不会扩散到非目标资源，保证了测试的可控性。

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 删除，验证从库自动晋升，以及应用连接切换时长。

实现步骤：

1. 准备监控脚本

#!/bin/bash
# monitor-db-switch.sh
while true; 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

2. 执行 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"

3. 分析切换过程

# 启动监控
./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:
  - kubectl apply -f chaos/network-delay.yaml
  - sleep 300
  - kubectl delete -f chaos/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

解决方案：

1. 检查 Selector 是否匹配目标 Pod。
2. 验证目标命名空间是否在 protectedNamespaces 列表中。
3. 确认 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

解决方案：

1. 验证 chaosDaemon.socketPath 配置正确。
2. 检查节点容器运行时类型（docker/containerd）。
3. 确认 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 调试模式

```bash
# 开启 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 恢复流程

1. 停止所有正在运行的实验

# 删除所有 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

2. 恢复实验定义

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

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

3. 验证恢复

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

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

4. 清理残留状态

# 检查是否有卡住的实验
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 进阶学习方向

1. 物理机混沌工程：使用 Chaosd 对虚拟机、裸金属服务器注入故障，覆盖混合云场景。可以从网络延迟、磁盘写满开始，逐步扩展到内核故障与时钟偏移。
2. 混沌工程平台化：基于 Chaos Mesh 构建企业级混沌工程平台，集成审批流、权限管控和实验模板库。设计实验分级制度（L0 安全实验、L1 影响有限、L2 高风险），并配以自动回滚策略。你可直接参阅 Chaos Mesh 的 GitHub 仓库，其中 examples 目录提供了丰富的参考实践。
3. 故障注入与可观测性联动：实验触发时，利用 Chaos Mesh Webhook 自动调用 Grafana Annotation API 创建时间标记，将监控指标和实验事件精准关联，这在事后的复盘分析中价值巨大。

6.3 参考资料

• Chaos Mesh 官方文档 - 完整的安装、配置、故障类型说明

• 混沌工程原则 - Netflix 提出的混沌工程方法论

• 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	工作流	编排多个混沌实验的执行顺序和依赖关系