云原生运维测试可观测性【免费下载链接】chaos-meshA Chaos Engineering Platform for Kubernetes.项目地址https://gitcode.com/gh_mirrors/ch/chaos-mesh点击查看免费下载本篇文章基于 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. Its 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.goconst ( // 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.cpuworkers工作线程数最大 8192、load每个 CPU worker 的负载百分比0 表示休眠、100 表示满载取值范围 0-100、options透传给 stress-ng 的扩展参数。stressors.memoryworkers、size每个 vm worker 消耗的字节数可写为绝对大小如10GB也可按总可用内存的百分比、oomScoreAdjstress 进程的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.yamlsize: 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其核心字段包括scheduleCron 表达式仓库使用支持秒级可选的标准解析器StandardCronParser组合了SecondOptional | Minute | Hour | Dom | Month | Dow | Descriptor。concurrencyPolicyForbid默认或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.shUI 源码位于 ui/app/src/表明 Dashboard 前后端已深度集成。状态检查评估环境健康度路线图要求支持状态检查StatusCheck用于评估应用环境在混沌注入期间及之后的健康状态。StatusCheck资源定义见 api/v1alpha1/statuscheck_types.go其StatusCheckSpec提供了一套贴近 Kubernetes 探针语义的完整参数type状态检查类型当前仅支持HTTP默认值。modeSynchronous成功或失败后立即结束或Continuous持续执行直到超时或失败。duration整个状态检查的总时长。timeoutSeconds单次执行的超时时间默认 1最小 1。intervalSeconds执行间隔秒数默认 10最小 1。failureThreshold视为状态检查失败所需的最小连续失败次数默认 3最小 1。successThreshold视为状态检查成功所需的最小连续成功次数默认 1最小 1仅对Synchronous模式生效。recordsHistoryLimit保留的历史记录条数默认 100范围 1-1000。HTTP 检查的请求描述支持url、methodGET/POST默认GET、headers、body以及criteria.statusCode——它既可以是单个状态码如200也可以是包含两端的闭区间如200-400。检查结果通过StatusCheckRecord记录每次执行的StartTime与Outcome和StatusCheckConditionCompleted、DurationExceed、FailureThresholdExceed、SuccessThresholdExceed等条件暴露相关字段同样定义在 api/v1alpha1/statuscheck_types.go。控制器实现在 controllers/statuscheck/含 controller、manager、worker、http 子包及配套测试。最小示例见 examples/statuscheck-example.yamlapiVersion: 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-kubernetesWorkflow 的执行控制器位于 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匹配 SQLmysqlConnectorVersion目前仅支持 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.yamlapiVersion: 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: - helloworldHTTP 混沌向 HTTP 连接注入故障路线图要求新增 HTTP 混沌支持向 HTTP 连接注入故障。HTTPChaos的类型定义见 api/v1alpha1/httpchaos_types.go其核心规格包括target注入目标为Request或Response。port被代理的目标端口。path/method/code/request_headers/response_headers按 URI 路径、HTTP 方法、响应状态码或请求/响应头选择命中的请求。tlsTLS 配置多个 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 进程。中期内尚未完成的方向路线图明确列出的未完成方向每一项都对应明确的工程缺口向 Kubernetes 原生组件注入故障由 v2.0 划掉项转入。更全面的状态检查机制与报告现有 StatusCheck 仅支持 HTTP 类型见 api/v1alpha1/statuscheck_types.go 中Type字段的枚举约束扩展更多检查类型与更丰富的报告能力是明确方向。通过事件日志与指标改进可观测性仓库已有 pkg/metrics/含 chaos-controller-manager、chaos-daemon、chaos-dashboard 三套指标与 pkg/events/、pkg/log/ 等基础设施但更全面的观测机制仍属规划。改进认证系统支持使用 GCP/AWS 账号登录 Dashboard。新增 GRPC Chaos。新增组件以强制恢复混沌实验、避免实验失控这是对混沌实验安全护栏的长期规划。构建混沌工作流与混沌类型分享的 Hub。支持在多个 Kubernetes 集群上执行混沌实验多集群能力已有雏形controllers/multicluster/ 与 examples/remote-cluster/但更大规模的跨集群实验编排仍属规划。提供插件机制扩展复杂混沌类型如 RabbitMQChaos、RedisChaos 等从 api/v1alpha1/physical_machine_chaos_types.go 的user_defined动作可以看出仓库已在物理机场景提供了用户自定义命令的灵活性插件化机制则是把这种灵活性推广到所有混沌类型的方向。继续丰富故障类型这是贯穿始终的长期目标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命令入口开始阅读。赞分享云原生运维测试可观测性【免费下载链接】chaos-meshA Chaos Engineering Platform for Kubernetes.项目地址https://gitcode.com/gh_mirrors/ch/chaos-mesh点击查看免费下载相关推荐告别网络依赖Pokerogue桌面版带你随时随地畅玩宝可梦Roguelike告别网络依赖Pokerogue桌面版带你随时随地畅玩宝可梦Roguelike 厌倦了每次打开浏览器都要等待网页加载受够了网络不稳定导致游戏中断的烦恼Pok标题混沌工程新星Chaos Mesh —— 云原生故障注入平台标题混沌工程新星Chaos Mesh —— 云原生故障注入平台 在数字化时代系统的高可用性和稳定性是企业成功的关键因素。这就是为什么混沌工程Chaos云原生运维测试可观测性如何在iPhone上畅玩Minecraft Java版PojavLauncher iOS完整指南如何在iPhone上畅玩Minecraft Java版PojavLauncher iOS完整指南 想要在iPhone上体验原汁原味的Minecraft Jav游戏开发移动开发上一篇templatespider实战教程3步将任意网站转化为可复用模板下一篇终极指南如何为Nintendo Switch安装Atmosphere定制固件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Chaos Mesh 路线图解读：从 v1.0 故障注入到 v2.0 混沌编排平台的演进之路
云原生运维测试可观测性【免费下载链接】chaos-meshA Chaos Engineering Platform for Kubernetes.项目地址https://gitcode.com/gh_mirrors/ch/chaos-mesh点击查看免费下载本篇文章基于 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. Its 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.goconst ( // 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.cpuworkers工作线程数最大 8192、load每个 CPU worker 的负载百分比0 表示休眠、100 表示满载取值范围 0-100、options透传给 stress-ng 的扩展参数。stressors.memoryworkers、size每个 vm worker 消耗的字节数可写为绝对大小如10GB也可按总可用内存的百分比、oomScoreAdjstress 进程的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.yamlsize: 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其核心字段包括scheduleCron 表达式仓库使用支持秒级可选的标准解析器StandardCronParser组合了SecondOptional | Minute | Hour | Dom | Month | Dow | Descriptor。concurrencyPolicyForbid默认或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.shUI 源码位于 ui/app/src/表明 Dashboard 前后端已深度集成。状态检查评估环境健康度路线图要求支持状态检查StatusCheck用于评估应用环境在混沌注入期间及之后的健康状态。StatusCheck资源定义见 api/v1alpha1/statuscheck_types.go其StatusCheckSpec提供了一套贴近 Kubernetes 探针语义的完整参数type状态检查类型当前仅支持HTTP默认值。modeSynchronous成功或失败后立即结束或Continuous持续执行直到超时或失败。duration整个状态检查的总时长。timeoutSeconds单次执行的超时时间默认 1最小 1。intervalSeconds执行间隔秒数默认 10最小 1。failureThreshold视为状态检查失败所需的最小连续失败次数默认 3最小 1。successThreshold视为状态检查成功所需的最小连续成功次数默认 1最小 1仅对Synchronous模式生效。recordsHistoryLimit保留的历史记录条数默认 100范围 1-1000。HTTP 检查的请求描述支持url、methodGET/POST默认GET、headers、body以及criteria.statusCode——它既可以是单个状态码如200也可以是包含两端的闭区间如200-400。检查结果通过StatusCheckRecord记录每次执行的StartTime与Outcome和StatusCheckConditionCompleted、DurationExceed、FailureThresholdExceed、SuccessThresholdExceed等条件暴露相关字段同样定义在 api/v1alpha1/statuscheck_types.go。控制器实现在 controllers/statuscheck/含 controller、manager、worker、http 子包及配套测试。最小示例见 examples/statuscheck-example.yamlapiVersion: 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-kubernetesWorkflow 的执行控制器位于 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匹配 SQLmysqlConnectorVersion目前仅支持 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.yamlapiVersion: 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: - helloworldHTTP 混沌向 HTTP 连接注入故障路线图要求新增 HTTP 混沌支持向 HTTP 连接注入故障。HTTPChaos的类型定义见 api/v1alpha1/httpchaos_types.go其核心规格包括target注入目标为Request或Response。port被代理的目标端口。path/method/code/request_headers/response_headers按 URI 路径、HTTP 方法、响应状态码或请求/响应头选择命中的请求。tlsTLS 配置多个 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 进程。中期内尚未完成的方向路线图明确列出的未完成方向每一项都对应明确的工程缺口向 Kubernetes 原生组件注入故障由 v2.0 划掉项转入。更全面的状态检查机制与报告现有 StatusCheck 仅支持 HTTP 类型见 api/v1alpha1/statuscheck_types.go 中Type字段的枚举约束扩展更多检查类型与更丰富的报告能力是明确方向。通过事件日志与指标改进可观测性仓库已有 pkg/metrics/含 chaos-controller-manager、chaos-daemon、chaos-dashboard 三套指标与 pkg/events/、pkg/log/ 等基础设施但更全面的观测机制仍属规划。改进认证系统支持使用 GCP/AWS 账号登录 Dashboard。新增 GRPC Chaos。新增组件以强制恢复混沌实验、避免实验失控这是对混沌实验安全护栏的长期规划。构建混沌工作流与混沌类型分享的 Hub。支持在多个 Kubernetes 集群上执行混沌实验多集群能力已有雏形controllers/multicluster/ 与 examples/remote-cluster/但更大规模的跨集群实验编排仍属规划。提供插件机制扩展复杂混沌类型如 RabbitMQChaos、RedisChaos 等从 api/v1alpha1/physical_machine_chaos_types.go 的user_defined动作可以看出仓库已在物理机场景提供了用户自定义命令的灵活性插件化机制则是把这种灵活性推广到所有混沌类型的方向。继续丰富故障类型这是贯穿始终的长期目标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命令入口开始阅读。赞分享云原生运维测试可观测性【免费下载链接】chaos-meshA Chaos Engineering Platform for Kubernetes.项目地址https://gitcode.com/gh_mirrors/ch/chaos-mesh点击查看免费下载相关推荐告别网络依赖Pokerogue桌面版带你随时随地畅玩宝可梦Roguelike告别网络依赖Pokerogue桌面版带你随时随地畅玩宝可梦Roguelike 厌倦了每次打开浏览器都要等待网页加载受够了网络不稳定导致游戏中断的烦恼Pok标题混沌工程新星Chaos Mesh —— 云原生故障注入平台标题混沌工程新星Chaos Mesh —— 云原生故障注入平台 在数字化时代系统的高可用性和稳定性是企业成功的关键因素。这就是为什么混沌工程Chaos云原生运维测试可观测性如何在iPhone上畅玩Minecraft Java版PojavLauncher iOS完整指南如何在iPhone上畅玩Minecraft Java版PojavLauncher iOS完整指南 想要在iPhone上体验原汁原味的Minecraft Jav游戏开发移动开发上一篇templatespider实战教程3步将任意网站转化为可复用模板下一篇终极指南如何为Nintendo Switch安装Atmosphere定制固件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考