Litmus + Argo Workflows 混沌工程实战：KubeCon NA 2020 演示全流程拆解

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

本篇技术指南基于当前仓库中的 KubeCon NA 2020 演示文档（及配套的 完整操作指南 与全部 YAML 资源），完整复现"在 Kubernetes 上以云原生方式开展混沌工程"的端到端流程：从安装 Litmus Chaos Operator、部署 Argo Workflows 编排引擎，到注入 pod 删除故障、并行叠加 Gatling 性能压测。读者阅读完本文后，将能够独立搭建一套"混沌注入 + 工作流编排 + 性能测试"的实验环境，并掌握 ChaosExperiment、ChaosEngine、Argo Workflow 三个核心资源之间的协作关系与参数化调用方法。

说明：该演示对应 Litmus v1.9.0 时期的资源形态（API 版本litmuschaos.io/v1alpha1），并搭配 Argo v2.8.0 使用，文中命令与清单以当前仓库实际内容为准。

演示场景总览

本次演示以一套 3 副本的 nginx 无状态应用为被测对象（AUT），围绕它构建出三条完整链路：

1. 直接执行混沌：通过 ChaosEngine 直接对应用注入k8-pod-delete故障，验证 deployment 副本可用性与服务连续性；
2. Argo 编排混沌：把"创建 ChaosEngine → 等待 → 删除 ChaosEngine"封装成 Argo Workflow 模板，实现混沌注入的自动化编排与回收；
3. 混沌叠加性能压测：在 Argo Workflow 中并行运行 Gatling 压测步骤与混沌注入步骤，考察应用在真实流量压力下的弹性表现，并将压测结果归档至 S3。

演示所需的全部资源文件均位于 demo/kubecon-demo/2020-NA 目录下，目录结构如下：

• App/nginx_demo.yaml：被测的 3 副本 nginx Deployment + NodePort Service；
• ChaosExperiment/experiments-k8.yaml：k8-pod-delete混沌实验定义；
• ChaosExecution/rbac-chaos-admin.yaml：执行混沌所需的 ServiceAccount / ClusterRole / ClusterRoleBinding；
• ChaosExecution/engine-nginx-count-admin.yaml：直接执行的 ChaosEngine 实例；
• Argo/argowf-chaos-admin.yaml：纯混沌编排 Workflow；
• Argo/argowf-perf.yaml：纯性能压测 Workflow；
• Argo/argowf-perf-chaos-admin.yaml：混沌与压测并行 Workflow；
• Argo/rbac-argo-service.yaml：Workflow 运行所需的 RBAC。

安装 Litmus Chaos Operator

部署 Operator 清单

先为混沌资源准备集中式命名空间并安装 Operator。演示中的安装步骤为（对应 Readme.md 中的 Getting Started 一节，使用的是仓库中同期发布的litmus-operator-v1.9.0.yaml，该清单在仓库 mkdocs/docs 目录下亦有归档版本）：

kubectl apply -f <litmus-operator-v1.9.0.yaml 路径>

所有混沌资源都会被创建在集中的litmus命名空间下。安装完成后，验证 ChaosOperator 是否正常运行：

kubectl get pods -n litmus NAME READY STATUS RESTARTS AGE chaos-operator-ce-658b7dfc7b-4nw45 1/1 Running 0 11d

验证 CRD 与 API 资源

Operator 就绪后，确认三个核心 CRD 已注册：

kubectl get crds | grep chaos chaosengines.litmuschaos.io 2020-06-11T17:59:33Z chaosexperiments.litmuschaos.io 2020-06-11T17:59:33Z chaosresults.litmuschaos.io 2020-06-11T17:59:34Z

同时检查对应的 api-resources，三个资源均为 namespaced 作用域：

kubectl api-resources | grep chaos chaosengines litmuschaos.io true ChaosEngine chaosexperiments litmuschaos.io true ChaosExperiment chaosresults litmuschaos.io true ChaosResult

三个资源的分工如下：

