首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >从零落地 Chaos Mesh:构建高可用微服务的混沌工程平台(一)

从零落地 Chaos Mesh:构建高可用微服务的混沌工程平台(一)

作者头像
沈宥
发布2026-01-08 11:09:34
发布2026-01-08 11:09:34
1010
举报

一、为什么我们需要 Chaos Mesh?—— 来自生产事故的真实驱动

2024 年 Q3,我们线上支付网关因 Redis 集群主节点网络分区,导致写入超时,上游服务未做熔断,引发雪崩。事后复盘发现:

  • 单元测试覆盖了业务逻辑,但未覆盖基础设施异常
  • 压测只关注吞吐量,忽略故障注入下的链路行为
  • 监控告警依赖阈值,无法预判级联失败

我们意识到:系统在正常情况下跑得快 ≠ 系统在异常下不死

于是,混沌工程成为必选项。而 Chaos Mesh 凭借以下优势进入视野:

工具

是否开源

K8s 原生

故障类型覆盖

可编程性

社区活跃度

Chaos Monkey

有限(仅 kill pod)

LitmusChaos

中等

Chaos Mesh

全(网络/IO/CPU/时钟等)

强(CRD + API)

高(CNCF 毕业项目)

结论:Chaos Mesh 是当前最符合我们需求的混沌工程平台。


二、Chaos Mesh 核心能力拆解:不止是“制造故障”

很多人误以为 Chaos Mesh = “随机杀 Pod”。实际上,它的价值在于 可控、可观、可重复 的故障实验。我们重点关注以下能力:

1. 故障类型全覆盖(基于 CRD)

  • PodChaos:Pod Kill / Pod Failure
  • NetworkChaos:延迟 / 丢包 / 分区 / DNS 劫持
  • IOChaos:文件读写延迟、错误注入
  • StressChaos:CPU / Memory 压力
  • TimeChaos:系统时间篡改-用于测试定时任务
  • KernelChaos:内核级故障(高级用法)

关键点:所有故障通过 Kubernetes CRD 定义,天然支持 GitOps 和版本管理。

2. 精准作用域控制

  • 支持按 namespacelabel selectorannotation 精确指定目标 Pod
  • 支持 valueFrom 动态注入(如从 ConfigMap 读取目标列表)

3. 实验编排与调度

  • 支持一次性实验(One-off)和周期性实验(Schedule)
  • 支持多阶段实验(Workflow),例如:先注入网络延迟 → 观察 5 分钟 → 再注入 CPU 压力

4. 安全防护机制

  • **安全模式(Security Mode)**:默认启用,限制 Chaos Daemon 权限
  • RBAC 集成:通过 ServiceAccount 控制操作权限
  • 实验暂停/恢复:支持运行时干预

三、落地挑战:为什么不能直接 helm install 就完事?

很多团队卡在“装上了但用不起来”,原因如下:

问题

后果

我们的解决方案

缺乏实验设计方法论

实验随意,无法复现

建立“假设-注入-验证”标准流程

无平台化入口

开发需写 YAML,门槛高

自研 Web 平台(Python + Vue)

无结果自动验证

依赖人工看监控

集成 Prometheus + 自定义指标校验

权限混乱

生产环境误操作风险

RBAC + 审批流 + 环境隔离

**因此,我们的目标不是“部署 Chaos Mesh”,而是“构建一个安全、易用、可度量的混沌工程平台”**。


四、平台架构设计:以 Python + Vue 为核心的控制平面

我们采用分层架构:

代码语言:javascript
复制
+---------------------+
|     Vue 前端        | ← 用户操作界面(实验创建/执行/报告)
+----------+----------+
           |
+----------v----------+
|   FastAPI 后端      | ← 实验编排、权限控制、结果聚合
+----------+----------+
           |
+----------v----------+
|   Chaos Mesh API    | ← 通过 k8s client 操作 CRD
+----------+----------+
           |
+----------v----------+
|   Kubernetes 集群   | ← 运行 Chaos Daemon 和目标应用
+---------------------+

后端技术选型理由(Python)

  • 快速开发:FastAPI 自动生成 OpenAPI,便于前端对接
  • 生态丰富:kubernetes-client、prometheus-api、celery(异步任务)
  • 数据处理:pandas/numpy 用于实验结果分析

