WeScale 采用 Litmus 实录：云原生咨询场景下的 Kubernetes 混沌工程、CI 注入与爆炸半径实践

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

本篇技术指南围绕开源仓库 adopters/organizations/wescale.md 中记录的 WeScale 采用案例展开，梳理这家法国云原生咨询公司在为客户交付微服务韧性验证时选择 Litmus 的动机、落地方式与收益，并结合当前仓库的 ChaosHub GraphQL 实现、CI/CD 集成文档、实验分类与安装清单等源码级证据进行纵深解读。读完本文，你将理解：咨询/服务商团队如何在多客户、多 CI 工具的环境下通过 ChaosHub 注入混沌实验，如何按"从 Pod 到集群"的爆炸半径递进安排故障注入，以及 Litmus 控制面（Litmus Portal/ChaosCenter）与执行面组件在实际部署中的分工。

案例背景：WeScale 是谁，为什么需要混沌工程

WeScale 是一家总部位于法国的技术咨询公司，定位为"Cloud pureplayer"，专注于 DevOps 与数字化自动化。其业务模式是多服务提供方——帮助企业在云项目中理解需求与目标、推进数字化转型，并提升团队在 Chaos Engineering 以及数字工具与软件方面的技能。WeScale 自身依托 AWS、GCP 等公有云平台为客户交付云管理能力，目标是"加速创新"，并让客户部署的微服务具备更高的韧性（resiliency）。

在仓库的 ADOPTERS.md 中，WeScale 被归入Cloud-Native Solutions & Service Providers分类（使用场景标注为 Chaos Engineering），这类公司"为客户/组织提供云原生解决方案与技术服务，常在客户端环境中选择 Litmus 作为执行混沌实验的工具，或将其作为更大规模定制 DevOps 平台的基础构件"。这正对应 WeScale 的实际诉求：不是在自建集群里自娱自乐，而是把混沌工程作为一项可交付的服务能力，嵌入到不同客户的系统验证流程中。

为什么选择 Litmus：混沌注入工具的选型逻辑

WeScale 的原话很直白：为了提升客户系统的韧性，他们要做混沌工程；但在微服务中注入混沌的可选工具很多，在尝试了大量工具之后，Litmus 在 Kubernetes 混沌注入方面脱颖而出（took the lead）。

这个结论可以从 Litmus 的设计上找到依据。README 明确指出，Litmus 以云原生方式落地混沌工程：平台以 Kubernetes 自定义资源（CR）表达混沌意图与稳态假设，核心资源包括：

• ChaosExperiment：描述某个故障的配置参数，是"可安装的模板"，标明执行故障所需的权限与默认参数；
• ChaosEngine：把应用工作负载/服务/节点等目标与某个 ChaosExperiment 关联起来，并可配置探针（probes）做稳态校验；Chaos-Operator 监听并调和它，触发实验执行；
• ChaosResult：保存实验运行结果（验证约束是否通过、故障回滚状态与 verdict），Chaos-exporter 读取后暴露为 Prometheus 指标，对自动化运行尤其有价值。

对咨询团队而言，这套"CR 定义意图 → Operator 调和执行 → Result 暴露结果"的模型意味着：混沌注入可以被当作声明式的、可审计的、可编程的流水线环节，而不是一次性的人工操作——这正是一个服务商团队最看重的可复制性。

如何使用 Litmus：ChaosHub 实验 + CI 注入 + 爆炸半径递进

WeScale 的使用方式可以归纳为三条主线：从 Litmus Chaos Hub 取用现成实验、通过客户各自的 CI 工具注入混沌、按"从 Pod 到集群"的顺序控制爆炸半径；同时规划用 Litmus Portal 统一管理混沌工作流。

3.1 从 ChaosHub 取用实验：社区实验市场的机制

WeScale 明确提到"使用 litmus chaos hub 中可用的 litmus 实验"。ChaosHub 是 Litmus 社区托管 ChaosExperiment 的中心（仓库 README 将hub.litmuschaos.io描述为"应用开发者或厂商分享混沌实验、供用户提升生产韧性"的中央枢纽）。

当前仓库中，ChaosHub 由 chaoscenter 的 GraphQL 服务管理，其 schema 定义在 chaoshub.graphqls，关键结构包括：

• HubType：GIT（git 仓库克隆型 Hub）与REMOTE（远程 Hub）两种类型；
• AuthType：BASIC、NONE、SSH、TOKEN四种认证方式，对应token、userName、password、sshPrivateKey等字段——说明 ChaosHub 不止支持公开仓库，也能挂载需要认证的私有 Git 仓库；
• 实验读取链路：listChaosFaults列出某 Hub 的图表（Chart）与故障（Fault），getChaosFault返回某实验的fault（fault.yaml）、engine（engine.yaml）与csv（chartserviceversion.yaml）三件套；
• Hub 生命周期管理：addChaosHub（含 git clone 操作）、syncChaosHub（从 Git 仓库同步变更）、updateChaosHub、deleteChaosHub等 Mutation。