• ChaosExperiment：描述"能做什么故障"，定义实验镜像、作用域、权限与默认环境变量，即实验的"类型定义"；
• ChaosEngine：描述"对谁注入、注入什么、如何回收"，通过appinfo指定目标应用，通过experiments引用具体实验；
• ChaosResult：记录一次混沌执行的结果状态，供后续查询与监控消费。

部署 Argo Workflows 基础设施

Argo 负责将混沌注入与性能压测编排成多步骤工作流。演示以集群级模式安装（workflow-controller 作用于全部命名空间），需要确保当前账号具备创建相关资源的权限。

# 创建 argo 命名空间 kubectl create ns argo # 创建 Workflow CRD、controller deployment 及配套 RBAC kubectl apply -f <argo install.yaml 路径>

安装后验证 CRD：

kubectl get crds | grep argo clusterworkflowtemplates.argoproj.io 2020-05-14T04:57:16Z cronworkflows.argoproj.io 2020-05-14T04:57:18Z workflows.argoproj.io 2020-05-14T04:57:20Z workflowtemplates.argoproj.io 2020-05-14T04:57:21Z

验证 api-resources：

kubectl api-resources | grep argo clusterworkflowtemplates clusterwftmpl,cwft argoproj.io false ClusterWorkflowTemplate cronworkflows cwf,cronwf argoproj.io true CronWorkflow workflows wf argoproj.io true Workflow workflowtemplates wftmpl argoproj.io true WorkflowTemplate

验证 controller 与 server 两个 Pod 均处于 Running：

kubectl get pods -n argo NAME READY STATUS RESTARTS AGE argo-server-78b774dd56-j8xwx 1/1 Running 0 13h workflow-controller-589bf468d7-bwjtr 1/1 Running 0 13h

最后在持有 kubeconfig 的执行机上安装 Argo CLI（演示环境使用 v2.8.0 的argo-linux-amd64二进制）：

curl -sLO <argo v2.8.0 的 argo-linux-amd64 下载地址> chmod +x argo-linux-amd64 mv ./argo-linux-amd64 /usr/local/bin/argo argo version # argo: v2.8.0 # BuildDate: 2020-05-11T22:55:16Z # GitCommit: 8f696174746ed01b9bf1941ad03da62d312df641 # GitTreeState: clean # GitTag: v2.8.0 # GoVersion: go1.13.4 # Compiler: gc # Platform: linux/amd64

若希望 Argo 以命名空间隔离方式运行，可按 Argo 官方 namespace-install 清单安装，限制 workflow 仅作用于指定命名空间。

部署被测应用：3 副本 nginx

为混沌实验单独创建命名空间并部署应用：

kubectl create ns chaos-ns kubectl apply -f App/nginx_demo.yaml

nginx_demo.yaml 中值得注意的设计点：

1. 混沌开关注解：Deployment 元数据携带litmuschaos.io/chaos: "true"注解。当 ChaosEngine 将annotationCheck设为true时，只有带该注解的应用才会被纳入混沌范围，起到"应用主动报名参与混沌"的保护作用；
2. 反亲和性调度：通过podAntiAffinity的requiredDuringSchedulingIgnoredDuringExecution规则按app=nginx-demo-app标签强制将 3 个副本分散到不同主机（topologyKey: kubernetes.io/hostname），确保故障注入时不会因同主机调度而放大影响；同时用preferredDuringSchedulingIgnoredDuringExecution优先跨可用区（failure-domain.beta.kubernetes.io/zone）分布；
3. 就绪探针：readinessProbe 每 5 秒探测/healthz（HTTP 80），用于评估故障期间服务的可用性波动；
4. 对外暴露：NodePort 类型 Service 将 80 端口映射到集群节点端口，可通过https://<node-ip>:<nodeport>访问。

部署完成后可观察 3 个副本全部进入 Running：

kubectl get pods -l app=nginx-demo-app -w NAME READY STATUS RESTARTS AGE nginx-demo-app-68c58bb7d7-fg2bc 1/1 Running 0 94s nginx-demo-app-68c58bb7d7-jfrrr 1/1 Running 0 94s nginx-demo-app-68c58bb7d7-s98wz 1/1 Running 0 94s

