Chaos Mesh 深入解析：Kubernetes 云原生混沌工程平台的架构、特性与快速上手指南

• 云原生
• 运维
• 测试
• 可观测性

Chaos Mesh 是一个开源的、云原生的 Kubernetes 混沌工程平台，它通过 Kubernetes 自定义资源（CRD）来定义、编排并观测针对工作负载、基础设施、云服务和应用的受控故障注入。本文以仓库 README.md 为核心骨架，结合cmd/、controllers/、api/、pkg/等目录的源码实现，系统讲解 Chaos Mesh 的核心特性、三大运行时组件的职责划分、实验编排能力以及从 Helm 安装到运行首个故障实验的完整路径，帮助你快速掌握这套平台的架构全貌与实战用法。

项目概览与定位

Chaos Mesh 由 Cloud Native Computing Foundation（CNCF）托管，是 CNCF 孵化项目之一。它是一个面向 Kubernetes 的混沌工程平台，核心理念是：把故障注入变成 Kubernetes 原生资源——用户通过标准的 Kubernetes API 工具和 RBAC 来创建、管理混沌实验，Controller Manager 负责调和期望状态，Chaos Daemon 在节点上执行特权级故障操作。

在深入细节之前，先用一个宏观视角理解它解决的问题：生产系统中的故障（Pod 崩溃、网络延迟、磁盘 I/O 错误、时钟偏移等）难以在测试环境复现，Chaos Mesh 的价值在于把这些故障封装成语义清晰、可声明、可编排、可观测的 Kubernetes 资源对象，让团队可以像管理普通工作负载一样管理"破坏"。

核心特性

README 中列举了 Chaos Mesh 的五大特性，下面结合源码逐条展开。

广泛的故障覆盖（Broad fault coverage）

Chaos Mesh 支持的故障类型覆盖了应用运行时的各个层面：

• Pod 层：Pod 删除（pod-kill）、Pod 故障（pod-failure）、容器杀死（container-kill）等；
• 网络层：延迟（delay）、丢包（loss）、重复（duplicate）、篡改（corrupt）、分区（partition）、带宽限制（bandwidth）、DNS 故障（DNSChaos）、HTTP 故障（HTTPChaos）；
• 系统层：I/O 故障（IOChaos）、时间偏移（TimeChaos）、压力注入（StressChaos）、内核故障（KernelChaos）；
• 基础设施层：块设备故障（BlockChaos）、物理机故障（PhysicalMachineChaos）；
• 云服务层：AWS（EC2 停止/重启、卷分离）、Azure（VM 停止/重启、磁盘分离）、GCP（节点停止/重置、磁盘丢失）上的故障注入；
• 应用层：JVM 故障（JVMChaos）。

这些类型都在 api/v1alpha1/ 目录下以 CRD 类型定义。以网络混沌为例，api/v1alpha1/networkchaos_types.go 中定义了NetworkChaosAction枚举：netem、delay、loss、duplicate、corrupt、partition、bandwidth，其中netem会把多种动作合并为一次 Netem RPC 发送给 Chaos Daemon；Direction枚举（to、from、both）则控制故障注入的流量方向。

每种顶层混沌 Kind 都通过 api/v1alpha1/kinds.go 中的chaosKindMap全局注册表登记，AllKinds()返回全部混沌类型，AllKindsIncludeScheduleAndWorkflow()则额外包含Schedule和Workflow两个编排类型，供调度与工作流模块按名称动态生成对象。

Kubernetes 原生 API（Kubernetes-native API）

混沌实验以自定义资源的形式存在，通过 Kubernetes API 管理，并使用标准的 Kubernetes 工具和 RBAC。这意味着：

• 你可以用kubectl apply、kubectl get、kubectl delete直接操作混沌资源；
• 混沌资源的访问权限受 Kubernetes RBAC 约束，天然复用集群已有的鉴权体系；
• 实验对象会被 Controller Manager 以声明式（level-based）的方式调和。

RBAC 的完整定义位于 config/rbac/role.yaml，Helm 安装时也会通过rbac.create控制是否创建对应 RBAC 资源。

实验编排（Experiment orchestration）

Chaos Mesh 提供了三种编排资源，支持从简单定时到复杂工作流的完整场景：

