Go 开源说第八期：Chaos Mesh® 云原生混沌工程测试平台

1. 通过 kubectl 等命令行工具，将一个 YAML 文件提交至 Kubernetes 服务器这样做能够清晰地知道提交的内容，通过 kubectl 这一 Kubernetes 用户都能熟练使用的工具，将 Chaos Mesh 的资源操作方式和 Pod、Deployment 等其他原生资源的提交方式统一起来，方便用户上手、尝试。而除了使用kubectl apply 命令来提交一个混沌实验之外，还可以通过kubectl describe命令来查询实验的状态和错误信息，使用kubectl patch 来修改实验将实验暂停、恢复。（如图，一个典型的描述网络分区的NetworkChaos 资源文件）
   
   

   
   

2. 通过 kubernetes/client-go 等包来对 Chaos 资源进行增删查改。这样做的好处是能够方便地集成进已有的测试流程。如果用户已经搭建好一个 可编程地测试平台，那么就可以通过这种方式在任何自己期望的时机插入、恢复 混沌实验，如果说将 Chaos Mesh 提供的丰富的错误注入能力作为测试的武器 库，那么可编程的方式就是使用这些武器的最灵活的方式。
3. 通过 Chaos Dashboard 提供的 Web UI 界面对混沌试验进行操作和观测。Chaos Dashboard 提供了一套友好的用户界面，同时也提供了依照 RBAC 的权 限管控机制，用户需要输入自己的 Token 才能够进行操作。在这部分 UI 中用户 能够管理和观察已有的错误，同时也能将错误注入归档并在将来复用。

   
   

Chaos Mesh 的 Controller 总是只接受来自 Kubernetes API Server 的事件 —— 这种事件会描述“什么资源发生了什么变化”，比如一个名为network-test 的 NetworkChaos 资源被创建了。在工程实践中，对资源的具体变化进行响应太过复杂了；而往往选择使用“同步” 的方式 —— 将资源中描述的情形向真实状态中同步，比如当 Pod 建立时会将这种描述给具象化为一个（或多个）容器；反过来的 "同步" 也是存在的，当容器意外死亡、 启动失败的时候错误状态也会同步至 Pod 中。所以无论是怎样的变化（无论是增删查改 中的哪一个），Controller 要做的都只是决定以下两件事情：

1. 现在应该注入还是应该恢复还是要等待？
2. 如果需要注入/恢复，应该怎么做？

对于第一个问题，Controller 将必要的信息存储在资源中，比如下一次要注入的时间、 下一次要恢复的时间。这样在响应变化的时候，就能通过当前时间来推断应该注入还 是恢复还是等待。

而对于第二个问题，Controller 需要根据测试类型的不同进行不同的判断，比如删除 Pod 就能通过向 Kubernetes API Server 发送请求直接完成，对于公有云的混沌测试 ——比如起停虚拟机、移除磁盘则会通过每个公有云不同的 API 来完成，而其他稍稍复 杂的错误注入（比如后文会提到的 时间偏移 和 网络延迟 ）就需要 Chaos Daemon 的 帮助在每个节点上进行一些操作来注入。

要知道如何在云环境下注入，第一个问题就是弄清楚我们在注入什么 —— Pod 的实体 是 Container 的话那么 Container 的实体是什么呢？在常规的语境下，Container的一个实体指的是一个进程与它所属的 Namespace 和 Cgroup。其中 Namespace 与 Cgroup 起到了一个与其他进程隔离的作用。Namespace 控制着可见性，掌管着这个进 程能够看到哪些东西（看到哪些文件、看到哪些进程）；而 Cgroup 控制着资源分配：在一 个 cgroup 内允许占用多少 CPU 时间、占用多少内存、产生多少 Pid。而如果要进行错 误注入 —— 比如让一个容器内的 CPU 资源被吃满、让一个 Pod 与其他的 Pod 的网 络连接断开，需要做的第一件事情就是侵入到对应的 Namespace 及 Cgroup 中去。

侵入 Namespace

侵入 Cgroup 的实现是颇为简单的，在进程启动之后将它加入到对应 Cgroup 的进程 名单中即可。而 Namespace 的注入在 Go 的独特线程环境下要困难一些。Chaos Mesh 借鉴了 runc 的方案，自己实现了一个chaos-mesh/nsexec 来侵入 Namespace 。实现的原理是在进程启动的时候通过设置 LD_PRELOAD 环境变量来加载一个名为nsexec.so 的动态链接库，这个动态链接库的contructor 中调用 setns 系统调用来将自身 设置到目标名字空间中去。执行流程如图所示：

这一工具相比 nsenter 这个现成工具的好处主要有两点：

1. 拥有更适合 Chaos Mesh 的信号处理机制，能够方便地控制子进程的死亡。
2. 能够和 mnt namespace 配合工作，只要是当前 mnt namespace 存在的二进制文件，都能够在目标名字空间中运行，而不需要目标名字空间中存在。在常见的distroless 的镜像中，可能不存在任何常见的二进制文件，而nsexec 能够应对这种情况。

具体注入实现的方法

现在 Chaos Mesh 已经拥有了非常丰富的功能，受限于篇幅不可能单独介绍每一种注 入的实现，更重要的可能是注入实现背后的方法和路径。在设计一个错误注入的实现时 ，依照以下的流程进行考虑被证实是非常有用的：

1. 考虑正常情况下程序工作的方式
2. 在正常的调用途径中有哪些可注入的地方
3. 对这些可注入的地方进行注入

以下我们以时间偏移为例，照着这种思考范式来设计它的实现：

1. 考虑正常情况下程序工作的方式

正常情况下，一个程序是如何获得时间的呢？大部分程序会选择使用编程语言 标准库中携带的函数，比如 Rust 程序会使用Instant::now()， Go 程序会使用time.Now() ，C 生态的程序会使用glibc 中的 clock_gettime 函数。而这些函数都会以 vDSO 的方式调用操作系统提供的 clock_gettime。vDSO 也是由操作系统提供的函数功能。但与系统调用不同，vDSO 由操作系统 在进程启动的时候自动地加载入进程的内存空间，格式与动态链接库的 ELF 格 式相同。应用程序只需要解析这段 ELF 的一些段，就能找到clock_gettime 函数 并调用它。

2. 在正常的调用途径中有哪些可注入的地方？因为 vDSO 是存在于目标进程的内存空间中的，如果我们能够修改这部分内存 空间就好了。而事实上ptrace 系统调用给了我们修改另一进程的内存的能力。

3. 对这些可注入的地方进行注入 于是时间偏移的实现方式呼之欲出——只需要准备好一个有偏移的clock_gettime 的实现，用它覆盖住原有的clock_gettime 函数的实现就好了。

使用类似的方法，也同样能够破解其他类型注入的难题——比如对于文件系统的注入 方式，我们可以通过 FUSE 提供一个存在延迟的文件系统，而这一文件系统以真实的磁 盘上的文件系统为存储后端即可（这样用户在恢复之后仍然能操作这些文件）。

以上为这篇文章介绍的全部内容了。如果读者对 Chaos Mesh 项目感兴趣，想要成为用户或 贡献者，欢迎加入我们的 Slack Channel (CNCF Slack 的 #project-chaos-mesh 频道) 来一同 讨论如何应用混沌工程、如何让 Chaos Mesh 变得更好。构造一个稳定安全的软件服务使用 环境，离不开社区的帮助。无论是使用 Chaos Mesh 还是为 Chaos Mesh 提交代码，相信都是 在迈向这一美好的目标。