注册混沌实验：k8-pod-delete

在chaos-ns命名空间注册混沌实验（对应 demo.md 中的 Chaos Experiment 步骤）：

kubectl apply -f ChaosExperiment/experiments-k8.yaml kubectl get chaosexperiments NAME AGE k8-pod-delete 4s

experiments-k8.yaml 完整展示了 Litmus 混沌实验的定义结构：

实验级环境变量说明：

• CHAOSTOOLKIT_IN_POD: 'true'：标识在 Pod 内运行 chaostoolkit；
• FILE: 'pod-app-kill-count.json'：chaostoolkit 使用的故障场景配置文件名称（演示同时会使用pod-app-kill-health.json变体）；
• NAME_SPACE: 'chaos-ns'：目标应用所在命名空间；
• LABEL_NAME: 'nginx-demo-app'：通过该标签选择目标 Pod；
• APP_ENDPOINT: 'localhost'：被测应用端点；
• PERCENTAGE: '50'：故障注入的比例/周期参数；
• REPORT: 'true'与REPORT_ENDPOINT: 'none'：自定义报告上传开关与端点（默认关闭）。

创建混沌执行 RBAC

执行混沌前需为实验运行创建独立的服务账号与权限绑定。演示使用 rbac-chaos-admin.yaml，其授权模型如下：

kubectl apply -f ChaosExecution/rbac-chaos-admin.yaml serviceaccount/chaos-admin created clusterrole.rbac.authorization.k8s.io/chaos-admin configured clusterrolebinding.rbac.authorization.k8s.io/chaos-admin configured

该 RBAC 包含三部分：

• ServiceAccountchaos-admin（命名空间chaos-ns）：混沌实验 job 以该账号身份运行；
• ClusterRolechaos-admin：授予对jobs、deployments、daemonsets的create/list/get/patch/delete权限；对pods、configmaps、events、services及 litmus 三件套（chaosengines、chaosexperiments、chaosresults）的增删改查权限；对nodes的get/list权限；
• ClusterRoleBinding：将上述 ClusterRole 绑定到chaos-ns下的chaos-admin账号。

通过 ChaosEngine 直接注入故障

执行混沌的核心资源是 ChaosEngine。演示清单 engine-nginx-count-admin.yaml 如下：

kubectl apply -f ChaosExecution/engine-nginx-count-admin.yaml

该 ChaosEngine 各字段的实战含义：

ChaosEngine 还会以experiments[].spec.components.env覆盖或补充实验级参数，本例向k8-pod-delete传入：

• NAME_SPACE=chaos-ns、LABEL_NAME=nginx-demo-app：锁定目标 Pod 范围；
• APP_ENDPOINT=nginx.xxx.com：健康检查端点（占位地址，需按实际环境替换）；
• FILE=pod-app-kill-count.json：指定本次注入采用的 chaostoolkit 场景文件；
• REPORT=false、REPORT_ENDPOINT=https://report.xxx.com：本用例关闭报告上传；
• TEST_NAMESPACE=chaos-ns：指定测试命名空间。

结合仓库中 pod-delete 实验文档 可知，这类 Pod 删除类实验的典型可调参数还包括TOTAL_CHAOS_DURATION（混沌持续时间，默认 15 秒）、CHAOS_INTERVAL（两次删除间隔，默认 5 秒）、FORCE（强制/优雅删除，默认true即 0 秒宽限期）、PODS_AFFECTED_PERC（受影响副本百分比）、SEQUENCE（serial/parallel）等，可用于扩展本演示的故障强度。

用 Argo Workflow 编排混沌注入

将"创建 ChaosEngine → 等待注入 → 删除 ChaosEngine"封装成 Workflow，即可实现故障注入的自动化编排。清单见 argowf-chaos-admin.yaml，提交命令：

argo submit Argo/argowf-chaos-admin.yaml --watch

Workflow 参数化设计

Workflow 通过arguments.parameters暴露一组可覆盖参数（演示现场用-p覆盖，例如-pappLabel=kiam -pappNamespace=kube-system -pfileName=pod-app-kill-health.json即可把故障目标切换到 kube-system 命名空间下的 kiam 组件）：

