云原生混沌工程实战指南：使用Chaos Mesh构建Kubernetes系统韧性测试体系

一、概述

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

实现步骤：

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 调试模式

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

6.3 参考资料

• Chaos Mesh 官方文档 - 包含完整的安装、配置及各故障类型的详细说明。
• 混沌工程原则 - 由 Netflix 提出的混沌工程核心方法论。
• Chaos Mesh GitHub - 查看源代码、提交 Issue 和了解项目路线图。
• CNCF Chaos Engineering Landscape - 了解云原生混沌工程领域的工具全景图。
• 《Chaos Engineering》 - O'Reilly 出版的混沌工程实践指南。

如果你在实践 Chaos Mesh 或混沌工程过程中有任何心得或疑问，欢迎到 云栈社区 的相关板块与更多开发者交流讨论。

---

附录

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