Chaos Mesh - 您的 Kubernetes 系统韧性混沌工程解决方案

2020年1月15日 · 1 分钟阅读

Maintainer of Chaos Mesh

非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。发现错误？报告问题 →

为什么选择 Chaos Mesh？

在分布式计算领域，集群故障可能随时随地不可预测地发生。虽然单元测试和集成测试能确保系统达到生产就绪状态，但随着集群规模扩大、复杂度提升以及数据量达到 PB 级别，这些测试仅覆盖了冰山一角。为了更好地识别系统漏洞并提升韧性，Netflix 创造了 Chaos Monkey，通过向基础设施和业务系统注入各类故障，混沌工程由此诞生。

在 PingCAP 构建开源分布式 NewSQL 数据库 TiDB 时，我们同样面临这一问题。容错性和系统韧性对我们尤为关键——数据库用户最重要的资产就是数据本身。为确保韧性，我们很早就开始在测试框架中实践混沌工程。但随着 TiDB 的发展，测试需求也在增长。我们意识到需要一个通用的混沌测试平台，不仅服务于 TiDB，也适用于其他分布式系统。

因此我们推出 Chaos Mesh，这是一个专为 Kubernetes 环境编排混沌实验的云原生混沌工程平台。您可通过 https://github.com/chaos-mesh/chaos-mesh 获取这个开源项目。

接下来我将为您介绍 Chaos Mesh 的设计实现原理，并演示如何在实际环境中使用它。

Chaos Mesh 能做什么？

Chaos Mesh 是功能全面的混沌工程平台，提供针对 Kubernetes 复杂系统的全方位故障注入能力，覆盖 Pod、网络、文件系统乃至内核层级的故障。

以下是我们使用 Chaos Mesh 定位 TiDB 系统 bug 的实例。本例中，我们通过分布式存储引擎 (TiKV) 模拟 Pod 宕机，并观察每秒查询量 (QPS) 的变化。正常情况下，当单个 TiKV 节点宕机时，QPS 会短暂波动后恢复至故障前水平——这正是我们保障高可用的机制。

从仪表盘可见：

前两次宕机后，QPS 约 1 分钟恢复正常
但第三次宕机后，QPS 恢复耗时显著延长至约 9 分钟。这种异常宕机时长必然影响线上服务

经诊断，被测 TiDB 集群版本 (V3.0.1) 在处理 TiKV 宕机时存在隐蔽问题，我们已在后续版本中修复。

Chaos Mesh 的功能远不止模拟宕机，还包括以下故障注入方法：

pod-kill: 模拟 Kubernetes Pod 被终止
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 原生优先。

简单易用

为实现简单易用的目标，Chaos Mesh 具备以下特性：

无需特殊依赖，可直接部署在任何 Kubernetes 集群（包括 Minikube）
无需修改被测系统的部署逻辑，可直接在生产环境执行混沌实验
直观编排故障注入行为，实时查看实验状态与结果，并能快速回滚故障
隐藏底层实现细节，让用户专注于实验编排本身

高度可扩展

Chaos Mesh 通过模块化设计实现高度可扩展性：

复用现有实现，轻松扩展新的故障注入方法
开放接口设计，便于与其他测试框架集成

Kubernetes 原生优先

在云原生领域，Kubernetes 已成为容器编排的事实标准。其采用率的增长远超预期，本质上已成为云时代的操作系统。

TiDB 作为云原生分布式数据库，其自动化测试平台自始就构建于 Kubernetes 之上。我们每天在 Kubernetes 上运行数百个 TiDB 集群，执行各类混沌实验以模拟生产环境故障。因此，将混沌工程与 Kubernetes 深度集成成为我们实现的核心原则。

CustomResourceDefinitions 设计

Chaos Mesh 采用 CustomResourceDefinitions (CRD) 定义混沌对象。CRD 是 Kubernetes 生态中成熟的定制资源方案，拥有丰富的实践案例和工具链支持，使 Chaos Mesh 能天然融入 Kubernetes 生态系统。