步骤模板解析

Workflow 入口argowf-chaos采用顺序 steps 编排：

1. run-chaos步骤：以rawartifact 内联生成 ChaosEngine YAML（将上述参数通过{{workflow.parameters.*}}模板变量注入到appinfo、chaosServiceAccount、experiments[].components.env中），再使用lachlanevenson/k8s-kubectl镜像执行kubectl apply -f /tmp/createChaosEngine.yaml -n <appCurrentNamespace>，随后sleep 20等待注入生效；
2. revert-chaos步骤：同样内联生成一份用于回收的 ChaosEngine YAML，先sleep 20再执行kubectl delete -f /tmp/deleteChaosEngine.yaml，实现混沌注入后的清理与故障恢复。

这种"apply 内联清单 + sleep + delete"的写法，使故障注入的持续时间、目标选择完全由 Workflow 参数驱动，同一份模板可以复用于不同应用、不同命名空间。

纯性能压测 Workflow：Gatling + S3

演示还提供独立的性能压测编排 argowf-perf.yaml，用于测量应用在持续压力下的并发上限。提交方式：

argo submit Argo/argowf-perf.yaml --watch

Workflow 顶层策略

该 Workflow 设置了若干压测工程实践：

• poddisruptionbudget.minavailable: 100%：通过 Pod 中断预算约束压测任务可用性；
• activeDeadlineSeconds: 86400：整体执行上限 1 天；
• ttlStrategy.secondsAfterCompletion: 3600：完成后保留 1 小时供排查；
• podGC.strategy: OnPodCompletion：任务 Pod 一旦完成立即回收。

压测参数

压测核心参数同样通过arguments.parameters暴露：

• limit：并发压测轮数（演示默认 1，可借-plimit=N提升并发度）；
• peakTPS、rampupTime、steadyStateTime：Gatling 压测的峰值吞吐、爬坡时间与稳态时长；
• baseurl、query：被测地址与路径（默认https://nginx.xxx.com的/health/full）；
• appTestImg：distroproj/gatling:latest，Gatling 测试镜像；
• awscliGatmergeImg：结果聚合镜像（distroproj/gatling-merge）；
• simulationClass：Echo.EchoSimulation，Gatling 仿真类名；
• s3BucketName：结果归档桶（需在 AWS 账号中预先创建）。

执行与结果链路

1. run-test模板：以withSequence按limit次数串行执行；容器内运行mvn gatling:test，将gatling_results复制到/tmp，并将simulation.log重命名（附加时间戳与随机后缀）后放入/tmp/simulations；随后把result与simulation两个 artifact 上传至 S3（endpoint: s3.amazonaws.com、region: us-west-2，key 中包含命名空间、唯一名与 Pod 名）；
2. list（Aggregation）模板：拉取全部.tgz结果，解压后用gatling.sh -ro合并报告，去除冗余.log后生成最终结果目录并回传 S3；
3. s3access模板：演示最后通过aws s3 ls/aws s3 cp校验与迁移结果对象。

需要说明的是，上传 S3 依赖 Pod 注入的 AWS IAM 角色注解（iam.amazonaws.com/role: "k8s-<pfiNamespace>"），使用前需为集群配置对应的 IAM Roles for Service Accounts 能力。

混沌 + 性能并行 Workflow

演示的压轴场景是将前两者合并：在压测进行的同时并行注入混沌，检验应用在"有流量压力 + 有故障"双重条件下是否仍能满足 SLO。清单为 argowf-perf-chaos-admin.yaml，提交命令：

argo submit Argo/argowf-perf-chaos-admin.yaml -plimit=2 --watch

其编排策略（模板argowf-perf-chaos）与纯压测版的关键差异：

• 首步先执行pdbcreate（简短占位，保证 PodDisruptionBudget 相关就绪）；
• 随后并行执行perf-exec与chaos-exec两个分支：
  • perf-exec：内含run-test（按limit串行压测）与list（结果聚合）；
  • chaos-exec：内含run-chaos与revert-chaos（沿用 argowf-chaos 的 apply/delete 混沌注入模板）；
