Chaos Mesh® 的 Chaos Engineering as a Service 探索之路

Chaos Mesh 已经开源一周年了，目前是 CNCF 的 sanbox 项目，在国内外发展良好，有了很多的 Contributor 和关注度。

但是目前 Chaos Mesh 仍然存在一些需要继续建设的方面：

1. 不够易用。很多 Chaos 功能较为复杂，用户在创建 Chaos 实验后，往往需要人工确认实验是否生效，缺乏 Metrics 以及与监控系统的联动。

2. 基本上只支持 K8s 环境。每个 K8s 集群都需要部署一个 Chaos Mesh，无法统一进行管理。支持物理机的 Chaosd 较为简陋，只是一个命令行工具，只支持少量的 Chaos 实验。

3. 无法插件化。目前添加自定义 Chaos 只能通过修改源码，暂不支持插件以及 Go 以外的语言。

4. 不支持编排。没有办法对 Chaos 实验进行编排与管理，也无法闭环做一些回调操作。

文章 The benefits of chaos engineering-as-a-service 是这么定义的：

CAAS（ChaosEngineering-As-a-Service）意味着可以快速的看到直观的图形化界面，开箱即用的集成一切需要进行实验的东西。

业界也有基于 CAAS 提供服务的厂商，比如 Germlin。

我的解读，Chaos Engineering as a Service 需要有一个统一的管理入口，可以便捷地通过界面操作，填写配置，创建 Chaos 实验；可以看到实验的状态和一些监控指标数据，对比任务周期的效果；可以做一些暂停、归档等操作管理实验；可以拖拽式编排 Chaos 实验。

基于 Chaos Engineering as a Service 的理念，我们对 Chaos Mesh 进行改造。Chaos Mesh 目前的架构比较适合单 K8s 集群使用，而且是只针对 K8s 环境设计的。架构图如下：

改造之后的 Chaos Mesh 架构如下：

Metrics 主要是解决三个问题：

1. 如何观测 Chaos 被成功注入

2. 如何观测 Chaos 注入以后对于服务的影响，并能做周期性的对比

3. 异常 Chaos 事件的相应

综上，可能需要从三个方面入手，实验数据 Metrics、正常指标监控、实验 Event。也就是说，目前还欠缺：

• 实验数据 Metrics，例如注入网络延迟的具体延迟时间、模拟负载的具体模拟值等等。

• 实验 Event，实验创建、删除、运行周期的 K8s Event。

完整的实验闭环，既需要有对 Chaos 的探索，又需要对实验结果做相应的处理，并反馈给混沌工程系统。

目前开源的 Chaos 工具，大多都只做了有限的探索，缺少后续的反馈。基于可观测性组件，可以实时感知 Chaos 实验的结果，基于实验结果数据做对比与分析。

反馈与闭环，另一个重要组件的就是实验的编排与管理。目前社区已经有了相关的 WorkFlow 提案，以及基于提案的相应实现。基于 WorkFlow，可以很轻松的实现对 Chaos 实验的编排、回调，也可以很方便的和其他系统进行联动。例如，可以在 CI/CD 阶段跑 Chaos；可以在执行灰度/金丝雀发布后跑 Chaos。

同时，最重要的是可以让 Chaos 实验实现闭环。比如对某个 Pod 进行网络延迟测试，延迟是 100ms。通过可观测性组件可以轻松观测到网络延迟的变化，同时基于编排可以使用 PromQL 或者其他 DSL 查询到这个 Pod 的服务是否可用。假设服务服务不可用，就会得到一个结论，当延迟大于等于 100ms 的时候，服务不可用。但这远远不够，因为 100ms 不是阈值，更需要一个相对准确的阈值来保证服务的 SLO，而恰好可以通过编排修改 Chaos 实验的实验值来反复实验。同时，也需要知道服务在不同网络延迟下的表现，以及是否能达到预期。

通过编排再来看混沌工程

混沌工程和和故障测试类似。故障测试通过对预先设想到的可以破坏系统的点进行测试，但是并没能去探究上述这类更广阔领域里的、不可预知的、但很可能发生的事情。在测试中，要进行断言：即给定一个特定的条件，系统会输出一个特定的结果。

故障测试一般来说只会产生二元的结果，验证一个结果是真还是假，从而判定测试是否通过。严格意义上来说，这个实践过程并不能发掘出系统未知的或尚不明确的认知，它仅仅是对已知的系统属性可能的取值进行测验。