前端技术选型理由(Vue3 + TS)

  • 组件化:实验模板、拓扑图、结果面板可复用
  • 状态管理:Pinia 管理实验生命周期状态
  • 可视化:集成 ECharts 展示故障前后指标对比

五、第一步:部署 Chaos Mesh(生产就绪配置)

我们使用 Helm 3 部署,并关闭非必要功能以降低风险:

代码语言:javascript
复制
# 添加 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
代码语言:javascript
复制
helm install chaos-mesh chaos-mesh/chaos-mesh \
  --namespace=chaos-testing \
  --version v2.7.0 \
  -f values.yaml

🔒 安全建议

  1. 为 Chaos Mesh 创建独立 ServiceAccount,仅授予 chaos-mesh namespace 的权限
  2. 在生产集群中,禁止在 default 或核心业务 namespace 执行实验
  3. 所有实验 Pod 必须打上 chaos-experiment: "true" 标签,便于审计

六、第二步:构建实验模板引擎(Python 后端核心)

直接让用户写 YAML 不现实。我们抽象出 “实验模板” 概念。

示例:网络延迟实验模板

代码语言:javascript
复制
# 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 表达式

生成 CRD 的核心逻辑

代码语言:javascript
复制
# 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
        }
    }

提交到 K8s

代码语言:javascript
复制
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 异步任务)


七、第三步:前端实验创建界面(Vue3 实战)

我们使用 动态表单 + 拓扑图选择 降低使用门槛。

1. 拓扑图选择目标服务

  • 调用后端 /api/topology 获取当前 namespace 下的服务拓扑
  • 用户点击节点,自动填充 target_label
代码语言:javascript
复制
<template>
  <ServiceTopology @select="onServiceSelect" />
  <ChaosForm :target-label="selectedLabel" />
</template>

<script setup>
const selectedLabel = ref({})

function onServiceSelect(label) {
  selectedLabel.value = label
}
</script>

2. 实验参数表单(以网络延迟为例)

代码语言:javascript
复制
<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>

3. 提交与审批状态跟踪

  • 提交后进入“待审批”状态
  • SRE 在平台内一键批准/拒绝
  • 执行后实时显示 Chaos Mesh 实验状态(Running / Finished / Error)

八、阶段性成果:我们验证了什么?

在预发环境运行 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 时间源

最关键成果建立了“实验 → 问题 → 修复 → 回归”的闭环


九、下一步计划

  1. 自动化验证:实验后自动比对 Prometheus 指标(错误率、P99 延迟)
  2. 混沌演练剧本:将多个实验组合成“双 11 大促故障预案演练”
  3. 生产灰度实验:在 1% 流量上注入故障,验证金丝雀发布稳定性

结语

Chaos Mesh 不是玩具,而是系统韧性的压力测试仪。 落地的关键不在于工具本身,而在于如何将其融入研发流程。 下一期,我们将深入探讨:**《如何设计有效的混沌实验?—— 从“随机破坏”到“精准验证”》**。

附:资源清单

  • Chaos Mesh 官方文档:https://chaos-mesh.org
  • Prometheus 混沌指标看板 JSON
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-12-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 质量工程与测开技术栈 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、为什么我们需要 Chaos Mesh?—— 来自生产事故的真实驱动
    • 二、Chaos Mesh 核心能力拆解:不止是“制造故障”
      • 1. 故障类型全覆盖(基于 CRD)
      • 2. 精准作用域控制
      • 3. 实验编排与调度
      • 4. 安全防护机制
    • 三、落地挑战:为什么不能直接 helm install 就完事?
    • 四、平台架构设计:以 Python + Vue 为核心的控制平面
      • 后端技术选型理由(Python)
      • 前端技术选型理由(Vue3 + TS)
    • 五、第一步:部署 Chaos Mesh(生产就绪配置)
    • 六、第二步:构建实验模板引擎(Python 后端核心)
      • 示例:网络延迟实验模板
      • 生成 CRD 的核心逻辑
      • 提交到 K8s
    • 七、第三步:前端实验创建界面(Vue3 实战)
      • 1. 拓扑图选择目标服务
      • 2. 实验参数表单(以网络延迟为例)
      • 3. 提交与审批状态跟踪
    • 八、阶段性成果:我们验证了什么?
    • 九、下一步计划
    • 结语
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档