> **本文是「架构实战·第二季」第 48 篇**。上一篇讲了混沌工程的起源和原则，这一篇讲落地——用 ChaosBlade 和 Chaos Mesh 这两个 CNCF 主流工具，搭建一个能跑在生产环境的混沌工程平台。

---

## 引子：工具选型踩的坑

2024 年我们做混沌工程平台选型时，面临四个候选：

1. **Chaos Monkey**（Netflix，2012 年后基本没维护）
2. **Gremlin**（商业，最强但贵）
3. **ChaosBlade**（阿里，CNCF）
4. **Chaos Mesh**（PingCAP，CNCF）

我们试了一周：

- Chaos Monkey 跑在 K8s 上要自己改一堆东西；
- Gremlin 每个 SRE 账号 100 美元/月，100 人就是 12 万/年；
- ChaosBlade 功能多但 K8s 集成一般；
- **Chaos Mesh K8s 原生最好用，但只支持 K8s 场景**。

最后我们**两个都用**：

- **Chaos Mesh** 管 K8s 上的所有实验（90% 场景）；
- **ChaosBlade** 管主机/中间件/数据库场景（10% 场景）。

---

## 一、两个工具的定位差异

| 维度 | Chaos Mesh | ChaosBlade |
|------|-----------|------------|
| **出身** | PingCAP，CNCF（2021） | 阿里，CNCF（2021） |
| **核心定位** | K8s 原生混沌实验平台 | 多平台故障注入工具集 |
| **架构** | Controller + Dashboard | CLI + Agent |
| **支持场景** | K8s Pod/Network/IO/Stress/DNS/Time | JVM/容器/网络/磁盘/进程/数据库 |
| **学习曲线** | 中（K8s 友好） | 低（CLI 简单） |
| **可视化** | 内置 Dashboard | 无（依赖外部） |
| **实验编排** | 强（Workflow 支持） | 中（CLI 组合） |
| **社区** | 活跃（CNCF 沙箱） | 活跃（CNCF 沙箱） |
| **生产成熟度** | 高 | 高 |

**一句话总结**：

- **Chaos Mesh = K8s 上的混沌工程"操作系统"**
- **ChaosBlade = 多平台故障注入"瑞士军刀"**

---

## 二、Chaos Mesh 部署

### 2.1 安装

```bash
# 添加 Helm repo
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update

# 创建 namespace
kubectl create namespace chaos-mesh

# 安装（生产配置）
helm install chaos-mesh chaos-mesh/chaos-mesh \
  --namespace chaos-mesh \
  --version 2.7.0 \
  --set chaosDaemon.runtime=containerd \
  --set chaosDaemon.socketPath=/run/containerd/containerd.sock \
  --set chaosDaemon.criNamespace=k8s.io \
  --set controllerManager.replicaCount=2 \
  --set dashboard.securityMode=true \
  --set dashboard.persistentVolume.enabled=true \
  --set dashboard.persistentVolume.size=10Gi
```

### 2.2 核心组件

```
chaos-mesh namespace
├── chaos-controller-manager    # 控制器
├── chaos-daemon                # 每个 Node 一个，负责注入故障
├── chaos-dashboard             # Web UI
├── chaos-daemon-metrics        # Prometheus 集成
└── chaos-mesh-metrics          # 监控
```

**关键点**：

- `chaos-daemon` 以 DaemonSet 跑在每个节点，**故障注入不通过 K8s API**，直接操作 cgroup/netfilter；
- `chaos-controller-manager` 是无状态服务，可以水平扩展；
- `chaos-dashboard` 是 Web UI，可以**可视化编排实验**。

### 2.3 RBAC 权限

```yaml
# 给某个 namespace 注入故障的权限
apiVersion: v1
kind: ServiceAccount
metadata:
  name: chaos-experimenter
  namespace: chaos-mesh
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: chaos-experimenter
  namespace: prod-api
rules:
  - apiGroups: [chaos-mesh.org]
    resources: [podchaos, networkchaos, stresschaos]
    verbs: [get, list, watch, create, update, patch, delete]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: chaos-experimenter
  namespace: prod-api
subjects:
  - kind: ServiceAccount
    name: chaos-experimenter
    namespace: chaos-mesh
roleRef:
  kind: Role
  name: chaos-experimenter
  apiGroup: rbac.authorization.k8s.io
```