我们采用灵活的分治策略：不同故障类型拥有独立的 CRD 对象。新增故障注入方法时，若符合现有 CRD 规范则直接扩展；若是全新类型则创建专属 CRD。这种设计将混沌对象的定义与实现逻辑解耦，使代码结构更清晰，同时降低了耦合度与错误发生概率。此外，Kubernetes 的 controller-runtime 是一个优秀的控制器实现封装工具，它避免了为每个 CRD 项目重复实现相同的控制器逻辑，从而节省大量时间。

Chaos Mesh 已实现 PodChaos、NetworkChaos 和 IOChaos 三类对象，其命名清晰对应具体的故障注入类型。

以 Kubernetes 环境常见的 Pod 崩溃为例：原生资源对象通常会自动创建新 Pod 处理此类故障。但我们的应用是否能真正应对？若 Pod 无法启动又会怎样？

通过定义明确的 pod-kill 等操作，PodChaos 能精准定位此类问题。其对象定义如下：

spec:
 action: pod-kill
 mode: one
 selector:
   namespaces:
     - tidb-cluster-demo
   labelSelectors:
     "app.kubernetes.io/component": "tikv"
  scheduler:
   cron: "@every 2m"

这段代码实现的功能包括：

action 属性定义具体注入的故障类型（如 pod-kill 表示随机终止 Pod）
selector 属性用于限定混沌实验的作用范围。本示例中，实验范围限定在命名空间 tidb-cluster-demo 下的 TiDB 集群 TiKV Pod。
scheduler 属性定义了每次混沌故障操作的触发间隔。

有关 NetworkChaos 和 IOChaos 等 CRD 对象的详细说明，请参阅 Chaos-mesh 文档。

Chaos Mesh 的实现原理

确定 CRD 设计框架后，我们来宏观解析 Chaos Mesh 的运作机制。系统主要包含以下核心组件：

controller-manager

作为平台的"大脑"，负责管理 CRD 对象的生命周期并调度混沌实验。其对象控制器用于调度 CRD 实例，admission-webhooks 控制器则动态注入 sidecar 容器至目标 Pod。
chaos-daemon

以特权 DaemonSet 形式运行，可操作节点的网络设备及 Cgroup。
sidecar

作为特殊容器类型，由 admission-webhooks 动态注入目标 Pod。例如 chaosfs sidecar 容器通过运行 fuse-daemon 来劫持应用容器的 I/O 操作。

各组件协同执行混沌实验的流程如下：

用户通过 YAML 文件或 Kubernetes 客户端创建/更新混沌对象至 Kubernetes API Server。
Chaos Mesh 监听 API Server 中的混沌对象，通过创建/更新/删除事件管理实验生命周期。该过程中 controller-manager、chaos-daemon 和 sidecar 容器协同实施故障注入。
当 admission-webhooks 接收到 Pod 创建请求时，动态修改待创建 Pod 对象（如注入 sidecar 容器）。

运行混沌实验

前文介绍了 Chaos Mesh 的设计理念与运作机制，现在让我们进入实践环节。请注意：混沌测试时长取决于被测应用的复杂度及 CRD 中定义的调度规则。

环境准备

Chaos Mesh 需运行在 Kubernetes v1.12 及以上版本。建议通过 Kubernetes 包管理工具 Helm 进行部署与管理。运行前请确保 Helm 已在集群中正确安装。环境准备步骤如下：

确认已存在 Kubernetes 集群。若已满足请跳至步骤 2；否则可通过 Chaos Mesh 提供的脚本在本地创建集群：

// install kind
curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.6.1/kind-$(uname)-amd64
chmod +x ./kind
mv ./kind /some-dir-in-your-PATH/kind

// get script
git clone https://github.com/chaos-mesh/chaos-mesh
cd chaos-mesh
// start cluster
hack/kind-cluster-build.sh

注意： 本地启动 Kubernetes 集群可能影响网络类故障注入效果。

若 Kubernetes 集群已就绪，请使用 Helm 和 Kubectl 部署 Chaos Mesh：
```
git clone https://github.com/chaos-mesh/chaos-mesh.git
cd chaos-mesh
// create CRD resource
kubectl apply -f manifests/
// install chaos-mesh
helm install helm/chaos-mesh --name=chaos-mesh --namespace=chaos-mesh
```
等待所有组件安装完成，并通过以下命令检查安装状态：
```
// check chaos-mesh status
kubectl get pods --namespace chaos-mesh -l app.kubernetes.io/instance=chaos-mesh
```
若安装成功，您将看到所有 Pod 均处于运行状态。现在可以开始体验了。