对应地，chaoshub.resolvers.go 中每个解析器都先经authorization.ValidateRole做 RBAC 角色校验，再调用chaosHubService的对应方法，例如AddChaosHub、SyncChaosHub、ListChaosFaults、GetChaosFault。从源码结构可以推断：ChaosHub 的取用过程对用户是"点选即用"，对底层则是"克隆/同步 Git 仓库 + 解析 Chart 元数据 + 按需取回 YAML"的服务化流程。对 WeScale 这类要面向多个客户快速复制混沌能力的中介团队，这套机制大大降低了"实验从哪来、怎么维护版本"的管理成本。

3.2 注入 CI：实验失败即流水线失败

WeScale 表示"通过我们的 CI（取决于客户使用的 CI 工具）把实验注入应用"。仓库的 CI 集成官方 FAQ 位于 mkdocs/docs/experiments/faq/ci-cd.md，其中明确记载了 Litmus 与主流 CI 工具的集成方式：

• GitHub Actions（借助litmuschaosactions）；
• GitLab（remote templates）；
• Keptn；
• Spinnaker templates。

该 FAQ 给出的关键实践原则是："CI 中实验失败应必然导致流水线失败"——混沌注入成为持续验证（Continuous Chaos）的一环，帮助在开发阶段自动暴露应用故障路径。同时也提醒：若对无流量、无依赖交互的微服务 Pod 只做简单的 pod-delete 或 cpu-hog，洞察有限；实验设计要贴近真实运行条件才有价值。对服务商团队，这等于提供了一套"如何把混沌工程嵌进客户既有 DevOps 流水线"的现成方法论，且不要求客户更换 CI 平台——WeScale 文档中"取决于客户使用的 CI 工具"的说法与此完全吻合。

3.3 爆炸半径：从 Pod 到集群的递进式注入

WeScale 描述其注入策略为"通过把爆炸半径（blast radius）从 Pod 扩大到集群来执行混沌注入"。这一做法在仓库的实验分类体系中有清晰的映射。查看 mkdocs/docs/experiments/categories/contents.md，Litmus 实验被组织为：

• Kubernetes 实验（Generic）：
  • Pod Chaos：container-kill、disk-fill、pod-delete、pod-cpu-hog、pod-memory-hog、pod-network-loss、pod-network-latency、pod-http-* 等——故障作用域局限于单个应用容器/Pod；
  • Node Chaos：docker-service-kill、kubelet-service-kill、node-drain、node-cpu-hog、node-memory-hog、node-restart、node-taint 等——故障作用域上升到节点；
• 应用混沌：Spring Boot App Kill、CPU/Memory Stress、Latency、Exceptions 等带前置条件与预期结果的业务级故障；
• 负载混沌：k6 Load Generator；
• 云基础设施：AWS（EC2 Stop、EBS Loss、SSM Chaos）、GCP（VM 停止/磁盘分离）、Azure（实例停止/磁盘分离）、VMware（VM Poweroff）——故障作用域扩展到集群之外的云资源。

FAQ（mkdocs/docs/experiments/faq/experiments.md）进一步点明：基础设施级实验"通常具有更大的爆炸半径，影响不止一个应用"，并建议在应用部署规范不可随意修改或实验本身爆炸半径较大时，通过ChaosEngine.spec.annotationCheck: false关闭注解检查。WeScale 的"Pod → 集群"递进策略，正是利用这套分类在影响范围可控的前提下逐级验证：先验证单个副本的恢复（如 pod-delete 后 Deployment 的自愈），再验证节点层故障（如 node-drain 的调度迁移），最后触及集群依赖的云资源。

3.4 规划中的 Litmus Portal：从实验执行到工作流管理

WeScale 在文档中表示"很快将测试 Litmus Portal 来管理工作流"。仓库中的对应实现是 chaoscenter（即 README 所称的Chaos Control Plane / chaos-center，Web 前端位于 chaoscenter/web），用于"构造、调度并可视化 Litmus 混沌工作流"。

从 chaoscenter/manifests/litmus-installation.yaml 的部署清单可以看到控制面与执行面的组件分工：

• 控制面：litmusportal-server（GraphQL 服务，内含SUBSCRIBER_IMAGE、EVENT_TRACKER_IMAGE、ARGO_WORKFLOW_CONTROLLER_IMAGE等镜像配置，负责工作流编排与代理下发）、litmusportal-frontend（nginx 入口，代理/api/与/auth/）、litmusportal-auth-server（认证服务，清单中可见 OIDC/OAuth 相关配置项）；
• 执行面：chaos-operator（调和 ChaosEngine）、chaos-runner（实验总执行器）、chaos-exporter（导出 Prometheus 指标）、litmusportal-subscriber（订阅控制面指令）与event-tracker（事件驱动的 GitOps 混沌注入）等。

README 中的架构概览图（上文已引用）正是对这一"控制面 + 执行面"分层结构的说明。可以推断，WeScale 若启用 Litmus Portal/ChaosCenter，将把"从 ChaosHub 选实验、编排多步工作流、跨集群下发执行、汇总 ChaosResult"全部收口到一个可视化平台，替代或补充此前在 CI 中逐条注入的方式——这与文档"manage the chaos workflow"的目标一致。

使用 Litmus 的收益