**最小权限原则**：每个团队只能在自己 namespace 做实验。

---

## 三、Chaos Mesh 核心实验类型

### 3.1 PodChaos（Pod 故障）

```yaml
# Pod 随机杀
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-1
  namespace: chaos-mesh
spec:
  action: pod-kill
  mode: one                    # one / all / fixed / fixed-percent
  selector:
    namespaces:
      - prod-api
    labelSelectors:
      app: api-service
  duration: "30s"
  scheduler:
    cron: "@every 1h"          # 每小时一次
---
# Pod 持续重启
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-restart
spec:
  action: pod-restart
  mode: one
  selector:
    namespaces: [prod-api]
    labelSelectors:
      app: api-service
  duration: "1m"
```

### 3.2 NetworkChaos（网络故障）

```yaml
# 注入网络延迟
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay
spec:
  action: delay
  mode: all
  selector:
    namespaces: [prod-api]
    labelSelectors:
      app: api-service
  delay:
    latency: "200ms"
    jitter: "50ms"
    correlation: "75"          # 75% 的包受影响
  direction: to               # 出站方向
  duration: "5m"
---
# 注入丢包
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: packet-loss
spec:
  action: loss
  mode: all
  selector:
    namespaces: [prod-payment]
  loss:
    loss: "20"                 # 20% 丢包
    correlation: "80"
  duration: "2m"
---
# 网络分区（A 看不到 B）
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-partition
spec:
  action: partition
  mode: all
  selector:
    namespaces: [prod-api]
    labelSelectors:
      app: api-service
  direction: both
  target:
    selector:
      namespaces: [prod-payment]
      labelSelectors:
        app: payment-service
  duration: "1m"
```

### 3.3 StressChaos（资源压力）

```yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: cpu-memory-stress
spec:
  mode: one
  selector:
    namespaces: [prod-api]
    labelSelectors:
      app: api-service
  stressors:
    cpu:
      workers: 2
      load: 80                  # 80% CPU
    memory:
      workers: 1
      size: "512Mi"             # 占用 512MB 内存
  duration: "3m"
```

### 3.4 IOChaos（磁盘 IO 故障）

```yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: io-delay
spec:
  action: latency
  mode: all
  selector:
    namespaces: [prod-api]
    labelSelectors:
      app: api-service
  delay:
    latency: "50ms"
  path: /data                   # 注入到 /data 目录
  percent: 50                    # 50% 的 IO 操作
  duration: "2m"
```

### 3.5 DNSChaos（DNS 故障）

```yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: DNSChaos
metadata:
  name: dns-error
spec:
  action: error
  mode: all
  selector:
    namespaces: [prod-api]
    labelSelectors:
      app: api-service
  patterns:
    - "*.internal.company.com"   # 匹配内部域名
  duration: "1m"
```

### 3.6 TimeChaos（时钟漂移）

```yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: TimeChaos
metadata:
  name: clock-skew
spec:
  mode: all
  selector:
    namespaces: [prod-api]
    labelSelectors:
      app: api-service
  timeOffset: "-1h"             # 时间往回调 1 小时
  duration: "2m"
```

测证书过期、定时任务等场景特别有用。

---

## 四、Workflow：编排复杂实验

### 4.1 串行实验

```yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata:
  name: e2e-resilience-test
  namespace: chaos-mesh
spec:
  entry: e2e-test
  templates:
    - name: e2e-test
      templateType: Serial
      children:
        - kill-pod
        - wait
        - inject-network-delay
        - wait
        - stress-cpu
        - wait
    - name: kill-pod
      templateType: PodChaos
      duration: "30s"
      selector:
        namespaces: [prod-api]
        labelSelectors:
          app: api-service
      mode: one
      action: pod-kill
    - name: inject-network-delay
      templateType: NetworkChaos
      duration: "2m"
      selector:
        namespaces: [prod-api]
        labelSelectors:
          app: api-service
      mode: all
      action: delay
      delay:
        latency: "200ms"
        jitter: "50ms"
    - name: stress-cpu
      templateType: StressChaos
      duration: "1m"
      selector:
        namespaces: [prod-api]
        labelSelectors:
          app: api-service
      mode: one
      stressors:
        cpu:
          workers: 2
          load: 80
    - name: wait
      templateType: StatusCheck
      duration: "30s"
      conditions:
        - type: AwaitedConvergence
          timeout: "30s"
```

