Chaos Mesh 重构：向混沌工程即服务迈进一步

非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

混沌工程工具

Chaos Mesh 是一款面向 Kubernetes 环境的云原生混沌工程平台。通过向 Pod、网络、文件系统乃至内核注入各类故障，您可以在 Kubernetes 上全面检验系统的韧性与鲁棒性。

自开源并被云原生计算基金会（CNCF）纳入沙箱项目以来，Chaos Mesh 吸引了全球贡献者并帮助用户测试系统。但仍有诸多待改进之处：

• 易用性有待提升：部分功能操作复杂，例如发起混沌实验后常需手动确认实验是否启动

• 主要面向 Kubernetes 环境：由于无法管理多集群，每个 Kubernetes 集群均需独立部署 Chaos Mesh。虽然 chaosd 支持在物理机上运行混沌实验，但功能有限且命令行交互不够友好

• 缺乏插件机制：实施定制化混沌实验需修改源码，且当前仅支持 Golang 语言

诚然 Chaos Mesh 已是业界一流的混沌工程平台，但距离实现混沌工程即服务（CaaS）仍有差距。为此，在 TiDB Hackathon 2020 上，我们对架构进行了重构，向 CaaS 目标迈进重要一步。

本文将探讨 CaaS 的核心概念、实现路径、规划蓝图与实践经验，希望能为构建混沌工程体系提供参考。

什么是混沌工程即服务？

正如 Gremlin 联合创始人 Matt Fornaciari 所述，CaaS 意味着"您将获得直观的 UI、专业的技术支持、开箱即用的集成方案，以及能在几分钟内开启实验的全套能力"。

我们认为 CaaS 应具备以下核心能力：

• 统一管理控制台：支持配置编辑与混沌实验创建

• 可视化监控指标：实时呈现实验状态

• 实验管控操作：支持暂停/归档等操作

• 简洁的交互方式：通过拖拽即可编排实验对象

目前已有 网易伏羲实验室 和 FreeWheel 等企业根据自身需求改造 Chaos Mesh，初步实现了 CaaS 雏形。

面向 CaaS 的 Chaos Mesh 演进

基于对 CaaS 的理解，我们在 Hackathon 期间重构了 Chaos Mesh 架构，重点增强多系统支持与可观测性。您可通过 wuntun/chaos-mesh 和 wuntun/chaosd 查阅代码实现。

重构 Chaos Dashboard

当前架构主要适配单 Kubernetes 集群场景，其 Web UI（Chaos Dashboard）与特定 Kubernetes 环境强绑定：

Chaos Mesh 架构

在此次重构中，为了让 Chaos Dashboard 能够管理多个 Kubernetes 集群，我们将其从主架构中剥离出来。现在，如果您在 Kubernetes 集群外部部署 Chaos Dashboard，可通过 Web UI 添加集群；若在集群内部署，则会通过环境变量自动获取集群信息。

您可以在 Chaos Dashboard 中注册 Chaos Mesh（实质上是注册 Kubernetes 配置），或通过配置让 chaos-controller-manager 主动上报。Chaos Dashboard 与 chaos-controller-manager 通过 CustomResourceDefinitions（CRD）进行交互。当 chaos-controller-manager 监测到 Chaos Mesh CRD 事件时，会调用 chaos-daemon 执行对应的混沌实验。因此 Chaos Dashboard 可通过操作 CRD 来管理实验。

重构 chaosd

chaosd 是用于在物理机上运行混沌实验的工具包。此前它仅是命令行工具且功能有限。

chaosd——混沌工程命令行工具

重构过程中，我们为 chaosd 新增了 RESTful API 支持并强化其服务能力，使其能通过解析 CRD 格式的 JSON/YAML 文件来配置混沌实验。

现在 chaosd 可通过配置向 Chaos Dashboard 自主注册，并定期发送心跳信号。Chaos Dashboard 凭此管理 chaosd 节点状态，您也可通过 Web UI 手动添加 chaosd 节点。

此外，chaosd 现已支持按计划调度混沌实验并管理其生命周期，从而统一了 Kubernetes 环境与物理机环境的操作体验。

基于新版 Chaos Dashboard 和 chaosd，优化后的架构如下：

Chaos Mesh 优化架构

增强可观测性

另一项改进在于可观测性——如何判断实验是否成功执行。

此前需手动检查实验指标：例如向 Pod 注入 StressChaos 后，需进入 Pod 确认是否存在 stress-ng 进程，再用 top 命令检查 CPU/内存使用率，以此验证 StressChaos 实验是否创建成功。

现在我们将 node_exporter 集成至 chaos-daemon 和 chaosd 来采集节点指标，同时在 Kubernetes 集群部署 kube-state-metrics 并结合 cadvisor 采集集群指标。这些指标由 Prometheus 存储并通过 Grafana 可视化，为您提供便捷的实验状态检查方案。

待优化方向

指标系统的核心目标在于：

• 确认混沌注入已生效

• 观测混沌对服务的影响并定期分析

• 响应异常混沌事件

为此需监控三类数据：实验指标、常规指标及实验事件。Chaos Mesh 仍需加强：

• 实验数据指标：如注入网络延迟的具体时长、模拟负载的精确压力值

• 实验事件：包括创建/删除/运行实验时触发的 Kubernetes 事件

Litmus 的指标实现值得参考。

Chaos Mesh 的演进方向

受限于黑客松的时间限制，我们未能完成全部计划。以下是向 Chaos Mesh 社区提出的未来可考虑实施的建议方案。

编排能力