CRD 其实很好的提供了一种对数据格式定义的方式。基于 chaos-mesh 的 CRD，转换成 JSON，即可实现在组件间通信。

Chaos Mesh 目前对插件支持比较有限，只能通过扩展 CRD 的形式，具体可见官方文档。

但这样就会有两个问题：

1. 开发者必须使用 Golang 来做扩展开发，对开发者还是有一定要求的，虽然 Golang 是高级 PHP(PHP 是世界上最好的语言)。

2. 扩展的代码需要合进项目，合进主代码又有可能引发额外的风险，毕竟没有 BPF 那种安全机制(是不是文章中包含 BPF 就能蹭一波热度)。

可能需要探索一种魔(ye)幻(lu)的(zi)插件方式。基于 Go 的插件，HashiCorp 出过一个 go-plugin，但还是基于 Go。回归本质， Chaos Mesh 其实是基于 CRD 进行 Chaos 实验。也就是说，只要能够生成、监听处理、删除 CRD 就可以完成混沌实验。基于 client-go？开发 Controller、Operator 操作 CRD？不，还有其他好(ye)办(lu)法(zi)。

可以统一处理 CRD 事件，然后通过 HTTP 回调的形式实现对 CRD 的操作，可以不使用 Golang，有 HTTP API 即可。思路略像上文数据格式中提及的部分。开源实现的相关参考 Whitebox Controller。

只是 HTTP Hook 可能还够，还有更好的野路子，比如 Wasm。需要调用 Chaos 实验逻辑的时候调用 Wasm 程序就好啦。业界也基于 Wasm 做插件的例子可以参考，比如 Vector 的 WASM Transform。BTW，TiDB Hackathon 2020 上的 TiDB UDF 就是用 Wasm 实现的。

通过命令行、API、面板查看 Chaos 实验的状态太繁琐？试试 SQL？再次回归本质， Chaos Mesh 是基于 CRD 的，那么只要能读取、操作 CRD 即可。使用 SQL 操作 K8s 的开源方案还是有一些的，比如 Presto 的 connector，osquery 的扩展等等。

业界也有一些基于 SDK 的扩展方式，比如 Chaos Toolkit。

与现有的 Chaos 工具结合会让整体的生态更强大，毕竟用户的 Chaos 场景可能很难穷尽。

例如，Litmus 的 K8s 实现是基于 PowerfulSeal 的，Litmus 的容器实现是基于 Pumba 的。

• 支持执行物理机执行自定义脚本。CRD 配置脚本路径，通过 Chaos Daemon 运行自定义 Shell 脚本，但需要特权模式运行容器，不是很友好。
• 基于自定义 Shell 脚本模拟 reboot、shutdown、Kernel Panic。
• 基于自定义 Shell 脚本将节点网卡 down 掉(随机 down 调节点，可能会造成物理机启动失败)。Shell 脚本内实现 ifdown、ifup 即可。
• 使用 sysbench 制造上下文频繁切换。模拟“吵闹的邻居”。
• 基于 BPF 的 seccomp 实现对容器的系统调用拦截。传递 PID，基于 PID 过滤即可。

• 随机修改 Deployment 的副本数量，测试应用的流量是否有异常。
• 基于 CRD 对象嵌套，在 Chaos CRD 中填写 Ingress 对象，模拟接口限速。
• 基于 CRD 对象嵌套，在 Chaos CRD 中填写 Cilium Network Policy 对象，模拟网络时好时坏。

业务层面：

• 支持自定义 Job。目前 Chaos Mesh 主要是基于 Chaos Daemon 实现注入，不具备调度的公平性以及亲和性，通过 Controller Manager 针对不同的 CRD 类型，直接创建 Job 即可实现。

• 自定义 Job 跑 Newman，随机修改 HTTP 参数。实现 HTTP 接口层面的 Chaos 实验，模拟用户异常行为。

• https://principlesofchaos.org/zh/

• https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116

• https://medium.com/better-practices/chaos-d3ef238ec328

• Learning Chaos Engineering: Discovering and Overcoming System Weaknesses through Experimentation（https://www.oreilly.com/library/view/learning-chaos-engineering/9781492050995/）

• Chaos Engineering: System Resiliency in Practice（https://www.oreilly.com/library/view/chaos-engineering/9781492043850/）

• Chaos Engineering Observability（https://www.oreilly.com/library/view/chaos-engineering-observability/9781492051046/）

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/