### 4.2 并行实验

```yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata:
  name: parallel-failures
spec:
  entry: parallel-test
  templates:
    - name: parallel-test
      templateType: Parallel
      children:
        - kill-app-pod
        - kill-db-pod
        - kill-cache-pod
    - name: kill-app-pod
      templateType: PodChaos
      duration: "5m"
      selector:
        namespaces: [prod-api]
        labelSelectors:
          app: api-service
      mode: one
      action: pod-kill
    - name: kill-db-pod
      templateType: PodChaos
      duration: "5m"
      selector:
        namespaces: [prod-db]
        labelSelectors:
          app: mysql
      mode: one
      action: pod-kill
    - name: kill-cache-pod
      templateType: PodChaos
      duration: "5m"
      selector:
        namespaces: [prod-cache]
        labelSelectors:
          app: redis
      mode: one
      action: pod-kill
```

模拟"应用+数据库+缓存同时挂"的最坏情况。

---

## 五、ChaosBlade：多平台故障注入

### 5.1 安装

```bash
# Linux
wget https://github.com/chaosblade-io/chaosblade/releases/download/v1.7.2/chaosblade-1.7.2-linux-amd64.tar.gz
tar -xvf chaosblade-1.7.2-linux-amd64.tar.gz
mv chaosblade-1.7.2 /opt/chaosblade
export PATH=$PATH:/opt/chaosblade

# 验证
blade version
```

### 5.2 容器场景

```bash
# 在指定容器内制造 CPU 满载
blade create k8s pod-cpu fullload --namespaces prod-api --names api-service-xxx --cpu-count 2

# 杀 Pod
blade create k8s pod-pod delete --namespaces prod-api --names api-service-xxx

# 内存占用
blade create k8s pod-memory load --namespaces prod-api --names api-service-xxx --mem-size 512

# 网络延迟
blade create k8s pod-network delay --time 500 --interface eth0 --namespaces prod-api --names api-service-xxx

# 删除实验
blade destroy <uid>
```

### 5.3 主机场景

```bash
# 进程被杀
blade create process kill --process tomcat --signal 9

# 进程 hang
blade create process stop --process mysql

# 磁盘 IO 高
blade create disk burn --read --write --size 100

# 磁盘满
blade create disk fill --path /tmp --size 10240    # 占用 10GB

# CPU 满
blade create cpu fullload --cpu-count 4

# 内存占用
blade create mem load --mem-size 4096

# 网络丢包
blade create network loss --interface eth0 --percent 30 --local-port 8080

# DNS 解析异常
blade create network dns --domain api.company.com --ip 127.0.0.1
```

### 5.4 JVM 场景

```bash
# FullGC
blade create jvm outofmemory --area HEAP --wildcards com.company.api.service

# 方法延迟
blade create jvm outofmemory --area NOHEAP

# 抛出指定异常
blade create jvm throwCustomException --exception java.lang.RuntimeException --wildcards com.company.api.service.PayService --methodName pay
```

JVM 场景对 Java 应用特别有用，可以模拟：

- 业务方法抛异常
- 业务方法慢调用
- JVM FullGC
- 内存泄漏

### 5.5 数据库场景

```bash
# MySQL 慢查询
blade create mysql delay --time 5000 --sqltype select --database prod --table orders

# MySQL 抛异常
blade create mysql throw --sqltype insert --database prod --table orders

# Redis 慢响应
blade create redis delay --time 3000 --addr redis://10.0.0.1:6379

# Redis 断连
blade create redis full --addr redis://10.0.0.1:6379
```

---

## 六、平台化：自建混沌工程门户

光有工具不够，还需要一个**统一的门户**来：

- 让团队**自助**申请实验
- 跟踪**实验历史**
- 与**告警**联动
- 自动**出报告**

### 6.1 架构图

```
┌──────────────────────────────────┐
│         Web Portal               │
│   (申请 / 审批 / 看板 / 报告)    │
└──────────────┬───────────────────┘
               │
               ▼
┌──────────────────────────────────┐
│      Chaos Controller            │
│  (实验编排 / 状态机 / 回调)      │
└──────┬─────────────┬─────────────┘
       │             │
       ▼             ▼
┌──────────┐  ┌──────────────┐
│Chaos Mesh│  │  ChaosBlade  │
│  (K8s)   │  │ (主机/JVM/DB)│
└──────────┘  └──────────────┘
       │             │
       └──────┬──────┘
              ▼
┌──────────────────────────────────┐
│      Observability Stack         │
│   (Prometheus / Grafana / 告警)  │
└──────────────────────────────────┘
```