混沌工程的闭环包含四个关键步骤：混沌探索、系统缺陷发现、根因分析以及改进反馈。

混沌工程闭环示意图

然而当前大多数开源混沌工程工具仅聚焦于探索阶段，未能提供实质性反馈。基于增强的可观测性组件，我们可以实时监控混沌实验并对比分析实验结果。

依托这些结果，通过引入关键组件——编排能力，即可实现闭环反馈。Chaos Mesh 社区已提出工作流（Workflow）特性，支持轻松编排和回调混沌实验，或便捷集成至其他系统。您可在 CI/CD 阶段或金丝雀发布后执行混沌实验。

可观测性与编排能力的结合构建了混沌工程的闭环反馈机制。例如对 Pod 发起 100 毫秒网络延迟测试时，可通过可观测组件监控延迟变化，并基于编排能力使用 PromQL 或其他 DSL 验证 Pod 服务可用性。若服务不可用，即可得出结论：延迟 ≥100 毫秒时服务不可用。

但 100 毫秒并非服务的临界阈值；您需要明确服务可承受的最大延迟值。通过编排混沌实验参数值，即可确定满足服务等级目标（SLO）必须保障的阈值。同时还能获取不同网络条件下的服务性能表现，验证其是否符合预期。

数据格式

Chaos Mesh 使用 CRD 定义混沌对象。若能将 CRD 转换为 JSON 文件格式，即可实现跨组件通信。

在数据格式层面，chaosd 只需消费并注册 JSON 格式的 CRD 数据。任何能消费 CRD 数据并完成自注册的混沌工具，均可跨场景执行混沌实验。

插件体系

Chaos Mesh 的插件支持较为有限。目前仅能通过在 Kubernetes API 注册 CRD来添加新混沌类型，这导致两个问题：

• 必须使用与 Chaos Mesh 相同的 Golang 语言开发插件

• 扩展代码必须合并至 Chaos Mesh 项目。由于缺乏类似伯克利包过滤器（BPF）的安全机制，合并插件代码可能引入额外风险

为实现完备的插件支持，需探索新的插件集成方式。鉴于 Chaos Mesh 本质基于 CRD 执行混沌实验，实验过程仅需生成、监听和删除 CRD。对此我们提出几个值得尝试的方向：

• 开发控制器（Controller）或操作器（Operator）管理 CRD

• 统一处理 CRD 事件并通过 HTTP 回调操作 CRD。该方法仅依赖 HTTP API，无需 Golang 基础。示例参考：白盒控制器（Whitebox Controller）

• 采用 WebAssembly（Wasm）。需调用混沌实验逻辑时，直接执行 Wasm 程序

• 使用 SQL 查询混沌实验状态。基于 CRD 特性，可通过 SQL 操作 Kubernetes。参考方案：Presto 连接器与 osquery 扩展

• 采用 SDK 扩展方案，例如 Chaos Toolkit

与其他混沌工具的集成

在现实世界的系统中，单一混沌工程工具很难覆盖所有用例场景。因此与其他混沌工具集成能大幅增强混沌工程生态的能力。

市场上有大量混沌工程工具。Litmus 的 Kubernetes 实现基于 PowerfulSeal，其 容器实现则基于 Pumba。Kraken 专注于 Kubernetes，AWSSSMChaosRunner 聚焦 AWS，Toxiproxy 则针对 TCP 场景。此外还有基于 Envoy 和 Istio 的集成项目。

为管理多样化的混沌工具，可能需要统一模式（例如 Chaos Hub）。

社区实践分享

这里分享国内某领先网络安全公司（同时也是 Chaos Mesh 用户）如何改造 Chaos Mesh 满足需求。他们的实践涵盖三个层面：物理节点、容器和应用。

物理节点

• 支持在物理服务器执行脚本：通过 CRD 配置脚本目录，使用 chaos-daemon 运行脚本

• 通过自定义脚本模拟重启、关机和内核崩溃

• 使用自定义脚本关闭节点网卡（NIC）

• 利用 sysbench 制造频繁上下文切换，模拟"吵闹邻居"效应

• 通过 BPF 的 seccomp 拦截容器系统调用（基于 PID 传递和过滤实现）

容器

• 随机改变 Deployment 副本数，测试应用流量是否异常

• 基于 CRD 对象嵌入：在混沌 CRD 中填充 Ingress 对象模拟接口限速

• 基于 CRD 对象嵌入：在混沌 CRD 中填充 Cilium 网络策略对象模拟网络波动

应用

• 支持运行自定义任务：当前 Chaos Mesh 通过 chaos-daemon 注入混沌，无法保证调度公平性与亲和性。可通过 chaos-controller-manager 直接为不同 CRD 创建任务解决

• 在自定义任务中运行 Newman 随机修改 HTTP 参数，实现用户异常行为时的 HTTP 接口混沌实验

总结

传统故障测试针对系统预期脆弱点进行验证，本质是断言：特定条件产生特定结果。

混沌工程的强大之处在于帮助发现"未知的未知"。通过在更广阔领域探索，混沌工程能深化对被测系统的认知并挖掘新信息。

总而言之，以上是我们对混沌工程和 Chaos Mesh 的个人思考与实践总结。虽然我们的 Hackathon 项目尚未达到生产就绪状态，但希望能为 CaaS 的实现提供思路参考，并为 Chaos Mesh 勾勒出充满希望的演进路线。如果你对构建混沌工程即服务（CaaS）感兴趣，欢迎加入我们的 Slack (#project-chaos-mesh) 共同探索！