★ FEATURED ARTICLE 云原生运维可观测性【免费下载链接】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点击查看免费下载本文以 OpenEBS 官方采纳案例见 adopters/organizations/openebs.md为主线拆解一个 Kubernetes 原生存储项目如何将 LitmusChaos 嵌入 E2E 测试流水线与 Soak浸泡测试环境从而验证存储系统及其底层 Kubernetes 骨架的韧性。读完本文你将掌握 OpenEBS 引入混沌工程的完整动机、GitLab CI 集成方式、ChaosEngine/ChaosScheduler 的具体配置方法以及如何在多平台 Kubernetes 集群上复现这套功能测试 混沌注入的验证体系。OpenEBS 简介Kubernetes 世界里最活跃的容器附加存储项目OpenEBS 是一个完全 Kubernetes 原生的 Container Attached Storage容器附加存储项目其核心理念是让 DevOps 团队能够为每个工作负载定义独立的存储策略而不是为整个集群绑定一种统一存储方案。它提供了多种存储引擎用户可以根据实际存储需求进行选择Jiva轻量级、基于用户空间副本的存储引擎适用于对性能要求不苛刻、强调简单与可移植性的场景cStor面向生产环境的控制器型引擎具备数据保护与快照能力适合有状态工作负载LocalPV利用节点本地磁盘提供高性能本地持久化卷适合追求极低时延的场景。由于存储系统承担着数据的持久化与高可用职责其韧性Resiliency水平直接决定了上层有状态应用的可靠性这正是 OpenEBS 团队最终走向混沌工程的根本原因。为什么 OpenEBS 要使用 LitmusChaos功能测试之外的韧性盲区在 OpenEBS 的 E2E 测试实践中团队意识到一个关键问题仅靠功能测试functional testing不足以确保系统的韧性。传统功能测试验证的是系统在正常情况下是否按预期工作却无法回答当节点、Pod、kubelet 或存储控制器异常时系统能否自愈并继续对外提供服务。因此 OpenEBS 团队决定在 E2E 测试套件中引入混沌工程实践以验证系统的韧性。OpenEBS 的混沌注入目标分为两个层次从源码文档结构看这与 Litmus 实验分类体系mkdocs/docs/experiments/categories/contents.md中的两个大类完全对应OpenEBS 组件自身即存储控制器、副本 Pod 等存储数据面组件底层 Kubernetes 组件即构成容器基础设施骨架的 Pod、节点、kubelet、网络与存储资源等。Litmus 恰好为上述两类组件都提供了开箱即用的混沌图表Chaos Charts。据该采纳文档所述Litmus 为 OpenEBS 维护了独立的混沌图表分类OpenEBS chaos category并且该分类持续演进同时 OpenEBS 还大量使用了 Kubernetes 通用generic混沌图表。这种专属图表 通用图表的组合让存储团队既能针对存储语义做定制化故障注入又能覆盖通用基础设施故障。OpenEBS 如何使用 LitmusChaosGitLab CI 流水线中的持续混沌将混沌图表嵌入 E2E 流水线OpenEBS 的 E2E 测试以GitLab 作为 CI 平台。Litmus 提供的 [OpenEBS 混沌图表]与 [Kubernetes generic 混沌图表]被直接嵌入 E2E 流水线中执行随每一次代码变更与发布流程自动运行。关键信息点多平台并行验证OpenEBS E2E 测试会在多种 Kubernetes 发行版上执行包括 OpenShift、D2IQ Konvoy、Rancher 以及原生native平台。Litmus 的混沌图表在这些平台上全部可用从而保证 OpenEBS 系统在不同 Kubernetes 生态下的韧性一致。结果可视化测试结果通过名为 openebs.ci 的 UI 门户统一呈现方便团队追踪每一次混沌注入后的系统表现。仓库中的 CI/CD 集成 FAQ 提供了与 OpenEBS 实践完全同构的落地方式佐证Litmus 已与 GitLab通过 remote templates、GitHub Actions、Keptn、Spinnaker 等 CI 工具集成可以在 CI 阶段注入混沌实现持续混沌Continuous Chaos从而在开发阶段就自动暴露应用故障。该文档还特别指出Openebs.ci 正是 Litmus 在 DevOps 流水线中使用的参考实现。在 Soak 测试中按随机间隔执行混沌图表除了常规 E2E 流水线OpenEBS 还在soak testing 套件中使用 Litmus 混沌图表其特点是在随机时间间隔random intervals下持续执行。Soak 测试的核心目的是让系统在长时间、非规律的故障注入下运行以发现仅在特定时序组合下才出现的隐藏问题。仓库中的 ChaosScheduler 规范文档 正是实现这类按间隔重复注入的关键资源详见下文。复现 OpenEBS 的验证体系核心混沌资源与配置ChaosEngine一次混沌注入的执行单元在 Litmus 中混沌执行的触发点是创建ChaosEngine自定义资源——它将应用实例与一个或多个混沌实验绑定定义运行特征、覆盖实验默认值并由 Litmus Chaos Operator 负责调和reconcile。其完整字段说明见 ChaosEngine 规范文档。以 OpenEBS E2E 中常用的 Pod 级通用实验pod-delete删除应用 Pod验证副本可用性、无中断服务与恢复流程为例一个完整的 ChaosEngine 清单如下示例取自 pod-delete 实验文档# tune the deletion of target pods forcefully or gracefully apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: active annotationCheck: false appinfo: appns: default applabel: appnginx appkind: deployment chaosServiceAccount: pod-delete-sa experiments: - name: pod-delete spec: components: env: # provided as true for the force deletion of pod # supports true and false value - name: FORCE value: true - name: TOTAL_CHAOS_DURATION value: 60pod-delete实验的主要可调参数tunables如下表所示这些参数同样适用于 OpenEBS 对通用图表的大多数 Pod 级场景变量说明备注TOTAL_CHAOS_DURATION混沌注入的持续时间秒默认 15s实验整体运行时长可能略超出该值CHAOS_INTERVAL两次连续 Pod 故障之间的时间间隔秒默认 5sRANDOMNESS是否在CHAOS_INTERVAL最小周期之上引入随机的删除间隔true/false默认false与 Soak 测试随机间隔需求直接相关FORCEPod 删除模式false为优雅删除默认终止宽限期 30strue为强制删除0s 宽限期默认true对应terminationGracePeriodSeconds0TARGET_PODS被施加 Pod 删除混沌的 Pod 名逗号分隔未提供时按appLabels随机选择目标 PodPODS_AFFECTED_PERC目标 Pod 的百分比默认 0对应 1 个副本仅接受数值RAMP_TIME混沌注入前后的等待时间秒—SEQUENCE多目标 Pod 的混沌执行顺序默认parallel支持serial/parallel更细粒度的参数如RANDOMNESS配合CHAOS_INTERVAL取值区间l-r、POD_TERMINATION_ORDER、INTER_POD_KILL_INTERVAL_SECONDS等均可从 pod-delete 实验文档 中查阅完整 YAML 示例。ChaosScheduler为 Soak 测试构造随机间隔的重复混沌OpenEBS Soak 测试中随机间隔执行混沌图表的需求在 Litmus 中对应ChaosScheduler资源——它以 ChaosEngine 为模板支持按时间戳、间隔、时间窗进行重复调度。其规格见 ChaosScheduler 规范字段明细见 schedule-repeat 文档。ChaosScheduler 支持三种基本调度策略Schedule Oncespec.schedule.now: true立即执行或通过spec.schedule.once.executionTime指定 UTC 时间戳执行一次见 schedule-once 文档Repeat Schedule按分钟/小时重复执行并可用timeRange起止时间窗、workHours每日允许注入的小时段、workDays每周允许注入的日期精确约束执行窗口Schedule State定义调度状态的启停。一个典型的每 5 分钟重复一次、且在指定时间窗内执行的 ChaosSchedule 清单如下示例取自 schedule-repeat 文档apiVersion: litmuschaos.io/v1alpha1 kind: ChaosSchedule metadata: name: schedule-nginx spec: schedule: repeat: timeRange: #should be modified according to current UTC Time startTime: 2020-05-12T05:47:00Z endTime: 2020-09-13T02:58:00Z properties: minChaosInterval: minute: everyNthMinute: 5 engineTemplateSpec: engineState: active appinfo: appns: default applabel: appnginx appkind: deployment annotationCheck: true chaosServiceAccount: pod-delete-sa jobCleanUpPolicy: delete experiments: - name: pod-delete spec: components: env: # set chaos duration (in sec) as desired - name: TOTAL_CHAOS_DURATION value: 30 # set chaos interval (in sec) as desired - name: CHAOS_INTERVAL value: 10 # pod failures without --force default terminationGracePeriodSeconds - name: FORCE value: false针对 Soak 测试可以把everyNthMinute/everyNthHour与 Pod 级实验的RANDOMNESS参数结合调度层保证随机时刻持续注入实验层保证每次注入内的故障间隔也随机化两者叠加即构成 OpenEBS 所描述的随机间隔执行。OpenEBS 依赖的通用实验清单从仓库的 实验分类索引 可以完整看到 OpenEBS 在 E2E 中可引用的通用Generic混沌图表范围Pod 级container-kill、disk-fill、pod-delete、pod-cpu-hog、pod-memory-hog、pod-network-loss/latency/corruption/duplication、pod-http-*系列等节点级docker-service-kill、kubelet-service-kill、node-cpu-hog、node-drain、node-restart、node-taint、node-io-stress等。其中对存储项目尤其有参考价值的是disk-fill填满 Pod 临时存储、触发驱逐验证 ephemeral-storage 限额是否合理见 disk-fill 实验文档与kubelet-service-kill杀掉 kubelet 使节点 NotReady验证存储控制器与数据面在节点失联下的恢复能力见 kubelet-service-kill 实验文档——这两类故障与存储系统的资源管理、调度与自愈路径高度相关。此外应用级如 Spring Boot 系列与云基础设施级AWS/GCP/Azure/VMware实验也可按需叠加。收益隐藏在正常路径之外的韧性缺陷被系统性暴露OpenEBS 团队在将混沌图表接入 E2E 流水线与 Soak 测试环境后得到了明确的实践结论隐藏的韧性缺陷被检测出来原本在功能测试中无法触达的故障路径如副本 Pod 被强制删除后存储副本的重建、节点 NotReady 后数据面的恢复被系统性验证边界场景corner cases得到覆盖混沌图表在随机时间间隔下与功能测试场景穿插执行使得故障注入与业务操作在时间轴上的各种交错组合都成为测试对象那些只在特定时序下才显现的韧性缺陷由此暴露。这一结论与仓库中 CI/CD FAQmkdocs/docs/experiments/faq/ci-cd.md的实践建议相互印证CI 中注入混沌能自动识别开发阶段的应用失败且实验中失败应必然导致流水线失败——OpenEBS 正是把这一点贯彻到 E2E 门禁与 Soak 环境的韧性基线中。延伸阅读OpenEBS 采纳案例原文完整采纳组织列表Cloud-Native OSS Projects 分类实验分类索引Pod/Node/Application/Load/云基础设施ChaosEngine 规格与示例ChaosScheduler 重复调度详解CI/CD 集成 FAQ对任何正在做存储类有状态系统、或需要在多发行版 Kubernetes 集群上建立韧性基线的团队而言OpenEBS 这套E2E 流水线 Soak 随机注入的组合是一个可以直接复用的混沌工程落地范式。赞分享云原生运维可观测性【免费下载链接】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点击查看免费下载相关推荐EVCC 混沌工程系统韧性测试与验证EVCC 混沌工程系统韧性测试与验证 概述 EVCCElectric Vehicle Charge Controller作为开源电动汽车充电控制器和家庭能后端前端智能硬件物联网能源管理cal.com混沌工程系统韧性测试与实践cal.com混沌工程系统韧性测试与实践 背景与挑战 日历应用作为时间管理基础设施其可用性直接影响用户日程安排的可靠性。cal.com作为开源日历解决方案后端前端企业应用MayaData 基于 Litmus 的混沌工程实践从 E2E 流水线到 Gamedays 的韧性验证之路MayaData 基于 Litmus 的混沌工程实践从 E2E 流水线到 Gamedays 的韧性验证之路 本篇技术案例以开源仓库 adopters/orga云原生运维可观测性上一篇ncmdump: 突破NCM格式限制的音频解密技术实践下一篇ncmdump打破音乐格式壁垒的开源力量创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
)