### 6.2 最小可行的 Portal

我们用 Python Flask + 现有工具搭了个轻量门户，核心功能：

```python
# 实验申请 API
@app.post("/api/experiments")
def create_experiment(req: ExperimentRequest):
    # 1. 校验权限
    if not has_permission(req.user, req.namespace):
        raise HTTPException(403, "No permission")
    
    # 2. 校验爆炸半径
    if req.blast_radius > MAX_BLAST_RADIUS[req.environment]:
        raise HTTPException(400, "Blast radius too large")
    
    # 3. 检查是否在维护窗口
    if not in_maintenance_window(req.environment):
        raise HTTPException(400, "Not in maintenance window")
    
    # 4. 创建 Chaos Mesh 资源
    chaos_resource = build_chaos_mesh_resource(req)
    k8s_client.create(chaos_resource)
    
    # 5. 启动监控
    monitor.start(chaos_resource.uid, req)
    
    # 6. 通知 oncall
    notify_oncall(req)
    
    return {"experiment_id": chaos_resource.uid}
```

### 6.3 实验报告

每次实验自动出报告：

```markdown
# 实验报告 - 2026-08-13 03:00:00

## 实验信息
- **实验 ID**: exp-20260813-030000
- **实验类型**: PodChaos (kill)
- **目标服务**: prod-api/api-service
- **爆炸半径**: 1 Pod
- **持续时间**: 5 分钟
- **执行人**: zhang.san@company.com

## 假设
杀 1 个 Pod 后，Deployment 自动重启 Pod，业务在 10 秒内恢复。

## 实测
- Pod 重启时间: 6 秒 ✅
- 业务 P99 延迟: 涨到 800ms（持续 12 秒）⚠️
- 错误率: 峰值 0.5%（持续 8 秒）✅
- 告警: 未触发 ✅

## 结论
**部分符合假设**——Pod 重启时间达标，但延迟上涨超过预期。

## 改进建议
1. 调短 health check 间隔（从 10s 改 2s）
2. 加 preStop 钩子让流量先切换
3. 复制数从 3 增到 4（容忍 1 个 Pod 重启）

## 改进项跟踪
- [x] TASK-1234 健康检查间隔改 2s
- [ ] TASK-1235 加 preStop
- [ ] TASK-1236 复制数增到 4
```

---

## 七、与可观测性集成

### 7.1 自动对比实验前后指标

```python
def compare_steady_state(experiment_id, service):
    # 实验前 1 小时基线
    before = get_metrics(service, "1h_before_experiment")
    # 实验期间
    during = get_metrics(service, "during_experiment")
    # 实验后 30 分钟
    after = get_metrics(service, "30m_after_experiment")
    
    report = {
        "p99_latency": {
            "before": before.p99,
            "during_peak": during.p99_peak,
            "after": after.p99,
            "delta": during.p99_peak - before.p99,
            "passed": during.p99_peak < 1000  # 阈值
        },
        "error_rate": {
            "before": before.error_rate,
            "during_peak": during.error_rate_peak,
            "after": after.error_rate,
            "delta": during.error_rate_peak - before.error_rate,
            "passed": during.error_rate_peak < 0.01
        }
    }
    return report
```

### 7.2 集成告警

```yaml
# 实验期间临时调整告警阈值
# 通过 AlertManager Silences
- matchers:
    - alertname = "HighErrorRate"
    - service = "api-service"
  startsAt: "2026-08-13T03:00:00Z"
  endsAt: "2026-08-13T03:10:00Z"
  comment: "Chaos experiment in progress"
  createdBy: chaos-mesh
```

**注意**：实验期间告警阈值**不是关闭**，而是"放宽"。一旦超出范围，告警立即触发。

### 7.3 全链路追踪

```bash
# 注入故障时给所有相关 trace 打 tag
HEADER="X-Chaos-Experiment: exp-20260813-030000"
```

然后在 Jaeger/Tempo 里搜索这个 header 就能看到所有受影响的请求链路。

---

## 八、踩坑提示

### 8.1 不要在 dashboard 上暴露管理接口

Chaos Mesh 的 dashboard 默认**没有鉴权**，**必须**开启 security mode：

