基于 Chaos Mesh 和 Argo 打造分布式测试平台

为什么需要 TiPocket?

为了确保用户的数据安全，我们需要确保给用户提供的每一个 TiDB 版本都已经经过了严格的测试，所以我们为 TiDB 设计了各种异常场景，并实现了数十个测试 Case，所以在我们的 Kubernetes 集群中，可能同时运行着十几个甚至几十个混沌实验，即使我们拥有了 Chaos Mesh 来帮助我们管理错误注入，但这还远不够，我们还需要去管理 TiDB 集群，需要去收集指标，需要去分析结果，同时进行如此多的混沌实验，另一方面，我们还需要对 TiDB 生态中的其他工具进行混沌测试，这是无法想象的，因此，我们开发了 TiPocket 来解放自己。

TiPocket 是一个基于 Kubernetes 和 Chaos Mesh 的完全自动化测试框架，目前我们主要使用它用来测试 TiDB 集群，不过由于它 All-in-K8s 的特性以及可扩展的接口，它目前也支持测试 TiDB 生态中的其他组件，只要简单的添加应用在 Kubernetes 中 Create/Delete 的逻辑，就可以很轻松的添加对各种应用的支持。

Chaos Mesh 提供故障模拟的能力

故障注入可以说是混沌测试中重要的一环，并且在分布式数据库领域，可能遇到的故障又非常的多，不仅仅是节点故障、各种网络故障、文件系统故障，更甚至可能遇到内核故障。如果 TiDB 不能正确的处理这些异常，那么后果是无法想象的，这也是最开始我们开发 Chaos Mesh 的主要原因之一。而 TiPocket 中很好的结合了 Chaos Mesh，将 Chaos Mesh 作为最基本的依赖之一，以达到混沌测试中故障注入的目的。 

目前我们已经在 TiPocket 提供了多种类型的故障注入： 

• Network：基于 Chaos Mesh 的 NetworkChaos，提供模拟的网络分区，或者链路随机的丢包、乱序、重复、时延等。

• Time Skew：基于 TimeChaos，模拟待测试容器发生时间偏移。TimeChaos 的实现也是非常有趣，感兴趣的话可以参考我们以前的 文章 。

• Kill：通过 PodChaos 来 kill 对应的 pod。细分下来我们也实现了多种 kill 类型，最简单的就是随机删除集群内的任意pod；如果针对各个组件，也有专门的 Chaos 随机 kill 一个或两个 TiKV 节点，或者是专门 kill PD 的 leader 节点。

• IO：基于 IOChaos，我们用的比较多的是给 TiKV 注入 IO Delay，再去看写入的情况。

解决了故障注入的问题，那么接下来我