KnoAI 技术站

主题

21 — 混沌工程深度教材 ​

混沌工程是验证系统韧性的主动手段。本章覆盖 Chaos Mesh 架构、故障注入类型、实验设计、生产安全。

1. 混沌工程原理 ​

混沌工程核心思想：
  主动注入故障 → 观察系统行为 → 发现潜在弱点 → 加固系统

实验流程：
  1. 定义稳态指标（QPS、延迟、错误率）
  2. 建立假设（注入故障后系统应保持可用）
  3. 注入故障（最小爆炸半径）
  4. 观察结果
  5. 修复发现的问题

五大故障类型：
  1. Pod 故障（删除、挂起）
  2. 网络故障（延迟、丢包、分区）
  3. 节点故障（宕机、CPU/内存压力）
  4. IO 故障（磁盘延迟、满盘）
  5. 应用故障（进程 kill、JVM 异常）

2. Chaos Mesh（CNCF 孵化项目） ​

2.1 安装与架构 ​

bash
# 安装 Chaos Mesh
helm install chaos-mesh chaos-mesh/chaos-mesh \
  --namespace chaos-testing --create-namespace \
  --set chaosDaemon.runtime=containerd \
  --set chaosDaemon.socketPath=/run/containerd/containerd.sock

# 架构组件：
# chaos-dashboard  → Web UI
# chaos-controller → 控制器（管理实验生命周期）
# chaos-daemon     → 每个节点运行的 DaemonSet（执行故障注入）
# chaosd           → 物理机故障注入

2.2 实验类型 ​

yaml
# 1. Pod Chaos — 随机删除 Pod
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-test
  namespace: chaos-testing
spec:
  action: pod-kill           # pod-kill / pod-failure / container-kill
  mode: one                  # one / all / fixed-percent / random-max-percent
  selector:
    namespaces: [production]
    labelSelectors:
      app: web-app
  duration: "5m"             # 实验持续时间
  gracePeriod: 0

---
# 2. Network Chaos — 注入网络延迟和丢包
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay
spec:
  action: delay              # delay / loss / duplicate / corrupt / partition
  mode: all
  selector:
    namespaces: [production]
    labelSelectors:
      app: web-app
  delay:
    latency: "200ms"         # 延迟 200ms
    jitter: "50ms"           # 抖动 50ms
    correlation: "25"
  loss:
    loss: "10"               # 丢包 10%
  duration: "5m"

---
# 3. IO Chaos — 磁盘延迟
apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: io-delay
spec:
  action: latency
  mode: all
  selector:
    namespaces: [production]
    labelSelectors:
      app: database
  delay: "100ms"             # 磁盘 IO 延迟 100ms
  path: "/var/lib/mysql"
  percent: 100
  duration: "5m"

---
# 4. Stress Chaos — CPU/内存压力
apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: cpu-stress
spec:
  mode: one
  selector:
    namespaces: [production]
    labelSelectors:
      app: web-app
  stressors:
    cpu:
      workers: 4             # 4 个 CPU 压力线程
      load: 80               # 80% CPU 使用率
    memory:
      workers: 1
      size: "512MB"          # 消耗 512MB 内存
  duration: "5m"

---
# 5. Time Chaos — 时间偏移
apiVersion: chaos-mesh.org/v1alpha1
kind: TimeChaos
metadata:
  name: time-skew
spec:
  mode: one
  selector:
    namespaces: [production]
    labelSelectors:
      app: time-sensitive-app
  timeOffset: "-5m"          # 时间倒退 5 分钟
  duration: "2m"

3. 生产安全实践 ​

混沌工程安全原则：

1. 最小爆炸半径
   - 先在开发环境实验
   - 先在单个 Pod 实验
   - 先短时间实验（1-2 分钟）

2. 安全终止
   - 设置明确的终止条件（错误率 > 阈值时自动停止）
   - 实验完成后自动恢复
   - 提供紧急停止按钮

3. 监控与观察
   - 实验期间实时监控 Grafana 看板
   - 设置额外告警规则
   - 记录实验前后指标对比

4. 生产实验时间窗口
   - 低峰期实验
   - 避开大促/发版时间
   - 确保团队 On-Call
yaml
# 定时实验（每周二上午 10 点）
apiVersion: chaos-mesh.org/v1alpha1
kind: Schedule
metadata:
  name: weekly-chaos
spec:
  schedule: "0 10 * * 2"     # cron 表达式
  type: PodChaos
  podChaos:
    action: pod-kill
    mode: one
    selector:
      namespaces: [staging]
      labelSelectors:
        app: web-app

4. 面试高频问题 ​

Q: 混沌工程和传统测试有什么区别？

传统测试：验证已知场景（单元测试、集成测试）
混沌工程：发现未知弱点（生产环境真实故障模拟）

混沌工程验证的内容：
1. 高可用是否真的有效（Pod 删除后服务是否自动恢复）
2. 超时重试是否合理（网络延迟 200ms 后系统行为）
3. 监控告警是否及时（故障后多久收到告警）
4. 灾备切换是否顺畅（节点宕机后流量是否切换）

Q: 如何说服团队引入混沌工程？

1. 从低风险实验开始（开发环境删除一个 Pod）
2. 展示价值（发现真实问题，如超时配置不合理）
3. 与 SLO 结合（混沌实验验证 SLO 是否可达）
4. 定期演练（GameDay，团队一起观察和讨论）
5. 自动化（CI/CD 集成，每次发布前自动运行）