Chaos Mesh 路线图解读：从 v1.0 故障注入到 v2.0 混沌编排平台的演进之路

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

本篇文章基于 Chaos Mesh 仓库中的 ROADMAP.md 官方路线图文档，逐条解读 Chaos Mesh 从 v1.0 到 v2.0 再到中期规划的技术演进脉络。你将了解每项规划对应的故障注入类型（时间偏移、容器杀死、CPU/内存压力等）、编排与健康检查能力（Schedule、Workflow、StatusCheck）、以及 Dashboard、多集群、插件化等扩展方向，并看到每条路线图条目在仓库源码与示例中的具体落点，掌握"路线图声明了什么、代码里是如何实现"的完整对应关系。

需要说明的是，路线图文档自身明确声明：它用于描述项目的高层计划，既非全面覆盖、也非强制规定，更细粒度的规划以项目的里程碑（milestones）为准。因此本文对已完成条目给出仓库内的实现证据，对未完成条目如实标注为规划方向，不做过度的可行性承诺。

v1.0：奠定核心故障注入能力

v1.0 是 Chaos Mesh 从"故障注入工具"走向"可用的混沌工程平台"的奠基版本，其全部条目均已完成。这一阶段的核心成果集中在 Pod 级故障注入、压力注入、调度简化与安装运维体验四个方面。

时间偏移混沌：模拟时钟向前或向后跳变

路线图要求支持时间偏移混沌，即模拟系统时间向前或向后跳变。这一能力对应仓库中的TimeChaos自定义资源，其类型定义位于 api/v1alpha1/timechaos_types.go：

// TimeChaosSpec defines the desired state of TimeChaos type TimeChaosSpec struct { ContainerSelector `json:",inline"` // TimeOffset defines the delta time of injected program. It's a possibly signed sequence of decimal numbers, such as // "300ms", "-1.5h" or "2h45m". Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". TimeOffset string `json:"timeOffset" webhook:"TimeOffset"` // ClockIds defines all affected clock id // Default value is ["CLOCK_REALTIME"] ClockIds []string `json:"clockIds,omitempty" webhook:"ClockIds,nilable"` // Duration represents the duration of the chaos action Duration *string `json:"duration,omitempty"` }

关键参数说明：

• timeOffset：必填，注入程序的时间偏移量，支持带符号的十进制数字序列，如"300ms"、"-1.5h"、"2h45m"；合法时间单位为ns、us（或µs）、ms、s、m、h。
• clockIds：可选，指定受影响的时钟 ID，可用选项包括CLOCK_REALTIME、CLOCK_MONOTONIC、CLOCK_PROCESS_CPUTIME_ID、CLOCK_THREAD_CPUTIME_ID、CLOCK_MONOTONIC_RAW、CLOCK_REALTIME_COARSE、CLOCK_MONOTONIC_COARSE、CLOCK_BOOTTIME、CLOCK_REALTIME_ALARM、CLOCK_BOOTTIME_ALARM，默认值为["CLOCK_REALTIME"]。
• duration：可选，混沌动作的持续时间。

仓库中的最小可运行示例见 examples/time-chaos-example.yaml，该示例把选中 Pod 的时钟回拨 10 分钟并持续 30 秒：

apiVersion: chaos-mesh.org/v1alpha1 kind: TimeChaos metadata: name: time-shift-example spec: mode: one selector: labelSelectors: "app.kubernetes.io/component": "tikv" timeOffset: "-10m100ns" duration: "30s"

容器杀死混沌：在多容器 Pod 中杀死指定容器

路线图要求支持容器杀死混沌，用于模拟多容器 Pod 中某个指定容器被杀死的场景。这一能力体现在PodChaos的container-kill动作上，动作类型定义于 api/v1alpha1/podchaos_types.go：

