Chaos Mesh混沌工程实战：Kubernetes故障注入与系统韧性验证

Chaos Mesh是CNCF托管的混沌工程平台，专为Kubernetes环境设计，通过向集群中注入各类故障来验证系统的容错能力。本文覆盖Chaos Mesh的安装部署、故障实验设计、稳态验证和结果分析全流程。

Chaos Mesh架构与Kubernetes集群部署

Chaos Mesh以Kubernetes Custom Resource Definition（CRD）方式运行，核心组件包括chaos-controller-manager（控制器）、chaos-daemon（守护进程）和chaos-dashboard（可视化面板）。

# 安装Chaos Mesh
kubectl create ns chaos-mesh
helm install chaos-mesh chaos-mesh/chaos-mesh \
    -n chaos-mesh \
    --set chaosDaemon.runtime=containerd \
    --set dashboard.securityMode=false \
    --version 2.7.0

# 验证安装
kubectl get pods -n chaos-mesh
# NAME                                        READY   STATUS
# chaos-controller-manager-xxx                1/1     Running
# chaos-daemon-xxx                            1/1     Running
# chaos-dashboard-xxx                         1/1     Running

# 查看已注册的CRD
kubectl get crd | grep chaos

chaos-daemon以DaemonSet方式部署在每个节点上，负责执行具体的故障注入操作。runtime参数需与容器运行时匹配，Docker环境设为docker，containerd环境设为containerd。

网络故障注入实验设计

网络故障是最常见的混沌实验类型。Chaos Mesh的NetworkChaos CRD支持延迟、丢包、重复、损坏和带宽限制等网络异常。

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-service-network-delay
  namespace: default
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - default
    labelSelectors:
      app: payment-service
  delay:
    latency: "200ms"
    correlation: "100"
    jitter: "50ms"
  direction: to
  target:
    selector:
      namespaces:
        - default
      labelSelectors:
        app: order-service
    mode: all
  duration: "5m"
  scheduler:
    cron: "@every 1h"

上述实验向payment-service到order-service的所有出站流量注入200ms正负50ms的网络延迟，持续5分钟。correlation=100表示每次延迟值都相关，jitter增加随机性使延迟更接近真实网络抖动。

网络分区故障验证服务的降级逻辑：

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: db-partition
  namespace: default
spec:
  action: partition
  mode: all
  selector:
    labelSelectors:
      app: api-gateway
  direction: to
  target:
    selector:
      labelSelectors:
        app: postgresql
    mode: all
  duration: "2m"

该实验切断API网关与PostgreSQL之间的所有网络通信。系统应在连接池超时后触发熔断器，返回降级响应而非长时间阻塞。

Pod故障与资源压力注入

PodChaos模拟Pod级别的故障，包括随机删除、容器退出和容器挂起：

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: random-pod-kill
  namespace: default
spec:
  action: pod-kill
  mode: one
  selector:
    labelSelectors:
      app: worker
  scheduler:
    cron: "@every 10m"
  duration: ""

pod-kill模式直接删除目标Pod，验证Kubernetes的自动重建机制和服务的无状态性。mode: one表示每次随机选择一个Pod，mode: all则同时删除所有匹配Pod。对有状态服务（如数据库主从架构）进行此实验，可以验证故障转移是否正常触发。

StressChaos向容器注入CPU和内存压力：

apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: cpu-memory-stress
  namespace: default
spec:
  mode: all
  selector:
    labelSelectors:
      app: order-service
  stressors:
    cpu:
      workers: 4
      load: 80
    memory:
      workers: 2
      size: "512MB"
  duration: "3m"

该实验在order-service容器内启动4个CPU压力进程（80%负载）和2个内存压力进程（各512MB），持续3分钟。通过监控观察服务的响应时间、错误率和资源使用变化，评估服务在资源紧张时的行为表现。

IO故障注入与磁盘压力测试

IOChaos模拟磁盘读写异常，适用于验证数据持久化和日志写入的容错策略：

apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: io-latency-injection
  namespace: default
spec:
  action: latency
  mode: all
  selector:
    labelSelectors:
      app: log-collector
  delay: "500ms"
  path: "/var/log/**/*"
  percent: 50
  volumePath: "/data"
  duration: "5m"

percent=50表示50%的IO操作被注入500ms延迟。对日志采集服务注入此故障，验证其批量写入、异步刷新和背压机制是否有效。

稳态假设与实验结果分析

混沌实验的价值在于验证系统在故障条件下仍能满足稳态假设。实验前需明确定义可量化的SLO指标：

稳态假设示例：
1. API P99延迟 < 500ms（故障注入期间允许放宽至2s）
2. 错误率 < 1%（故障注入期间允许放宽至5%）
3. 核心交易接口可用性 > 99.9%
4. Pod自动恢复时间 < 30s

实验过程中通过Prometheus采集指标，使用以下PromQL查询验证稳态：

# P99延迟
histogram_quantile(0.99, 
  rate(http_request_duration_seconds_bucket[5m]))

# 错误率
sum(rate(http_requests_total{status=~"5.."}[5m])) / 
sum(rate(http_requests_total[5m]))

# Pod恢复时间
time() - kube_pod_created{pod=~"worker-.*"}

实验结束后生成报告，记录故障类型、注入参数、系统表现和发现的问题。对于未通过稳态假设的实验，需追踪到具体的代码缺陷或配置问题。常见发现包括：连接池未设置超时导致级联失败、熔断器阈值不合理、重试逻辑引发雪崩、Pod反亲和性配置缺失导致同节点多Pod同时被杀。

Chaos Mesh的Schedule模式支持周期性自动执行实验，将混沌工程从一次性验证变为持续性的韧性测试。建议在预发环境保持每周至少一次的全量混沌实验，在每次重大版本发布前执行针对性的故障注入验证。