基于 Chaos Mesh 和 Argo 构建自动化测试框架
本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →
Chaos Mesh 是面向 Kubernetes 的开源混沌工程平台。尽管它提供了丰富的异常状态模拟能力，但这仅解决了混沌工程难题的一小部分。完整的混沌工程实践不仅包含故障注入，还需要围绕稳态建立假设、在生产环境运行实验、通过测试用例验证系统以及实现测试自动化。
本文将介绍我们如何使用自动化测试框架 TiPocket 为分布式数据库 TiDB 构建完整的混沌工程测试闭环。
为什么需要 TiPocket？
在将 TiDB 这类分布式系统投入生产环境前，必须确保其具备足够的日常运行健壮性。为此，数年前我们将混沌工程引入测试框架，具体流程如下：
-
观察系统正常指标并建立测试假设
-
向 TiDB 注入预设故障清单
-
运行多样化测试用例验证故障场景下的系统表现
-
监控并收集测试结果用于分析诊断
这套流程看似完善且已运行多年，但随着 TiDB 演进，测试规模呈指数级增长。我们需在 Kubernetes 测试集群中针对多种故障场景运行数十个测试用例。即便有 Chaos Mesh 协助故障注入，剩余工作仍相当繁重，更遑论实现可扩展的高效测试流水线自动化。
因此我们开发了 TiPocket——基于 Kubernetes 和 Chaos Mesh 的全自动测试框架。目前主要应用于 TiDB 集群测试，得益于其 Kubernetes 友好设计和可扩展接口，您可通过 Kubernetes 的创建/删除逻辑轻松支持其他应用。
实现原理
基于上述需求，我们需要建立自动化工作流实现：
注入混沌故障 - Chaos Mesh
故障注入是混沌测试的核心。分布式数据库中故障可能随时发生在任何环节——节点崩溃、网络分区、文件系统故障乃至内核恐慌。这正是 Chaos Mesh 的用武之地。
TiPocket 当前支持的故障注入类型包括：
-
网络故障：模拟网络分区、随机丢包、链路乱序/重复/延迟
-
时间偏移：模拟被测容器时钟偏差
-
进程终止：在集群内随机或指定组件（TiDB/TiKV/Placement Driver）中终止特定 Pod
-
I/O 故障：在 TiDB 存储引擎 TiKV 中注入 I/O 延迟以识别相关问题
完成故障注入后，我们需要思考验证环节：如何确保 TiDB 能在这些故障中保持可用？
验证混沌影响：测试用例
为了验证 TiDB 在混沌攻击下的表现，我们在 TiPocket 中实现了数十个测试用例，并整合了多种检查工具。以下典型用例将展示 TiPocket 如何在故障场景中验证 TiDB，这些用例聚焦于 SQL 执行、事务一致性与事务隔离性三大核心领域。
模糊测试：SQLsmith
SQLsmith 是一款生成随机 SQL 查询的工具。TiPocket 会创建 TiDB 集群和 MySQL 实例，将 SQLsmith 生成的随机 SQL 同时在两者上执行。在向 TiDB 集群注入各类故障的同时进行测试，最终对比执行结果。若检测到结果不一致，则表明系统存在潜在问题。
事务一致性测试：Bank 与 Porcupine
Bank 是模拟银行系统转账流程的经典测试用例。在快照隔离级别下，所有转账操作必须确保账户总额在任何时刻保持恒定——即使在系统故障期间。若检测到总额不一致，则表明系统存在潜在问题。
Porcupine 是 Go 语言实现的线性一致性检查器，用于验证分布式系统的正确性。该工具接收可执行的 Go 语言顺序规范与并发历史记录，判断历史记录是否满足顺序规范的线性一致性要求。TiPocket 在多个测试用例中采用 Porcupine 检查器验证 TiDB 是否符合线性一致性约束。
事务隔离性测试：Elle
Elle 是验证数据库事务隔离级别的检查工具。TiPocket 集成了 go-elle——Elle 检查器的 Go 语言实现——用于验证 TiDB 的隔离级别。
以上仅是 TiPocket 验证 TiDB 准确性与稳定性的部分测试用例。更多测试用例及验证方法请参见我们的源代码。
自动化混沌流水线 - Argo
现在，我们已具备故障注入工具 Chaos Mesh、待测的 TiDB 集群及验证方法，如何实现混沌测试流水线的自动化？我们面临两个选择：在 TiPocket 中实现调度功能，或借助现有开源工具。为了让 TiPocket 更专注于测试验证环节，我们选择了开源工具方案。结合全 Kubernetes 化的设计理念，我们最终采用了 Argo。
Argo 是专为 Kubernetes 设计的工作流引擎，作为开源项目已长期发展并得到广泛应用。
Argo 抽象了若干工作流相关的自定义资源定义（CRD），其中最关键的是工作流模板（Workflow Template）、工作流（Workflow）和定时工作流（Cron Workflow）。以下是它们在 TiPocket 中的协作方式：
-
工作流模板：为每个测试任务预定义的模板，测试运行时支持参数注入。
-
工作流：按特定顺序调度多个工作流模板，组合成待执行任务。Argo 支持在流水线中添加条件判断、循环逻辑及有向无环图（DAG）等复杂控制流。
-
定时工作流：支持以 cron 任务形式调度工作流，完美适配需要长期运行的测试任务场景。
下图展示我们预定义的银行测试（bank test）工作流示例：
spec:
entrypoint: call-tipocket-bank
arguments:
parameters:
- name: ns
value: tipocket-bank
- name: nemesis
value: random_kill,kill_pd_leader_5min,partition_one,subcritical_skews,big_skews,shuffle-leader-scheduler,shuffle-region-scheduler,random-merge-scheduler
templates:
- name: call-tipocket-bank
steps:
- - name: call-wait-cluster
templateRef:
name: wait-cluster
template: wait-cluster
- - name: call-tipocket-bank
templateRef:
name: tipocket-bank
template: tipocket-bank
在此示例中，我们使用工作流模板和故障参数（nemesis parameters）来定义要注入的具体故障。您可以复用该模板创建适应不同测试用例的多个工作流，从而在流程中添加更多自定义的故障注入。
除了 TiPocket 提供的工作流示例和模板外，该设计还支持添加自定义故障注入流程。通过可编程的工作流处理复杂逻辑，使 Argo 成为开发者友好的工具，完美契合我们的应用场景。
混沌实验现已自动运行，但如果结果未达预期该如何定位问题？TiDB 保存了丰富的监控信息，这使得日志收集成为实现 TiPocket 可观测性的关键环节。
可视化结果：Loki
在云原生系统中，可观测性至关重要。通常可通过指标（metrics）、**日志（logging）和追踪（tracing）**实现可观测性。TiPocket 主要测试 TiDB 集群，因此指标和日志成为我们定位问题的默认数据源。
Kubernetes 环境中，Prometheus 是指标监控的事实标准，但日志收集尚无统一方案。Elasticsearch、Fluent Bit 和 Kibana 等方案表现优异，但可能引发系统资源争用且维护成本高昂。我们最终选用 Grafana 推出的类 Prometheus 日志聚合系统 Loki。
Prometheus 负责处理 TiDB 监控信息。由于 Prometheus 与 Loki 采用相似的标签体系，我们可轻松关联监控指标与对应 Pod 日志，并使用相近的查询语言。Grafana 原生支持 Loki 仪表盘，这意味着我们能同时展示监控指标和日志——而 Grafana 作为 TiDB 内置监控组件，Loki 可直接复用其能力。
整体架构：TiPocket
至此所有组件准备就绪，以下是 TiPocket 的简化架构图：
如图所示，Argo 工作流统一管理所有混沌实验和测试用例。完整测试周期通常包含以下步骤：
- Argo 创建定时工作流（Cron Workflow），定义待测集群、故障注入方案、测试用例及任务时长。该工作流还支持实时查看用例日志。
-
定时触发工作流后，独立 TiPocket 线程启动并向 TiDB-Operator 发送待测集群定义，由 Operator 创建目标 TiDB 集群，同时 Loki 开始采集相关日志。
-
Chaos Mesh 向集群注入故障。
-
用户通过预设测试用例验证系统健康状态。任何用例失败都将触发 Argo 工作流失败，进而通过 Alertmanager 将结果推送至指定 Slack 频道；若测试正常完成，则清理集群并等待下次测试。
这就是完整的 TiPocket 工作流。
加入我们
Chaos Mesh 和 TiPocket 目前均处于积极迭代阶段。我们已将 Chaos Mesh 捐赠给 CNCF，期待更多社区成员加入我们，共同构建完整的混沌工程生态。如果您对此感兴趣，欢迎访问我们的官网，或加入 CNCF Slack 的 #project-chaos-mesh 频道。