WeScale 归纳了三点收益，均可从仓库得到印证：

1. 让混沌工程变得非常容易：Litmus 被其称为"让混沌工程变得非常简单的开源工具之一"。低门槛体现在：安装 chaos-operator 与实验 CR 后，创建一个 ChaosEngine 把应用与实验关联即可触发执行（见 chaos-resources 文档 中 ChaosEngine/ChaosExperiment/ChaosResult 的规格说明）。
2. 提供实验 Hub：ChaosHub 集中托管社区实验，无需自研故障注入器，3.1 节的 GraphQL 机制就是其实现底座。
3. 无外部依赖即可部署进 Kubernetes 集群：仓库中 chaoscenter/manifests 目录同时提供litmus-getting-started.yaml、litmus-installation.yaml、litmus-portal-crds.yml与litmus-without-resources.yaml等安装清单，后者即面向最小依赖场景的部署形态，契合"部署在客户集群中不引入额外外部依赖"的咨询交付约束。

可复现示例：在 CI 中注入一次 pod-delete 混沌实验

为了让上述思路可直接落地，下面以 WeScale 最典型的场景——在 CI 阶段对应用做一次 Pod 级混沌验证——给出基于仓库文档的可执行示例。完整实验说明与 tunables 表见 pod-delete.md。

4.1 最小 RBAC（实验专用 ServiceAccount）

pod-delete 需要权限：创建/监控实验与辅助 Pod、操作 events、读写litmuschaos.io的 chaosengines/chaosexperiments/chaosresults 等。pod-delete 文档中给出了完整的最小 RBAC 清单（ServiceAccount + Role + RoleBinding），核心规则片段如下（完整版请查阅该文档）：

--- apiVersion: v1 kind: ServiceAccount metadata: name: pod-delete-sa namespace: default labels: name: pod-delete-sa app.kubernetes.io/part-of: litmus --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-delete-sa namespace: default rules: # 创建并监控实验与辅助 Pod - apiGroups: [""] resources: ["pods"] verbs: ["create","delete","get","list","patch","update", "deletecollection"] # 在 chaosengine 与 chaosresult 内对事件做 CRUD - apiGroups: [""] resources: ["events"] verbs: ["create","get","list","patch","update"] # 管理实验 Job（由 chaos-runner Pod 配置与监控） - apiGroups: ["batch"] resources: ["jobs"] verbs: ["create","list","get","delete","deletecollection"] # 混沌工作流中 litmus 混沌资源的创建、状态轮询与删除 - apiGroups: ["litmuschaos.io"] resources: ["chaosengines","chaosexperiments","chaosresults"] verbs: ["create","list","get","patch","update","delete"]

提示：若实验是通过 chaos-center 编排并下发的工作流，通常会使用 agent 预装时部署的litmus-adminRBAC，无需为每个实验单独建 ServiceAccount。

4.2 ChaosEngine：强制删除指定 Pod

以"强制删除 nginx 应用副本"为例，ChaosEngine 清单如下（默认校验要求应用 Pod 在注入前后均处于 Running）：

apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" appinfo: appns: "default" applabel: "app=nginx" appkind: "deployment" chaosServiceAccount: pod-delete-sa experiments: - name: pod-delete spec: components: env: # true 表示强制删除（0s 宽限期）；false 表示优雅删除（默认 30s 终止期） - name: FORCE value: 'true' - name: TOTAL_CHAOS_DURATION value: '60'

4.3 核心 tunables 一览

4.4 结果验证：CI 里如何判定通过/失败

实验执行后，结果写入 ChaosResult 资源，可直接在 CI 步骤中读取 verdict（来自 mkdocs/docs/experiments/faq/experiments.md 的实践指引）：

kubectl describe chaosresult <chaosengine-name>-<chaos-experiment> -n <namespace>

• verdict 为Pass：应用对注入的混沌具备韧性，实验通过；
• verdict 为Fail：应用韧性不足，需要排查部署配置或应用缺陷。

对应 CI 的策略即"失败即流水线失败"。需要停止/中止飞行中的实验时，可将 ChaosEngine 的engineState补丁为stop；重新激活只需再补丁为active：

kubectl patch chaosengine <chaosengine-name> -n <namespace> --type merge --patch '{"spec":{"engineState":"stop"}}' kubectl patch chaosengine <chaosengine-name> -n <namespace> --type merge --patch '{"spec":{"engineState":"active"}}'

结语：咨询团队可复制的混沌工程交付路径

从 WeScale 的采用记录可以看出一条清晰的可复制路径：以 ChaosHub 为实验供给源、以客户既有 CI 为注入通道、以"Pod → 节点 → 云基础设施"的爆炸半径递进控制风险、以 Litmus Portal/ChaosCenter 为未来的集中编排层。对同样面向多客户交付云原生韧性的团队，这条路径的价值在于：实验定义与执行机制全部开源、结果以标准 CR 暴露、部署不依赖外部组件，因而可以低成本嵌入任意客户的 Kubernetes 环境与 DevOps 流水线。若需查阅本案例的原始记录，可访问仓库中的 wescale.md；更多采用者分类与故事索引见 ADOPTERS.md。

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