```bash
helm install chaos-mesh ... --set dashboard.securityMode=true
```

然后用 RBAC 控制谁能创建实验。

### 8.2 NetworkChaos 在某些 CNI 下不工作

Cilium、Calico 等 CNI 插件可能和 Chaos Mesh 的 iptables 注入冲突。

**验证**：

```bash
# 跑一个最简单的网络延迟实验，看是否生效
blade create k8s pod-network delay --time 1000 --interface eth0 ...
```

如果延迟没有注入，说明 CNI 拦截了。

**解决**：

- 某些 CNI 切到 host-local 模式
- 或者用 sidecar 模式注入

### 8.3 StressChaos 会和 VPA 冲突

VPA 会根据 CPU/内存使用率自动调整 Resources，Chaos Mesh 注入 CPU/内存压力会**触发 VPA 频繁重启 Pod**。

**解决**：

- 实验期间临时关 VPA
- 或在 VPA 排除名单里加 chaos-test 标签

### 8.4 跨 namespace 实验要小心

NetworkChaos 跨 namespace 实验可能影响**所有**流量，**要严格限制 selector**。

**反例**：

```yaml
selector:
  namespaces: ["*"]   # ❌ 所有 namespace
  labelSelectors:
    app: "anything"   # ❌ 太宽
```

**正例**：

```yaml
selector:
  namespaces: ["prod-api"]   # ✅ 限定 namespace
  labelSelectors:
    app: "api-service"       # ✅ 限定 label
```

### 8.5 实验清理

实验结束后**自动清理资源**：

```yaml
# 关键配置
spec:
  duration: "5m"   # 实验持续时间
  # duration 结束自动恢复
```

但要确认：

```bash
# 实验后检查没有残留
kubectl get podchaos,networkchaos,stresschaos -A
```

---

## 本篇要点回顾

1. **Chaos Mesh** 是 K8s 原生，覆盖 Pod/网络/IO/DNS/时间五大类故障
2. **ChaosBlade** 是多平台瑞士军刀，主机/容器/JVM/数据库都能搞
3. **Workflow** 编排复杂实验，串行 + 并行组合
4. 平台化需要**门户 + 权限 + 审批 + 监控 + 报告**
5. 实验期间告警**不是关闭**，是"放宽阈值"
6. CNI 冲突要验证，跨 namespace 实验要严控
7. **实验报告和改进行动跟踪是闭环核心**

---

## 下篇预告

下一篇讲 **49-故障注入设计：实验场景库与爆炸半径控制**。一个公司到底要做多少个混沌实验？实验怎么分类？爆炸半径怎么量化？实验库怎么维护？敬请期待。

本文是「架构实战·第二季」第 48 篇。上一篇讲了混沌工程的起源和原则，这一篇讲落地——用 ChaosBlade 和 Chaos Mesh 这两个 CNCF 主流工具，搭建一个能跑在生产环境的混沌工程平台。

【架构实战】ChaosBlade 与 Chaos Mesh：开源混沌工程工具落地

研发部经理

架构设计

运维

测试

本文深入解析生产级混沌工程平台搭建，基于CNCF主流工具ChaosMesh与ChaosBlade的选型对比与落地实践。核心覆盖K8s原生实验（Pod/网络/IO/DNS/时间）、多平台故障注入（主机/JVM/数据库）、Workflow复杂实验编排、平台化门户架构及可观测性集成。文章提供完整部署配置、RBAC权限控制、踩坑指南（CNI冲突、VPA兼容）及自动化实验报告模板，助力团队快速构建高可用韧性体系。

腾讯云双十一大促

tcmg

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

本文深入解析生产级混沌工程平台搭建，基于CNCF主流工具ChaosMesh与ChaosBlade的选型对比与落地实践。核心覆盖K8s原生实验（Pod/网络/IO/DNS/时间）、多平台故障注入（主机/JVM/数据库）、Workflow复杂实验编排、平台化门户架构及可观测性集成。文章提供完整部署配置、RBAC权限控制、踩...

【架构实战】ChaosBlade 与 Chaos Mesh：开源混沌工程工具落地-腾讯云开发者社区-腾讯云

【架构实战】ChaosBlade 与 Chaos Mesh：开源混沌工程工具落地

【架构实战】ChaosBlade 与 Chaos Mesh：开源混沌工程工具落地

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