• Schedule：基于 Cron 表达式周期性执行混沌实验，支持Forbid（禁止并发，默认）与Allow（允许并发）两种并发策略；
• Workflow：支持串行（serial）或并行（parallel）的故障编排，可以链式组合多个混沌步骤；
• StatusCheck：在实验中周期性地执行 HTTP 健康检查，用于判定应用在混沌注入期间的可用性状态。

以 api/v1alpha1/schedule_types.go 中的ScheduleSpec为例，它包含schedule（Cron 表达式）、startingDeadlineSeconds（启动截止时间）、concurrencyPolicy（并发策略，默认Forbid）、historyLimit（历史记录上限，最小为 1）以及type与内联的ScheduleItem（指定要调度哪种混沌类型）。对应的工作流示例可参考 examples/workflow/serial.yaml、examples/workflow/parallel.yaml 和 examples/workflow/status-check.yaml。

可视化 Dashboard

Dashboard 提供 Web UI 和 HTTP API，用于创建、管理并查看实验、Schedule 与 Workflow 的状态。它是可选的——如果团队习惯直接用 Kubernetes API 管理实验，可以不安装 Dashboard。

多集群执行（Multi-cluster execution）

Chaos Mesh 支持从管理集群（management cluster）注册远程集群（RemoteCluster），并把支持的混沌实验分发到远程集群执行。这一能力由 controllers/multicluster/ 目录下的控制器实现，包括远程集群生命周期管理、远程混沌创建与状态/终结器同步。相关示例参见 examples/remote-cluster/。

架构：三大运行时组件

README 明确指出 Chaos Mesh 有三个主要的运行时组件，这也是理解整个平台的最重要框架：

Chaos Controller Manager

Controller Manager 是"大脑"，职责包括：

• 监听（watch）所有 Chaos Mesh 自定义资源；
• 通过准入 Webhook（admission webhooks）校验请求；
• 编排 Workflow 与实验调度；
• 协调故障注入与恢复（recovery）流程。

其入口位于 cmd/chaos-controller-manager/main.go。从源码可以看到，main.go通过 Uber Fx 依赖注入框架组装整个应用：fx.New(...)将provider.Module、controllers.Module、selector.Module以及混沌对象与 Webhook 对象分组注入，最终由Run函数注册 controller-runtime Manager、各类 Webhook 和/validate-auth鉴权 Webhook（基于SecurityMode、ClusterScoped、TargetNamespace、EnableFilterNamespace等配置）。

控制器的装配点在 controllers/fx.go：它提供 Chaos Daemon 客户端构建器、事件记录器、公共管线步骤与远程集群注册表，注册公共混沌管线、Pod 级控制器（PodHTTPChaos/PodIOChaos/PodNetworkChaos）、工作流控制器、状态检查与多集群控制器，并加载chaosimpl.AllImpl中注册的全部混沌实现。

Controller Manager 的环境配置定义在 pkg/config/controller.go，通过envconfig从环境变量读取，关键项包括：

Chaos Daemon

Chaos Daemon 以 DaemonSet 形式运行在每个 Kubernetes 节点上，是"手脚"。它执行特权级的节点与容器操作，覆盖运行时、进程、网络、文件系统、时钟和内核层面的故障注入。其入口位于 cmd/chaos-daemon/main.go，服务端逻辑集中在 pkg/chaosdaemon/（如dns_server.go、ipset_server.go、iptables_server.go、tc_server.go、time_server_linux.go、stress_server_linux.go等按故障类型划分的服务实现）。

由于需要操纵宿主机网络栈、文件系统与时钟，Chaos Daemon 默认以特权容器运行（Helm 中chaosDaemon.privileged=true），并在 Controller Manager 与 Daemon 之间启用 mTLS（chaosDaemon.mtls.enabled=true）。

Chaos Dashboard

Dashboard 提供 HTTP API 与 Web 界面，由 cmd/chaos-dashboard/main.go 启动，其 API 服务、存储、收集器与 TTL 控制器分布在 pkg/dashboard/。Dashboard 通过 Uber Fx 组装，main.go中还包含了根 Swagger 注解，API 文档生成见make swagger_spec。

组件协作流程

用户通过 Kubernetes API（直接或经 Dashboard）创建或更新 Chaos Mesh 资源 → Controller Manager 调和期望状态 → 需要节点级操作时委托给 Chaos Daemon。顶层混沌对象经由 controllers/common/pipeline/README.md 描述的公共调和管线处理，其步骤顺序是固定不变量：

