云原生运维可观测性【免费下载链接】litmusLitmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q项目地址https://gitcode.com/gh_mirrors/li/litmus点击查看免费下载本篇技术指南以 Litmus 仓库中的 KubeCon 2020 NA 演示文档demo/kubecon-demo/2020-NA/Readme.md为骨架完整还原一套从零搭建 Litmus 混沌工程环境 → 用 Argo Workflows 编排故障注入 → 叠加性能压测的可落地方案。读完本文你将掌握 Litmus Operator 与三大 CRDChaosEngine / ChaosExperiment / ChaosResult的部署与验证方法、Argo Workflows 基础设施的安装方式以及如何用一份可参数化的 Argo 工作流在同一套 Nginx 应用上顺序或并行执行混沌实验与 Gatling 性能测试。演示场景总览KubeCon 2020 NA 演示搭建了一套完整的云原生混沌演练流水线其核心思路是故障注入 负载压测 工作流编排三合一目标应用一个 3 副本、以 NodePort 暴露的多实例无状态 Nginx 应用故障注入通过 Litmus 的k8-pod-delete实验删除目标 Pod验证应用在持续被杀掉副本的场景下的自愈与可用性编排引擎Argo Workflows 负责把创建 ChaosEngine → 等待注入 → 删除 ChaosEngine以及Gatling 压测 → 结果聚合 → 上传 S3串成可重放的工作流三种运行模式纯混沌argowf-chaos-admin.yaml、纯性能argowf-perf.yaml、混沌与性能并行argowf-perf-chaos-admin.yaml。演示所需的所有清单文件都随仓库分发路径与作用如下文件作用App/nginx_demo.yaml被测 Nginx 应用Deployment NodePort ServiceChaosExperiment/experiments-k8.yamlk8-pod-delete混沌实验定义ChaosExecution/rbac-chaos-admin.yaml执行混沌实验所需的 RBACchaos-adminChaosExecution/engine-nginx-count-admin.yaml面向 Nginx 应用的 ChaosEngine 实例Argo/argowf-chaos-admin.yaml纯混沌注入的 Argo 工作流Argo/argowf-perf.yaml纯性能压测的 Argo 工作流Argo/argowf-perf-chaos-admin.yaml混沌与性能并行的工作流Argo/rbac-argo-service.yamlArgo 工作流执行时使用的 RBACargowf-svcacc一、安装 Litmus 基础设施Operator、命名空间与三大 CRD演示环境要求先在一个集中命名空间litmus中安装 Litmus Operator后续所有混沌资源都会在该命名空间下创建。1.1 应用 Operator 清单原演示文档通过远程 URL 拉取litmus-operator-v1.9.0.yaml该版本的清单同样保存在仓库中mkdocs/docs/litmus-operator-v1.9.0.yaml可按下述方式之一执行kubectl apply -f mkdocs/docs/litmus-operator-v1.9.0.yaml从 litmus-operator-v1.9.0.yaml 的源码可以看到这份清单依次创建了以下资源理解它们有助于后续排查Namespace: litmus——所有混沌资源Operator、实验、引擎的集中命名空间ServiceAccount: litmus命名空间litmus——Operator 运行身份ClusterRole: litmus与ClusterRoleBinding: litmus——授予 Operator 对jobs / deployments / statefulsets / daemonsets / pods / chaosengines / chaosexperiments / chaosresults等资源的读写与deletecollection权限Deployment: chaos-operator-ce——混沌 Operator 本体镜像litmuschaos/chaos-operator:1.9.0并通过环境变量指定CHAOS_RUNNER_IMAGElitmuschaos/chaos-runner:1.9.0即执行阶段实际拉起混沌 Runner 的镜像与WATCH_NAMESPACE空值表示监听所有命名空间即集群级模式三个CustomResourceDefinitionchaosengines.litmuschaos.io、chaosexperiments.litmuschaos.io、chaosresults.litmuschaos.iogroup 均为litmuschaos.ioscope 均为Namespaced。1.2 验证 Operator 与 CRD应用清单后依次执行三类验证# 验证 ChaosOperator 是否 Running kubectl get pods -n litmus # 预期输出形如 # NAME READY STATUS RESTARTS AGE # chaos-operator-ce-658b7dfc7b-4nw45 1/1 Running 0 11d # 验证 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 资源 kubectl api-resources | grep chaos # 预期输出 # chaosengines litmuschaos.io true ChaosEngine # chaosexperiments litmuschaos.io true ChaosExperiment # chaosresults litmuschaos.io true ChaosResult其中kubectl api-resources输出中的true表示该资源是 Namespaced命名空间级资源。这套Pod 健康 → CRD 注册 → API 资源可见的验证顺序是判断 Litmus 基础环境是否就绪的标准检查项。二、搭建 Argo WorkflowsCRD、Controller、Server 与 CLIArgo 工作流基础设施由 Argo 的 CRD、Workflow Controller、关联 RBAC 与 Argo CLI 组成。以下步骤以标准集群级模式安装即 workflow controller 作用于所有命名空间因此需要确保当前账号具备创建上述资源的权限。2.1 创建命名空间并安装 Argo# 创建 argo 命名空间 kubectl create ns argo # 创建 CRD、workflow controller Deployment 及其关联 RBAC kubectl apply -f install.yaml说明install.yaml为 Argo 官方 stable 分支提供的 cluster-wide 安装清单原演示文档通过远程 URL 拉取。若希望以命名空间级namespace-scoped模式运行 Argo可改用官方对应的 namespace-install.yaml 清单此时 workflow controller 仅作用于指定命名空间权限需求更小。2.2 验证 Argo 资源# 验证 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 资源 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 # 验证 argo-server 与 workflow-controller 都已 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 13h2.3 安装 Argo CLICLI 应安装在持有 kubeconfig 的执行机harness/test 机器上演示使用 v2.8.0 的 linux-amd64 二进制# 从 Argo 官方 release 页下载 v2.8.0 的 linux-amd64 二进制 curl -sLO argo-v2.8.0-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三、部署被测应用多副本 Nginx NodePort Service3.1 创建混沌命名空间并部署应用# 为混沌实验创建专属命名空间 kubectl create ns chaos-ns # 部署多副本无状态 Nginx 应用Service 以 NodePort 暴露 kubectl apply -f demo/kubecon-demo/2020-NA/App/nginx_demo.yaml # 预期输出 # deployment.apps/nginx-demo-app created # service/nginx-demo-app-svc created # 持续观察应用 Pod 状态 kubectl get pods -l appnginx-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应用部署完成后可通过https://node-ip:nodeport访问该服务。3.2 清单要点解析App/nginx_demo.yaml 中有几个与后续混沌演练直接相关的设计litmuschaos.io/chaos: true注解标注该 Deployment 是混沌实验的合法目标。当 ChaosEngine 中annotationCheck开启时Litmus 会校验目标应用是否带此注解3 副本 就绪探针镜像nginxdemos/hello:plain-text暴露 80 端口readinessProbe 以initialDelaySeconds: 1、periodSeconds: 5、timeoutSeconds: 4探测/healthz成功阈值 2、失败阈值 3——这意味着每次只删一个副本时应用整体仍可对外正常服务正好用于观察故障注入期间服务不中断Pod 反亲和requiredDuringSchedulingIgnoredDuringExecution强制同一应用副本尽量分布在不同主机topologyKey: kubernetes.io/hostname避免单点故障影响实验判断NodePort 类型 Service通过nginx-demo-app-svc把 80 端口映射到节点端口供外部压测工具访问。四、注册混沌实验k8-pod-deleteChaosExperiment混沌实验定义用ChaosExperiment描述注入什么故障、如何注入。演示使用k8-pod-delete删除 Deployment / StatefulSet / DaemonSet 所属的某个 Pod清单见 ChaosExperiment/experiments-k8.yaml# 为你的命名空间创建 ChaosExperiment kubectl apply -f demo/kubecon-demo/2020-NA/ChaosExperiment/experiments-k8.yaml # 预期输出 # chaosexperiment.litmuschaos.io/k8-pod-delete created # 验证实验已注册 kubectl get chaosexperiments # 预期输出 # NAME AGE # k8-pod-delete 4s清单核心字段与说明字段取值含义metadata.namek8-pod-delete实验名称供 ChaosEngine 引用metadata.namespacechaos-ns实验所在命名空间spec.definition.scopeNamespaced实验作用范围spec.definition.permissions一组 apiGroups/resources/verbs实验 Job 所需的 Kubernetes 权限包括对pods / deployments / daemonsets / jobs / configmaps / events及chaosengines / chaosexperiments / chaosresults的增删改查以及对nodes的 get/listspec.definition.imagelitmuschaos/chaostoolkit:latest实验运行镜像基于 chaostoolkit 的混沌工具包spec.definition.command/args/bin/bash -c python /app/chaos/chaostest/kubernetes/k8_wrapper.py ; exit 0实验入口spec.definition.env见下表实验参数化环境变量实验环境变量env与作用CHAOSTOOLKIT_IN_POD: true标识实验以 in-pod 模式运行工具随实验 Job 一起注入而非外部独立服务FILE: pod-app-kill-count.json指定故障编排脚本文件名演示包含pod-app-kill-count.json与pod-app-kill-health.json两种前者面向计数验证、后者面向健康检查验证NAME_SPACE: chaos-ns目标应用命名空间LABEL_NAME: nginx-demo-app目标应用选择标签APP_ENDPOINT: localhost应用端点供健康探测使用PERCENTAGE: 50故障注入前等待的秒数注释原文为 Period to wait before injection of chaos in sec即注入前的等待周期REPORT: true/REPORT_ENDPOINT: none是否上传自定义实验报告及上报端点地址。五、执行混沌实验RBAC ChaosEngine5.1 创建执行实验的 RBAC在实验执行前需要为chaos-ns命名空间准备执行账号chaos-adminServiceAccount ClusterRole ClusterRoleBinding见 ChaosExecution/rbac-chaos-admin.yamlkubectl apply -f demo/kubecon-demo/2020-NA/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 授予chaos-admin对jobs / deployments / daemonsets的 create/list/get/patch/delete对pods / configmaps / events / services / chaosengines / chaosexperiments / chaosresults / deployments / jobs的读写以及对nodes的 get/list——恰好覆盖实验 Job 注入故障与上报结果所需的全部动作。5.2 创建 ChaosEngine 触发注入kubectl apply -f demo/kubecon-demo/2020-NA/ChaosExecution/engine-nginx-count-admin.yamlengine-nginx-count-admin.yaml 是实例化实验的关键清单字段解析如下字段取值含义metadata.namek8-nginx-count-cluster引擎名称metadata.namespacechaos-ns引擎所在命名空间spec.appinfo.appnschaos-ns目标应用命名空间spec.appinfo.applabelappnginx-demo-app目标应用标签注释提示可用kubectl get pods --show-labels查看实际标签spec.appinfo.appkinddeployment目标应用资源类型spec.jobCleanUpPolicydelete实验结束后自动清理实验 Jobspec.monitoringfalse本引擎不开启监控注入spec.annotationCheckfalse关闭注解检查此时不强制要求目标应用带litmuschaos.io/chaos注解spec.engineStateactive引擎处于激活状态Operator 将立即执行其中的实验spec.chaosServiceAccountchaos-admin实验 Job 使用的服务账号spec.experiments[0].namek8-pod-delete引用上一步注册的实验同时引擎内联覆盖了实验的环境变量NAME_SPACEchaos-ns、LABEL_NAMEnginx-demo-app、APP_ENDPOINTnginx.xxx.com、FILEpod-app-kill-count.json、REPORTfalse、REPORT_ENDPOINThttps://report.xxx.com、TEST_NAMESPACEchaos-ns实现了同一实验定义、不同目标参数的复用模式——这正是 Litmus 解耦实验与引擎的设计初衷。六、用 Argo 编排混沌工作流把注入混沌 → 等待 → 回滚固化为可重复执行的 Argo 工作流是演示的核心亮点。提交命令argo submit demo/kubecon-demo/2020-NA/Argo/argowf-chaos-admin.yaml --watch若需对工作流参数做运行时覆盖可结合演示附带的 demo.md 中的用法例如argo submit Argo/argowf-chaos-admin.yaml -pappLabelkiam -pappNamespacekube-system -pfileNamepod-app-kill-health.json --watch演示文档注释提到该用法原用于对kube-system命名空间、标签为kiam的应用注入故障。6.1 工作流参数化设计argowf-chaos-admin.yaml 通过arguments.parameters暴露一组可覆盖参数参数默认值含义appNamespacedefault目标应用命名空间appCurrentNamespacechaos-ns引擎实际所在的执行命名空间appLabelnginx-demo-app目标应用标签appEndpointnginx.xxx.com应用端点fileNamepod-app-kill-count.json故障编排脚本文件chaosServiceAccountchaos-admin混沌执行账号reportEndpointhttps://report.xxx.com报告上报端点6.2 模板与执行流程工作流的entrypoint: argowf-chaos模板是一个两步顺序步骤stepsrun-chaos 模板以rawartifact 的方式在/tmp/createChaosEngine.yaml中动态渲染一份 ChaosEngine 清单使用{{workflow.parameters.xxx}}模板变量把上述参数注入appinfo、chaosServiceAccount、experiments[].spec.components.env等字段随后由lachlanevenson/k8s-kubectl容器执行kubectl apply -f /tmp/createChaosEngine.yaml -n {{workflow.parameters.appCurrentNamespace}}并 sleep 20 秒等待故障注入生效revert-chaos 模板同样以 raw artifact 渲染一份删除用 ChaosEnginesleep 20 秒后执行kubectl delete -f /tmp/deleteChaosEngine.yaml -n ...完成混沌回滚。工作流的serviceAccountName: argowf-svcacc对应 Argo/rbac-argo-service.yaml 中的同名 ServiceAccount。该 RBAC 授予argowf-svcacc对workflows / workflowtemplates / cronworkflows的读写、对pods / pods/log的 get/watch、对poddisruptionbudgets的增删查以及对chaosengines / chaosexperiments / chaosresults的完整读写与deletecollection——保证 Argo 能创建/删除 ChaosEngine而混沌实验本身再以chaos-admin身份执行。这种编排账号与执行账号分离的权限模型值得在正式环境中沿用。七、性能压测工作流Gatling S3 结果归集7.1 纯性能压测工作流提交命令argo submit demo/kubecon-demo/2020-NA/Argo/argowf-perf.yaml --watchargowf-perf.yaml 的参数包括limit并发压测 Pod 数上限、peakTPS、rampupTime、steadyStateTime、baseurl默认https://nginx.xxx.com、query默认/health/full、simulationClassGatling 模拟类默认Echo.EchoSimulation、appTestImg默认distroproj/gatling:latest以及 S3 相关的s3BucketName需要读者自行在 AWS 账号中创建结果存储桶。工作流模板链路为perf-infra → pdbcreate → run-test(带 withSequence.countlimit 的并行压测) → list(聚合)run-test以distroproj/gatling:latest镜像执行mvn gatling:test将peakTPS / rampupTime / steadyStateTime / baseurl / query传入 Gatling 模拟压测结束后把/tmp与simulation.log打包为 artifact 上传至 S3endpoints3.amazonaws.com、regionus-west-2、bucket 由参数指定key 按results/namespace/uniqueName/...组织list聚合下载所有.tgz模拟结果解包后用gatling.sh -ro生成聚合报告最终以archive: none方式将/perf-out目录上传 S3。7.2 混沌 性能并行工作流演示高潮提交命令argo submit demo/kubecon-demo/2020-NA/Argo/argowf-perf-chaos-admin.yaml --watchargowf-perf-chaos-admin.yaml 把前两类工作流合并entrypoint: argowf-perf-chaos下先创建 PDBminavailable: 100%随后在同一个步骤组中并行执行perf-exec内部再拆分为 run-test 与 list 两个串行步骤与chaos-exec内部拆分为 run-chaos 与 revert-chaos 两个串行步骤。即压测进行的同时k8-pod-delete混沌持续删除目标 Pod用于观测应用在故障注入压力下的性能表现。相比纯压测工作流此清单额外携带reportEndpoint / appNamespace / appCurrentNamespace / appLabel / appEndpoint / fileName默认pod-app-kill-health.json即基于健康检查验证的故障脚本与chaosServiceAccount等混沌参数。两套工作流还声明了以下 Argo 生命周期策略值得在生产中复用poddisruptionbudget.minavailable: 100%压测 Pod 不允许被 PDB 中断activeDeadlineSeconds: 86400工作流最长执行 24 小时ttlStrategy.secondsAfterCompletion: 3600完成后保留 1 小时再回收podGC.strategy: OnPodCompletionPod 一旦完成立即清理。八、演示速查卡随目录附带的 demo.md 是一份精简速查清单适合在活动现场快速执行# 查看当前 Pod kubectl get pods -w # 注册混沌实验 kubectl apply -f ChaosExperiment/experiments-k8.yaml # 验证实验 kubectl get chaosexperiments # 创建混沌 RBAC kubectl apply -f ChaosExecution/rbac-chaos-admin.yaml # 执行混沌 kubectl apply -f ChaosExecution/engine-nginx-count-admin.yaml # 通过 Argo 提交混沌可覆盖目标应用参数 argo submit Argo/argowf-chaos-admin.yaml -pappLabelkiam -pappNamespacekube-system -pfileNamepod-app-kill-health.json --watch # 通过 Argo 提交压测limit 控制并发压测 Pod 数 argo submit Argo/argowf-perf-chaos-admin.yaml -plimit2 --watch九、小结与延伸阅读回顾整套演示它完整走通了 Litmus 混沌工程的经典闭环装环境Operator 三大 CRD→ 备应用多副本 Nginx NodePort→ 定实验ChaosExperiment→ 配权限chaos-admin RBAC→ 建引擎ChaosEngine→ 编排注入Argo 工作流→ 叠加压测Gatling S3 归集并示范了实验定义复用 引擎参数化 工作流模板化三层抽象这正是把混沌演练沉淀为团队常态化能力的关键。如需继续深入可在本仓库中查阅以下素材Litmus Operator v1.9.0 完整清单含 Operator 环境变量、ClusterRole 权限与三大 CRD 的 OpenAPI 校验定义demo/kubecon-demo/2020-NA/本演示的全部清单源文件demo/boutique-chaos-on-load/boutique-chaos-on-load.md另一套负载生成 CPU 混沌组合场景可对照学习故障场景的设计思路CHAOS_EXPERIMENT_MATURITY.md实验成熟度模型用于评估实验的可持续性。版本与适用前提说明本文命令与清单基于 Litmus v1.9.0 与 Argo v2.8.0KubeCon 2020 NA 演示当时的版本其中rbac.authorization.k8s.io/v1beta1、apiextensions.k8s.io/v1beta1等 API 版本在较新 Kubernetes 上已被替代正式环境请按集群版本适配。文中xxx.com类地址为演示占位符需替换为你的实际端点S3 压测结果上传需要预先创建存储桶并配置相应权限。赞分享云原生运维可观测性【免费下载链接】litmusLitmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q项目地址https://gitcode.com/gh_mirrors/li/litmus点击查看免费下载相关推荐终极DevSecOps混沌工程实战指南从Chaos Mesh到Litmus的完整演练终极DevSecOps混沌工程实战指南从Chaos Mesh到Litmus的完整演练 在当今快速迭代的DevSecOps环境中保障系统稳定性和安全性变得愈发网络安全应用安全供应链安全云原生Floci实战教程10分钟掌握Docker Compose部署AWS本地环境Floci实战教程10分钟掌握Docker Compose部署AWS本地环境 想要在本地快速搭建一个完整的AWS开发环境吗Floci就是你一直在寻找的终极解终极混沌工程实践指南从Chaos Monkey到Litmus的完整工具使用教程终极混沌工程实践指南从Chaos Monkey到Litmus的完整工具使用教程 在现代DevOps实践中确保系统在各种故障条件下的稳定性至关重要。混沌工程作云原生CI/CD运维上一篇如何用PanoHead从单张照片创建个性化3D头像完整教程下一篇uni-app x UTS 内置对象 Set 完全指南去重、增删查改与跨端实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考