
2024 年 Q3,我们线上支付网关因 Redis 集群主节点网络分区,导致写入超时,上游服务未做熔断,引发雪崩。事后复盘发现:
我们意识到:系统在正常情况下跑得快 ≠ 系统在异常下不死。
于是,混沌工程成为必选项。而 Chaos Mesh 凭借以下优势进入视野:
工具 | 是否开源 | K8s 原生 | 故障类型覆盖 | 可编程性 | 社区活跃度 |
|---|---|---|---|---|---|
Chaos Monkey | 是 | 否 | 有限(仅 kill pod) | 弱 | 低 |
LitmusChaos | 是 | 是 | 中等 | 中 | 中 |
Chaos Mesh | 是 | 是 | 全(网络/IO/CPU/时钟等) | 强(CRD + API) | 高(CNCF 毕业项目) |
结论:Chaos Mesh 是当前最符合我们需求的混沌工程平台。
很多人误以为 Chaos Mesh = “随机杀 Pod”。实际上,它的价值在于 可控、可观、可重复 的故障实验。我们重点关注以下能力:
✅ 关键点:所有故障通过 Kubernetes CRD 定义,天然支持 GitOps 和版本管理。
namespace、label selector、annotation 精确指定目标 PodvalueFrom 动态注入(如从 ConfigMap 读取目标列表)helm install 就完事?很多团队卡在“装上了但用不起来”,原因如下:
问题 | 后果 | 我们的解决方案 |
|---|---|---|
缺乏实验设计方法论 | 实验随意,无法复现 | 建立“假设-注入-验证”标准流程 |
无平台化入口 | 开发需写 YAML,门槛高 | 自研 Web 平台(Python + Vue) |
无结果自动验证 | 依赖人工看监控 | 集成 Prometheus + 自定义指标校验 |
权限混乱 | 生产环境误操作风险 | RBAC + 审批流 + 环境隔离 |
**因此,我们的目标不是“部署 Chaos Mesh”,而是“构建一个安全、易用、可度量的混沌工程平台”**。
我们采用分层架构:
+---------------------+
| Vue 前端 | ← 用户操作界面(实验创建/执行/报告)
+----------+----------+
|
+----------v----------+
| FastAPI 后端 | ← 实验编排、权限控制、结果聚合
+----------+----------+
|
+----------v----------+
| Chaos Mesh API | ← 通过 k8s client 操作 CRD
+----------+----------+
|
+----------v----------+
| Kubernetes 集群 | ← 运行 Chaos Daemon 和目标应用
+---------------------+
我们使用 Helm 3 部署,并关闭非必要功能以降低风险:
# 添加 repo
helm repo add chaos-mesh https://charts.chaos-mesh.org
# 创建 namespace
kubectl create ns chaos-testing
# 关键配置 values.yaml
---
chaosDaemon:
# 启用安全模式(必须!)
securityMode: true
# 限制 Chaos Daemon 只在特定节点运行(打污点)
nodeSelector:
chaos-ready: "true"
controllerManager:
# 禁用 Dashboard(我们自研前端)
enableDashboard: false
# 启用所需 Chaos 类型
enabledChaosList:
- pod
- network
- stress
- time
helm install chaos-mesh chaos-mesh/chaos-mesh \
--namespace=chaos-testing \
--version v2.7.0 \
-f values.yaml
🔒 安全建议:
chaos-mesh namespace 的权限chaos-experiment: "true" 标签,便于审计直接让用户写 YAML 不现实。我们抽象出 “实验模板” 概念。
# models/experiment.py
class NetworkDelayExperiment(BaseModel):
name: str
namespace: str
target_label: Dict[str, str] # 如 {"app": "order-service"}
delay_ms: int = 200
duration: str = "5m" # 支持 5m, 1h 等
scheduler: Optional[str] = None # cron 表达式
# services/chaos_mesh.py
def build_network_chaos_cr(experiment: NetworkDelayExperiment) -> dict:
return {
"apiVersion": "chaos-mesh.org/v1alpha1",
"kind": "NetworkChaos",
"metadata": {
"name": experiment.name,
"namespace": "chaos-testing"
},
"spec": {
"action": "delay",
"mode": "all", # 或 one / fixed
"selector": {
"namespaces": [experiment.namespace],
"labelSelectors": experiment.target_label
},
"delay": {
"latency": f"{experiment.delay_ms}ms",
"correlation": "0",
"jitter": "0ms"
},
"duration": experiment.duration,
"scheduler": {"cron": experiment.scheduler} if experiment.scheduler else None
}
}
from kubernetes import client
def apply_chaos_experiment(cr: dict):
api = client.CustomObjectsApi()
api.create_namespaced_custom_object(
group="chaos-mesh.org",
version="v1alpha1",
namespace="chaos-testing",
plural=f"{cr['kind'].lower()}s",
body=cr
)
💡 关键设计:所有实验操作走审批流。用户提交 → SRE 审核 → 自动执行(通过 Celery 异步任务)
我们使用 动态表单 + 拓扑图选择 降低使用门槛。
/api/topology 获取当前 namespace 下的服务拓扑target_label<template>
<ServiceTopology @select="onServiceSelect" />
<ChaosForm :target-label="selectedLabel" />
</template>
<script setup>
const selectedLabel = ref({})
function onServiceSelect(label) {
selectedLabel.value = label
}
</script>
<el-form :model="form">
<el-form-item label="延迟时间 (ms)">
<el-input-number v-model="form.delay_ms" :min="10" :max="5000" />
</el-form-item>
<el-form-item label="持续时间">
<el-select v-model="form.duration">
<el-option value="1m" />
<el-option value="5m" />
<el-option value="10m" />
</el-select>
</el-form-item>
</el-form>
在预发环境运行 2 周后,我们完成了以下验证:
实验类型 | 目标服务 | 发现问题 | 改进项 |
|---|---|---|---|
Pod Kill | user-service | 无健康检查,重启后流量立即打入 | 增加 readinessProbe |
网络延迟 (500ms) | order-service | Hystrix 超时设置过长(10s) | 降级为 2s + fallback |
CPU Stress (80%) | payment-gateway | 日志采集占用过高 CPU | 限制 Filebeat CPU limit |
Time Chaos (+1h) | coupon-service | 优惠券过期逻辑依赖本地时间 | 改为 NTP 时间源 |
最关键成果:建立了“实验 → 问题 → 修复 → 回归”的闭环。
Chaos Mesh 不是玩具,而是系统韧性的压力测试仪。 落地的关键不在于工具本身,而在于如何将其融入研发流程。 下一期,我们将深入探讨:**《如何设计有效的混沌实验?—— 从“随机破坏”到“精准验证”》**。
附:资源清单