• 参数集合为纯压测版与纯混沌版参数的并集，因此-plimit=2表示同时发起两轮压测与一轮混沌注入，二者并行运行。

该 Workflow 还包含poddisruptionbudget、podGC、ttlStrategy等顶层策略，以及向 S3 归档最终报告的完整链路，可用于量化"故障注入期间峰值 TPS 与错误率的变化"。

Argo Workflow 运行所需 RBAC

Workflow 提交后，由 controller 在chaos-ns命名空间调度任务 Pod，需要配套的权限。清单 rbac-argo-service.yaml 定义了：

• Roleargowf-role：授予对pods及pods/log的查看与 patch 权限；对workflow/workflows（argoproj.io）的增删改查；对poddisruptionbudgets（policy）的管理；以及对chaosengines、chaosexperiments、chaosresults的完整生命周期权限；
• ServiceAccountargowf-svcacc：Workflow 清单中serviceAccountName即引用它；
• RoleBinding：将 Role 绑定到该 ServiceAccount，限定于chaos-ns命名空间内生效。

现场速查命令（demo.md 精要）

演示现场文档 demo.md 给出了可直接照做的命令序列，与上文各节一一对应：

# 1. 观察目标应用当前状态（配合 -w 实时跟踪副本变化） kubectl get pods -w # 2. 注册混沌实验 kubectl apply -f ChaosExperiment/experiments-k8.yaml # 3. 验证实验已就绪 kubectl get chaosexperiments # 4. 创建混沌执行 RBAC kubectl apply -f ChaosExecution/rbac-chaos-admin.yaml # 5. 直接执行混沌（创建 ChaosEngine） kubectl apply -f ChaosExecution/engine-nginx-count-admin.yaml # 6. 通过 Argo 向 kube-system 命名空间的 kiam 组件注入故障 # 使用 -p 覆盖 appLabel/appNamespace/fileName 三个参数 argo submit Argo/argowf-chaos-admin.yaml -pappLabel=kiam -pappNamespace=kube-system -pfileName=pod-app-kill-health.json --watch # 7. 通过 Argo 对 nginx 应用执行压测（limit 控制并发压测轮数） argo submit Argo/argowf-perf-chaos-admin.yaml -plimit=2 --watch

其中第 6 步演示了 Workflow 参数化的价值：pod-app-kill-health.json是面向健康检查场景的 chaostoolkit 故障配置文件（与默认的pod-app-kill-count.json相对），配合-pappNamespace=kube-system即可在不对模板做任何修改的前提下，把混沌目标从 nginx 切换到集群关键组件 kiam，验证系统组件在故障下的韧性。

小结与适用前提

本演示完整覆盖了"混沌实验定义 → 权限隔离 → 引擎触发 → 工作流编排 → 压测叠加 → 结果归档"的整条链路，其核心方法论可概括为三点：

1. 资源分层：ChaosExperiment（故障类型）与 ChaosEngine（注入对象）分离，使故障定义可复用、注入对象可灵活切换；
2. 权限最小化：chaos-admin与argowf-svcacc两个服务账号分别承载混沌执行与工作流调度权限，并通过 namespaced Role 收敛范围；
3. 模板参数化：Argo Workflow 用{{workflow.parameters.*}}驱动 ChaosEngine 内联清单，使同一模板可对任意命名空间、任意标签的应用实施故障注入。

需要注意的适用前提：本演示资源基于 Litmus v1.9.0 时期 API（litmuschaos.io/v1alpha1）与 Argo v2.8.0 CLI，文中诸如nginx.xxx.com、report.xxx.com、perf-results-000000000等均为占位地址，实际演练时须替换为真实环境值；S3 归档链路依赖 AWS IAM Roles for Service Accounts 配置。如需在全新环境中复现，可参考仓库 mkdocs/docs 下的实验文档体系（如 pod-delete 实验详解 与 ChaosEngine 概念说明）获得更完整的参数与调优指引。

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