混沌测试

混沌测试基础

混沌测试是一种可试验的、基于系统的方法来处理大规模分布式系统中的混乱问题。通过不断试验，了解系统的实际能承受的韧性边界并建立信心，通过不同的试验方法和目的，观察分布式系统的行为和反应。

在复杂的分布式系统中，无法阻止这些故障的发生，应该致力于在这些异常行为被触发之前，尽可能多地识别风险。然后，针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。

混沌测试正是这样一套通过在生产分布式系统上进行实验，主动找出系统中的脆弱环节的方法学。

ChaosBlade 

ChaosBlade 是阿里巴巴开源的一款遵循混沌工程实验原理，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具，可实现底层故障的注入，特点是操作简洁、无侵入、扩展性强。

ChaosBlade 基于 Apache License v2.0 开源协议，目前有 chaosblade 和 chaosblade-exe-jvm 两个仓库。其中，Chaosblade 包含 CLI 和使用 Golang 实现的基础资源、容器相关的混沌实验实施执行模块。chaosblade-exe-jvm 是对运行在 JVM 上的应用实施混沌实验的执行器。

项目地址：https://github.com/chaosblade-io/chaosblade/wiki/%E6%96%B0%E6%89%8B%E6%8C%87%E5%8D%97

系统架构

Component Architecture

• Cli 包含 create、destroy、status、prepare、revoke、version 6 个命令
• 相关混沌实验数据使用 SQLite 存储在本地（chaosblade 目录下）
• Create 和 destroy 命令调用相关的混沌实验执行器创建或者销毁混沌实验
• Prepare 和 revoke 命令调用混沌实验准备执行器准备或者恢复实验环境，比如挂载 jvm-sandbox
• 混沌实验和混沌实验环境准备记录都可以通过 status 命令查询

场景覆盖

从其cli工具的help中，可以看出ChaosBlade目前支持的一些能力。

cpu         Cpu experiment
  disk        Disk experiment
  docker      Execute a docker experiment
  dubbo       dubbo experiment
  jvm         method
  k8s         Kubernetes experiment
  mysql       mysql experiment
  network     Network experiment
  process     Process experiment
  servlet     java servlet experiment      

此工具目前的实践场景如下：

1.自测阶段的故障植入，在不需要变更真实逻辑的情况下，验证自己的异常处理；

2.测试同学在测试阶段，模拟底层依赖服务的故障场景，验证系统可用程度，降级方案是否生效等；

3.业务故障演练时，在不需要变更真实逻辑的情况下，可以人为模拟特定场景的故障异常，验证止损方案是否可是有效的，可落地的；

在分布式架构环境下，服务间的依赖日益复杂，可能没有人能说清单个故障对整个系统的影响，构建一个高可用的分布式系统面临着很大挑战。在可控范围或环境下，使用 ChaosBlade 工具，对系统注入各种故障，持续提升分布式系统的容错和弹性能力，以构建高可用的分布式系统。

Chaos Mesh

Chaos Mesh 是PingCap团队研发的一款用于测试kubernetes环境的工具。通过人为地在集群中注入故障来检测集群对故障的处理以及恢复能力。混沌测试与针对某个应用测试的区别为：前者更倾向于在现有大规模集群中进行测试，影响因素可能来自集群中的方方面面；而后者更专注于对应用本身功能的测试。

Chaos Mesh 还支持许多其他的错误注入：

• pod-kill：模拟 Kubernetes Pod 被 kill。
• pod-failure：模拟 Kubernetes Pod 持续不可用，可以用来模拟节点宕机不可用场景。
• network-delay：模拟网络延迟。
• network-loss：模拟网络丢包。
• network-duplication: 模拟网络包重复。
• network-corrupt: 模拟网络包损坏。
• network-partition：模拟网络分区。
• I/O delay : 模拟文件系统 I/O 延迟。
• I/O errno：模拟文件系统 I/O 错误 。

Chaos Mesh 的目标是要做一个通用的混沌测试工具，所以需要遵循以下几个原则。

易用性：

• 无特殊依赖，可以在 Kubernetes 集群上面直接部署，包括 Minikube。
• 无需修改应用的部署逻辑，理想的情况是可以在生产环境上进行混沌实验 。
• 易于编排实验的错误注入行为，易于查看实验的状态和结果，并能够快速地对注入的故障进行回滚。
• 隐藏底层的实现细节，用户更聚焦于编排自己需要的实验。

拓展性：

• 基于现有实现，易于扩展新的故障注入种类。
• 方便集成到其他测试框架中。

作为一个通用的工具，易用性是必不可少的，一个工具不管功能如何多，如何强大，如果不够易用，那么这个工具最终也会失去用户，也就失去了工具的本身的价值。另一方面在保证易用的前提下，拓展性也是必不可少。如今的分布式系统越来越复杂，各种新的问题层出不穷，Chaos Mesh 的目标的是当有新的需求的时候，我们可以方便去在 Chaos Mesh 中实现，而不是重新再造个轮子。

总体来说，混沌测试更像是集成验证的一部分，通过在现有运行环境中注入故障来发现系统或应用的兼容性问题，故障恢复能力问题等。

原理解析

Chaos Mesh 的基本工作流原理是：

• Controller-manager
• 目前 controller-manager 可以分为两部分，一部分 controllers 用于调度和管理 CRD 对象实例，另一部分为 admission-webhooks 动态的给 Pod 注入 sidecar 容器。
• Chaos-daemon
• Chaos-daemon 以 daemonset 的方式运行，并具有 Privileged 权限，Chaos-daemon 可以操作具体 Node 节点上网络设备以及 Cgroup 等。
• Sidecar
• Sidecar contianer 是一类特殊的容器，由 admission-webhooks 动态的注入到目标 Pod 中，目前在 Chaos Mesh 中实现了 chaosfs sidecar 容器，chaosfs 容器内会运行 fuse-daemon，用来劫持应用容器的 I/O 操作。

整体工作流如下：

1. 用户通过 YAML 文件或是 Kubernetes 客户端往 Kubernetes API Server 创建或更新 Chaos 对象。
2. Chaos-mesh 通过 watch API Server 中的 Chaos 对象创建更新或删除事件，维护具体 Chaos 实验的运行以及生命周期，在这个过程中 controller-manager、chaos-daemon 以及 sidecar 容器协同工作，共同提供错误注入的能力。
3. Admission-webhooks 是用来接收准入请求的 HTTP 回调服务，当收到 Pod 创建请求，会动态修改待创建的 Pod 对象，例如注入 sidecar 容器到 Pod 中。第 3 步也可以发生在第 2 步之前，在应用创建的时候运行。