您可通过 YAML 定义文件或 Kubernetes API 两种方式运行 Chaos Mesh。

通过 YAML 文件运行混沌实验

通过 YAML 文件方式，您可以自定义混沌实验配置。该方法在应用部署后提供了一种快速便捷的混沌实验实施途径。请按以下步骤操作：

注意： 为便于演示，我们使用 TiDB 作为被测系统。您可选择任意目标系统，并相应调整 YAML 文件内容。

部署名为 chaos-demo-1 的 TiDB 集群。您可使用 TiDB Operator 进行部署。

创建名为 kill-tikv.yaml 的 YAML 文件并添加以下内容：

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-chaos-demo
  namespace: chaos-mesh
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - chaos-demo-1
    labelSelectors:
      'app.kubernetes.io/component': 'tikv'
  scheduler:
    cron: '@every 1m'

保存文件。
执行 kubectl apply -f kill-tikv.yaml 启动混沌实验。

以下混沌实验模拟了 chaos-demo-1 集群中 TiKV Pod 被频繁终止的场景：

我们使用 sysbench 程序监测 TiDB 集群的实时 QPS 变化。当错误注入集群时，QPS 出现剧烈抖动，这表明特定 TiKV Pod 已被删除，随后 Kubernetes 会重新创建新的 TiKV Pod。

更多 YAML 文件示例请参考：https://github.com/chaos-mesh/chaos-mesh/tree/master/examples。

通过 Kubernetes API 运行混沌实验

Chaos Mesh 通过 CRD 定义混沌对象，因此您可直接操作 Kubernetes API 来管理 CRD 对象。这种方式能便捷地将 Chaos Mesh 集成到自定义测试场景中，实现自动化混沌实验。

在 test-infra 项目中，我们模拟了 Kubernetes 上 etcd 集群的潜在故障，包括节点重启、网络故障及文件系统故障。

以下是使用 Kubernetes API 的 Chaos Mesh 示例脚本：

import (
  "context"

  "github.com/chaos-mesh/chaos-mesh/api/v1alpha1"
  "sigs.k8s.io/controller-runtime/pkg/client"
)

func main() {
  // ...
  delay := &chaosv1alpha1.NetworkChaos{
    Spec: chaosv1alpha1.NetworkChaosSpec{
      // ...
    },
  }
  k8sClient := client.New(conf, client.Options{ Scheme: scheme.Scheme })
  k8sClient.Create(context.TODO(), delay)
  k8sClient.Delete(context.TODO(), delay)
}

未来展望

本文向您介绍了 Chaos Mesh——我们开源的云原生混沌工程平台。目前仍有诸多功能正在开发中，我们将持续揭晓其设计理念、应用场景和开发进展，敬请关注。

开源仅是起点。除前文介绍的基础设施级混沌实验外，我们正在支持更广泛、更细粒度的故障类型，例如：

借助 eBPF 等工具在系统调用和内核层面注入错误
通过集成 failpoint 在应用函数和语句级别注入特定错误类型，覆盖传统注入方法无法实现的场景

未来我们将持续优化 Chaos Mesh 仪表盘（Dashboard），让用户直观观测故障注入对线上业务的影响。此外，我们计划提供易用的故障编排界面，并开发 Chaos Mesh Verifier、Chaos Mesh Cloud 等创新功能。

若这些方向令您心动，欢迎加入我们共建世界级混沌工程平台。愿我们的应用在 Kubernetes 的混沌风暴中优雅起舞！

如您发现缺陷或功能建议，欢迎提交 issue、发起 PR，或在 CNCF Slack 工作区的 #project-chaos-mesh 频道联系我们。

GitHub: https://github.com/chaos-mesh/chaos-mesh

为什么选择 Chaos Mesh？​

Chaos Mesh 能做什么？​

设计原则​

简单易用​

高度可扩展​

Kubernetes 原生优先​

CustomResourceDefinitions 设计​

Chaos Mesh 的实现原理​

运行混沌实验​

环境准备​

通过 YAML 文件运行混沌实验​

通过 Kubernetes API 运行混沌实验​

未来展望​