这套管线把"目标选择、迭代、阶段迁移、持久化与重试"集中在公共层，而每个混沌实现（如 controllers/chaosimpl/podchaos/）只需实现针对单个目标的Apply与Recover行为——这是 controllers/README.md 中强调的"一个字段只有一个逻辑写入者"设计规则。

快速上手：从安装到运行第一个实验

使用 Helm 安装

Chaos Mesh 的官方安装方式是 Helm 3。仓库内完整的 Helm Chart 位于 helm/chaos-mesh/，其详细使用说明见 helm/chaos-mesh/README.md。

安装前提：

• Helm 3 或更高版本；
• 受支持的 Kubernetes 集群与容器运行时；
• 创建集群级资源的权限（CRD、ClusterRole、ClusterRoleBinding、准入 Webhook 配置）；
• 允许在 Chaos Daemon 所在节点运行特权工作负载。

方式一：安装已发布的 Chart（推荐生产使用）

helm repo add chaos-mesh https://charts.chaos-mesh.org helm repo update helm search repo chaos-mesh/chaos-mesh --versions helm install chaos-mesh chaos-mesh/chaos-mesh \ --namespace chaos-mesh \ --create-namespace \ --version <version>

方式二：从仓库源码安装（开发/测试本地改动）

在仓库根目录执行：

helm upgrade --install chaos-mesh ./helm/chaos-mesh \ --namespace chaos-mesh \ --create-namespace

源码 Chart 默认使用latest镜像标签；需要可复现的安装时用--set images.tag=<tag>固定镜像版本，复杂配置则建议写入 values 文件：

helm upgrade --install chaos-mesh ./helm/chaos-mesh \ --namespace chaos-mesh \ --create-namespace \ --values my-values.yaml

验证安装：

kubectl get pods --namespace chaos-mesh \ --selector app.kubernetes.io/instance=chaos-mesh

Chart 安装了什么

根据 helm/chaos-mesh/README.md，Chart 默认安装以下组件：

此外还会创建所需的 Service、RBAC 资源、证书 Secret（或 cert-manager 资源）、准入 Webhook 配置，以及 helm/chaos-mesh/crds/ 中的 CRD。

常用 Helm 配置速查

核心全局配置（来自 helm/chaos-mesh/values.yaml）：

关键组件配置：

容器运行时适配：默认运行时是 Docker。改用 containerd 或 CRI-O 时需同时配置运行时与宿主机 socket：

chaosDaemon: runtime: containerd socketPath: /run/containerd/containerd.sock

chaosDaemon: runtime: crio socketPath: /var/run/crio/crio.sock

命名空间隔离模式：设置clusterScoped=false可将调和与目标绑定限制在单个命名空间（CRD 与控制面部分资源仍为集群级）：

clusterScoped: false controllerManager: targetNamespace: testing dnsServer: targetNamespace: testing

如果希望保持集群级操作、但只允许注入到主动"opt-in"的命名空间，则设置controllerManager.enableFilterNamespace=true并注解命名空间：

kubectl annotate namespace testing chaos-mesh.org/inject=enabled

升级与卸载

升级时先阅读 release notes 与 CRD 变更，并复用安装时的 values 文件：

helm upgrade chaos-mesh chaos-mesh/chaos-mesh \ --namespace chaos-mesh \ --version <version> \ --values my-values.yaml

卸载：

helm uninstall chaos-mesh --namespace chaos-mesh

CRD 生命周期注意事项：Helm 不会升级或删除crds/目录中的 CRD。升级前需要单独审查并应用变更后的 CRD；helm uninstall会有意保留 CRD 及所有 Chaos Mesh 自定义资源在集群中；删除 CRD 属于独立的破坏性操作，会连同其自定义资源一并删除。源码开发时可用kubectl apply --filename helm/chaos-mesh/crds/更新已安装的 CRD。

运行第一个混沌实验

安装完成后即可通过kubectl直接创建混沌实验。以最简单的 PodChaos（pod-kill）为例，examples/pod-kill-example.yaml 给出了完整清单：

apiVersion: chaos-mesh.org/v1alpha1 kind: PodChaos metadata: name: pod-kill-example spec: action: pod-kill mode: one selector: labelSelectors: "app.kubernetes.io/component": "tikv"