const ( // PodKillAction represents the chaos action of killing pods. PodKillAction PodChaosAction = "pod-kill" // PodFailureAction represents the chaos action of injecting errors to pods. PodFailureAction PodChaosAction = "pod-failure" // ContainerKillAction represents the chaos action of killing the container ContainerKillAction PodChaosAction = "container-kill" )

底层实现位于 controllers/chaosimpl/podchaos/containerkill/impl.go。Apply方法先通过decoder.DecodeContainerRecord解析出目标容器及其 gRPC 客户端，然后向 Chaos Daemon 发送ContainerAction_KILL请求完成注入；Recover方法直接返回NotInjected，因为容器被杀死后无需（也无法）执行恢复逻辑：

if _, err = pbClient.ContainerKill(ctx, &pb.ContainerRequest{ Action: &pb.ContainerAction{ Action: pb.ContainerAction_KILL, }, ContainerId: containerId, }); err != nil { impl.Log.Error(err, "kill container error", "containerID", containerId) return v1alpha1.NotInjected, err }

示例见 examples/container-kill-example.yaml，通过containerNames指定 Pod 内要被杀死的具体容器：

apiVersion: chaos-mesh.org/v1alpha1 kind: PodChaos metadata: name: container-kill-example spec: action: container-kill mode: one selector: labelSelectors: app.kubernetes.io/component: monitor containerNames: - prometheus

同属 PodChaos 家族的pod-kill动作对应 examples/pod-kill-example.yaml，且 api/v1alpha1/podchaos_types.go 中还提供了gracePeriod字段（默认 0，表示立即删除）用于控制 pod-kill 的优雅删除等待时间。

CPU 混沌与内存混沌：模拟 CPU 繁忙与内存分配失败

路线图要求支持 CPU 混沌（模拟 CPU 繁忙）与内存混沌（模拟内存分配失败）。这两者统一由StressChaos资源承载，类型定义见 api/v1alpha1/stresschaos_types.go，其规格包含两类压力器：

• stressors.cpu：workers（工作线程数，最大 8192）、load（每个 CPU worker 的负载百分比，0 表示休眠、100 表示满载，取值范围 0-100）、options（透传给 stress-ng 的扩展参数）。
• stressors.memory：workers、size（每个 vm worker 消耗的字节数，可写为绝对大小如10GB，也可按总可用内存的百分比）、oomScoreAdj（stress 进程的oom_score_adj，取值范围 -1000 到 1000，默认 0）、options。

代码中的Normalize()方法（api/v1alpha1/stresschaos_types.go）负责把这些声明式配置转换为 stress-ng 命令行参数，其中 CPU 压力默认附加--cpu-load-slice 10 --cpu-method sqrt以保证在 worker 数大于 1 时能真正触达 Pod 的资源上限。

CPU 压力示例见 examples/burn-cpu.yaml（单 worker 满载烧 CPU），内存压力示例见 examples/cause-pod-oom.yaml（size: 10GB配合oomScoreAdj: -1000，可被用于制造容器 OOM 的场景）：

apiVersion: chaos-mesh.org/v1alpha1 kind: StressChaos metadata: name: pod-oom spec: mode: one selector: labelSelectors: "app.kubernetes.io/component": "tikv" stressors: memory: workers: 1 size: 10GB oomScoreAdj: -1000 duration: "30s"

此外，StressChaosSpec还支持stressngStressors字段，允许直接以 stress-ng 方言定义更强大的压力场景（标注为实验特性，当两者同时定义时stressngStressors优先），这是"继续丰富故障类型"路线图在 API 层面的早期铺垫。

调度器可选：支持单次混沌触发

路线图要求"让调度器可选"，即允许不依赖周期调度而直接单次触发混沌实验。这对应仓库中Schedule资源与直接创建*Chaos实验资源两种路径并存的设计。Schedule的类型定义见 api/v1alpha1/schedule_types.go，其核心字段包括：

• schedule：Cron 表达式，仓库使用支持秒级可选的标准解析器StandardCronParser（组合了SecondOptional | Minute | Hour | Dom | Month | Dow | Descriptor）。
• concurrencyPolicy：Forbid（默认）或Allow，控制上次实验未结束时是否允许并发触发下一次。
• historyLimit：保留的历史记录数量，最小为 1。
• startingDeadlineSeconds：错过调度窗口后的启动截止时间。

而"单次触发"路径则直接kubectl apply一个不含调度字段的混沌资源即可，例如上面展示的 TimeChaos、PodChaos、StressChaos 示例都无需携带调度配置。周期触发的示例见 examples/schedule-podchaos.yaml。

无 Helm 安装与 finalizer 强制清理

• 无 Helm 安装：v1.0 起支持不依赖 Helm 的安装方式。仓库的 manifests/ 目录提供了独立的 manifests/crd.yaml 等资源清单，同时 helm/chaos-mesh/ 仍保留 Helm Chart 方式（其 CRD 清单位于 helm/chaos-mesh/crds/），两种安装路径并存。
• finalizer 强制清理注解：混沌实验在结束时需要通过 finalizer 清理副作用（如网络规则、注入代理等），但异常场景下 finalizer 可能阻塞资源删除。路线图中的"用注解强制清理 finalizer"能力与 pkg/annotation/utils.go 中的注解机制相关，该文件定义了chaos-mesh注解前缀及镜像类注解 key 的生成规则，并且 key 长度超过 63 字符时会退化为仅使用容器名，以符合 Kubernetes 注解命名约束；finalizer 的具体处理逻辑可从 controllers/common/finalizers/ 的实现中进一步查看。

Chaos Dashboard 基础版

v1.0 交付了 Chaos Dashboard 基础版，它提供 HTTP API 与 Web 界面用于创建、管理和观察混沌实验。Dashboard 的入口位于 cmd/chaos-dashboard/main.go，核心代码集中在 pkg/dashboard/（含 apiserver、core、store、collector、uiserver 等子模块）。从架构上看，Dashboard 是可选的：实验也可以完全通过 Kubernetes API 直接管理，这与"调度器可选"的设计哲学一脉相承。

v2.0：从故障注入走向混沌编排生态

v2.0 的核心主题是把 Chaos Mesh 从"单个故障注入工具"升级为"混沌工程生态"。这一版本中，绝大部分条目已经完成，另有两项在 v2.0 范围内被明确划掉（放弃），我们逐一说明。

Dashboard 体验改进

路线图要求改进 Chaos Dashboard 并使其更易使用。仓库中 pkg/dashboard/apiserver/ 包含 25 个 Go 文件，覆盖实验、调度、工作流等资源的 API 层；同时仓库内嵌了前端资产（相关生成逻辑见 hack/embed_ui_assets.sh），UI 源码位于 ui/app/src/，表明 Dashboard 前后端已深度集成。

状态检查：评估环境健康度

路线图要求支持状态检查（StatusCheck），用于评估应用环境在混沌注入期间及之后的健康状态。StatusCheck资源定义见 api/v1alpha1/statuscheck_types.go，其StatusCheckSpec提供了一套贴近 Kubernetes 探针语义的完整参数：

• type：状态检查类型，当前仅支持HTTP（默认值）。
• mode：Synchronous（成功或失败后立即结束）或Continuous（持续执行直到超时或失败）。
• duration：整个状态检查的总时长。
• timeoutSeconds：单次执行的超时时间，默认 1，最小 1。
• intervalSeconds：执行间隔秒数，默认 10，最小 1。
• failureThreshold：视为状态检查失败所需的最小连续失败次数，默认 3，最小 1。
• successThreshold：视为状态检查成功所需的最小连续成功次数，默认 1，最小 1，仅对Synchronous模式生效。
• recordsHistoryLimit：保留的历史记录条数，默认 100，范围 1-1000。

HTTP 检查的请求描述支持url、method（GET/POST，默认GET）、headers、body，以及criteria.statusCode——它既可以是单个状态码（如200），也可以是包含两端的闭区间（如200-400）。检查结果通过StatusCheckRecord（记录每次执行的StartTime与Outcome）和StatusCheckCondition（Completed、DurationExceed、FailureThresholdExceed、SuccessThresholdExceed等条件）暴露，相关字段同样定义在 api/v1alpha1/statuscheck_types.go。控制器实现在 controllers/statuscheck/（含 controller、manager、worker、http 子包及配套测试）。

最小示例见 examples/statuscheck-example.yaml：

apiVersion: chaos-mesh.org/v1alpha1 kind: StatusCheck metadata: name: status-check-example spec: type: HTTP http: url: http://123.123.123.123 method: GET criteria: statusCode: "200"

状态检查的Records历史能力与"为每个混沌场景生成报告"的路线图条目在数据层面直接相关，可视为报告生成的基础数据来源。

场景定义：编排一组混沌实验

路线图要求"支持定义场景以管理一组混沌实验"，这一能力由Workflow资源承担，类型定义见 api/v1alpha1/workflow_types.go。WorkflowSpec由entry（入口模板名）与templates（模板列表）组成，模板类型包括：

• Serial：串行执行children中的子模板，支持deadline截止时间。
• Parallel：并行执行多个子模板。
• Suspend：挂起一段时间（通过deadline控制）。
• 各类*Chaos模板：内嵌对应的混沌规格。
• Schedule：内嵌调度规格（ChaosOnlyScheduleSpec，只能调度混沌、不能嵌套调度 Workflow，文档注释说明这是为了避免嵌套 CRD 解析问题）。
• StatusCheck：内嵌状态检查规格，并可通过abortWithStatusCheck控制在失败阈值被超过时中止整个工作流。
• Task：自定义任务，可运行任意容器镜像并挂载卷，适合做自定义检查步骤。

完整的串行工作流示例见 examples/workflow/serial.yaml，它依次编排了 StressChaos、挂起、NetworkChaos、Schedule（每 2 秒一次的 pod-kill）和挂起等步骤，并在入口模板上设置了 240 秒总截止时间：

apiVersion: chaos-mesh.org/v1alpha1 kind: Workflow metadata: name: try-workflow-serial spec: entry: the-entry templates: - name: the-entry templateType: Serial deadline: 240s children: - workflow-stress-chaos - prefix-suspending - workflow-network-chaos - suffix-suspending - workflow-pod-chaos - name: workflow-network-chaos templateType: NetworkChaos deadline: 20s networkChaos: direction: to action: delay mode: all selector: labelSelectors: "app": "hello-kubernetes" delay: latency: "90ms" correlation: "25" jitter: "90ms" - name: workflow-pod-chaos templateType: Schedule deadline: 40s schedule: schedule: "@every 2s" concurrencyPolicy: Allow type: PodChaos podChaos: action: pod-kill mode: one selector: labelSelectors: "app": "hello-kubernetes"

Workflow 的执行控制器位于 pkg/workflow/controllers/，工作流的设计思路可参考 workflow/docs/design.md。同目录的 examples/workflow/parallel.yaml 与 examples/workflow/custom-task.yaml 提供了并行编排与自定义任务两种补充形态。

为每个混沌场景生成报告

路线图要求支持为每个混沌场景生成报告。如前所述，StatusCheck的Records机制会持久化每次检查的执行时间与成败结果，Workflow则会记录StartTime、EndTime以及Accomplished/Scheduled等条件状态（见 api/v1alpha1/workflow_types.go），这些结构化数据共同构成场景报告的素材来源。路线图中将该能力列为已完成；报告中更细粒度的形态仍属于中期规划中"更全面的状态检查机制与报告"的演进范畴。

JVM 混沌：向 Java 应用注入故障

路线图要求新增 JVM 混沌，支持向 Java 应用注入故障。JVMChaos的类型定义见 api/v1alpha1/jvmchaos_types.go，支持的动作包括：

• latency：为指定方法注入调用延迟（latency字段，单位毫秒）。
• return：篡改指定方法的返回值（returnValue）。
• exception：抛出指定异常（exception，例如java.io.IOException("BOOM")）。
• stress：对 JVM 施加 CPU/内存压力（cpuCount、memType取stack或heap）。
• gc：触发垃圾回收。
• ruleData：直接以 Byteman 规则语言注入自定义故障（ruleData）。
• mysql：针对 MySQL Java 客户端注入故障（JVMMySQLSpec支持按database、table、sqlType匹配 SQL，mysqlConnectorVersion目前仅支持 5.X（写"5"）与 8.X（写"8"））。

其公共参数还包括 agent 服务端口（默认 9277）与 Java 进程 PID。故障注入基于 Byteman 实现，服务端代码位于 pkg/chaosdaemon/jvm_server.go，仓库还提供了配套示例应用 examples/jvm/app.yaml。

异常注入示例见 examples/jvm/jvm-exception-example.yaml：

apiVersion: chaos-mesh.org/v1alpha1 kind: JVMChaos metadata: name: exception spec: action: exception class: Main method: sayhello exception: java.io.IOException("BOOM") mode: all selector: namespaces: - helloworld

HTTP 混沌：向 HTTP 连接注入故障

路线图要求新增 HTTP 混沌，支持向 HTTP 连接注入故障。HTTPChaos的类型定义见 api/v1alpha1/httpchaos_types.go，其核心规格包括：

• target：注入目标为Request或Response。
• port：被代理的目标端口。
• path/method/code/request_headers/response_headers：按 URI 路径、HTTP 方法、响应状态码或请求/响应头选择命中的请求。
• tls：TLS 配置，多个 HTTPChaos 实验同时作用时会覆盖 PodHttpChaos 的默认配置。
• 内嵌的PodHttpChaosActions：提供具体的故障动作（如对响应 body 打补丁、注入延迟、中止连接等，详见 api/v1alpha1/podhttpchaos_types.go）。

响应篡改示例见 examples/nginx/http-patch-response.yaml，它把 nginx 的 JSON 响应体整体替换为自定义内容：

kind: HTTPChaos apiVersion: chaos-mesh.org/v1alpha1 spec: selector: namespaces: - default labelSelectors: app: nginx mode: all target: Response patch: body: type: JSON value: '{"status":"Failed","reason":"hacked by Chaos Mesh"}' port: 80 path: '*'

HTTPChaos 的控制器与代理管理逻辑位于 controllers/chaosimpl/httpchaos/，Chaos Daemon 侧的代理服务实现见 pkg/chaosdaemon/httpchaos_server.go。

v2.0 中划掉的两项

路线图文档在 v2.0 部分用删除线明确标记了两项不在 v2.0 范围内交付的能力：

• GRPC Chaos（向 GRPC 连接注入故障）：v2.0 中放弃，被推迟到中期规划，届时以未勾选状态重新出现。
• 向 Kubernetes 原生组件注入故障：v2.0 中放弃，同样被重新列入中期规划。

这两项在中期规划章节中仍以未完成条目保留，说明它们是长期演进方向而非彻底取消。

Medium term：中期演进方向

中期规划分为"已完成"与"待完成"两类，既反映项目已经落地的能力，也暴露了后续版本最值得关注的空白。

中期内已完成的两项

• 在统一 Dashboard 上管理和调度 Kubernetes 与非 Kubernetes 目标上的混沌实验：非 Kubernetes 目标对应PhysicalMachineChaos资源，其类型定义见 api/v1alpha1/physical_machine_chaos_types.go。该资源提供了极为丰富的动作枚举：stress-cpu、stress-mem、磁盘读写/填充、network-corrupt/duplicate/loss/delay/partition/dns/bandwidth/flood/down、process、JVM 系列（jvm-exception/gc/latency/return/stress/rule-data/mysql）、clock、Redis 系列（redis-expiration/penetration/cacheLimit/restart/stop）、Kafka 系列（kafka-fill/flood/io）、HTTP 系列、文件系列（create/modify/delete/rename/append/replace）、vm与user_defined。示例见 examples/physicalmachinechaos/；"统一管理"的架构支撑是 controllers/multicluster/ 下的远程集群与远程 Pod 协调模块。
• 改进 JVMChaos 并支持动态注入：从 api/v1alpha1/jvmchaos_types.go 的 API 结构看，JVMChaos支持多种可随时调整的动作与参数（延迟、返回值、异常、压力、GC、规则数据、MySQL），配合 agent 机制可以做到运行时注入与恢复，而无需重启目标 Java 进程。

中期内尚未完成的方向

路线图明确列出的未完成方向，每一项都对应明确的工程缺口：

1. 向 Kubernetes 原生组件注入故障（由 v2.0 划掉项转入）。
2. 更全面的状态检查机制与报告：现有 StatusCheck 仅支持 HTTP 类型（见 api/v1alpha1/statuscheck_types.go 中Type字段的枚举约束），扩展更多检查类型与更丰富的报告能力是明确方向。
3. 通过事件日志与指标改进可观测性：仓库已有 pkg/metrics/（含 chaos-controller-manager、chaos-daemon、chaos-dashboard 三套指标）与 pkg/events/、pkg/log/ 等基础设施，但更全面的观测机制仍属规划。
4. 改进认证系统，支持使用 GCP/AWS 账号登录 Dashboard。
5. 新增 GRPC Chaos。
6. 新增组件以强制恢复混沌实验、避免实验失控：这是对"混沌实验安全护栏"的长期规划。
7. 构建混沌工作流与混沌类型分享的 Hub。
8. 支持在多个 Kubernetes 集群上执行混沌实验：多集群能力已有雏形（controllers/multicluster/ 与 examples/remote-cluster/），但更大规模的跨集群实验编排仍属规划。
9. 提供插件机制扩展复杂混沌类型（如 RabbitMQChaos、RedisChaos 等）：从 api/v1alpha1/physical_machine_chaos_types.go 的user_defined动作可以看出，仓库已在物理机场景提供了"用户自定义命令"的灵活性，插件化机制则是把这种灵活性推广到所有混沌类型的方向。
10. 继续丰富故障类型：这是贯穿始终的长期目标，v2.0 已新增 JVM 与 HTTP，物理机侧已覆盖 Redis、Kafka、文件系统等动作，未来故障面会持续扩大。

结语：从路线图看 Chaos Mesh 的演进逻辑

对照 ROADMAP.md 与仓库源码，可以清晰地看到 Chaos Mesh 的三阶段演进逻辑：

• **v1.0（已完成）**解决"能不能注入故障"的问题：时间偏移、容器杀死、CPU/内存压力等核心故障类型全部落地，同时通过可选调度器、无 Helm 安装与 finalizer 强制清理注解解决了可用性与运维体验问题。
• **v2.0（主体已完成）**解决"如何组织与验证混沌"的问题：StatusCheck 提供健康评估，Workflow 提供场景编排与报告素材，JVM/HTTP 混沌把故障面从基础设施扩展到应用层，Dashboard 则把这一切统一到可视化入口。
• 中期规划解决"如何让混沌工程规模化"的问题：多集群、插件化、混沌分享 Hub、更完善的恢复与可观测性机制，都是在 v1.0 与 v2.0 已验证的地基之上延伸。

对于已经完成的路线图条目，读者可以直接在仓库中找到对应的 CRD 类型、控制器实现与可运行示例（examples/ 目录是快速上手的入口）；对于尚未完成的条目，它们代表的是项目当前明确的演进方向，跟踪更细粒度的进展可关注项目的里程碑页面。若想进一步深入实现细节，可以从 controllers/README.md（控制器架构）与 cmd/README.md（命令入口）开始阅读。

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