应用后，Controller Manager 的公共管线会为目标 Pod 执行Apply注入，故障注入与恢复的状态会通过实验的status字段和 Dashboard 呈现。仓库 examples/ 目录还提供了大量可直接复用的场景模板，包括网络延迟（examples/network-delay-example.yaml）、网络分区（examples/network-partition-example.yaml）、Pod 故障（examples/pod-failure-example.yaml）、I/O 故障（examples/io-delay-example.yaml）、时间偏移（examples/time-chaos-example.yaml）、定时调度（examples/schedule-podchaos.yaml）以及工作流（examples/workflow/serial.yaml）等。

不想搭集群？README 推荐了一个约 20 分钟的交互式 Killercoda 在线练习场景：在真实的双节点 Kubernetes 集群上安装 Chaos Mesh，运行 PodChaos 与 NetworkChaos 实验，探索 Dashboard，并串联一个 Workflow。

深入仓库：源码导航与开发指引

如果想继续深入，README 指向了三份核心文档，仓库内已有完整内容：

• 控制器架构指南：详细介绍 controller-runtime reconciler 的组织方式。所有控制器通过 Uber Fx 在controllers.Module中组装，由cmd/chaos-controller-manager加载。设计规则包括：每个字段只有一个逻辑写入者、调和必须是幂等且 level-based、冲突重试时只重放自己拥有的字段、遵循 controller-runtime v0.21 的错误与 requeue 语义（RequeueAfter用于已知延迟，reconcile.TerminalError仅用于重试无意义的情形）。
• 命令入口点指南：cmd/下每个子目录构建一个命令。产品镜像中交付的二进制为chaos-controller-manager、chaos-daemon、cdh（chaos-daemon-helper）与chaos-dashboard；watchmaker是 Linux 专用的进程时钟偏移辅助工具；chaos-builder与generate-makefile是仓库开发工具，不随服务部署。入口点应保持精简，业务逻辑放在可导入的包中（控制器装配在controllers/，daemon 服务在pkg/chaosdaemon/，Dashboard 服务在pkg/dashboard/）。
• Helm Chart 指南：values.yaml是带注释的主配置参考与默认值来源，values.schema.json由它生成；crds/由api/与config/crd/bases/生成，修改 API 类型后运行make generate并一起审查config/crd/bases/、helm/chaos-mesh/crds/与manifests/crd.yaml的输出。

常用开发命令（来自两份指南，均在仓库根目录执行）：

# 聚焦测试 go test ./controllers/common/... go test ./controllers/schedule/... go test ./controllers/statuscheck/... go test ./controllers/multicluster/... go test ./controllers/chaosimpl/podchaos/... go test ./cmd/chaos-controller-manager/provider/... go test ./pkg/chaosdaemon/... go test ./pkg/dashboard/... go test ./cmd/chaos-builder/... # 构建二进制 make local/chaos-controller-manager make local/chaos-dashboard make images/chaos-daemon/bin/chaos-daemon make images/chaos-daemon/bin/cdh make image-chaos-mesh # 代码/CRD/文档生成 make chaos-build # 仅混沌 API 生成 make generate # deepcopy、clients、CRD、Swagger 等全套生成 make generate-makefile make swagger_spec make helm-values-schema

注意：Chaos Daemon 与 watchmaker 的 Linux 实现依赖 Linux 特性、CGO 或原生辅助对象，并在正常运行中需要提权，应在 Linux 环境使用对应 Make 目标构建验证，不要直接在开发机上执行故障注入辅助程序。

开源治理与生态

作为 CNCF 孵化项目，Chaos Mesh 遵循 Apache License 2.0（见 LICENSE）。仓库同时提供了完整的社区治理材料：贡献流程见 CONTRIBUTING.md，所有贡献者须遵守 CODE_OF_CONDUCT.md，安全问题按 SECURITY.md 流程上报，生产用户列表见 ADOPTERS.md。

结语

Chaos Mesh 用一套简洁而完备的资源模型，把混沌工程从"临时脚本注入故障"演进为"声明式、可编排、可观测的 Kubernetes 原生实践"。从本文的梳理可以看到：三大运行时组件（Controller Manager / Chaos Daemon / Dashboard）各司其职，公共调和管线保证了故障生命周期的确定性，Schedule / Workflow / StatusCheck 提供了从定时触发到复杂编排的完整能力，而 Helm Chart 让安装与配置管理变得标准而可控。如果你正准备在 Kubernetes 上落地混沌工程实践，不妨从 examples/ 中的示例清单开始，结合 controllers/README.md 与 cmd/README.md 深入源码，逐步构建属于自己团队的故障演练体系。

• 云原生
• 运维
• 测试
• 可观测性