作者：南坪拓哉，来自“混沌工程实践社区”

编者提示：

本文转载自公众号 “混沌工程实践” (ID: chaosops)。欢迎阅读和关注 原文链接。

本文介绍了一款 K8s 上的著名混沌工程框架 LitmusChaos，从 K8s 平台和应用韧性的讨论入手，很深入地讨论了该框架的组成部分、实现原理、体系架构、实际用例、注意事项、生命周期、ChaosHub 实验库、监测汇总等内容，也提供了详尽的快速入门和参与社区贡献的方法。

作者：Uma Mukkara

时间：2020 年 7 月 31 日

标题：Introduction to LitmusChaos

来源：Dev.to

LitmusChaos 是 CNCF 沙箱项目，提供完整的混沌工程框架和混沌实验库，助力 K8s SRE 和开发人员发现 K8s 平台和应用的韧性问题。

在本文中，我们将讨论

• 为什么韧性对于 K8s 而言很重要？

• 如何使用 LitmusChaos 实现韧性？

1. K8s 的现状

得益于 K8s 和 CNCF 构建的生态，开发人员已经可以使用通用的 API 编排微服务。K8s 在技术采纳周期方面已经跨越了鸿沟。随着其持续增长，我们需要更多工具来确保 K8s 的使用过程是无缝且稳定的。

null

因此，韧性成为 K8s 开发人员和 SRE 需要重点关注的领域之一。作为 SRE，要如何确保我的应用可以抵御潜在的故障？如何实现韧性？我们将在本文中进行思考和讨论。

K8s 需要框架和工具来验证 K8s 平台以及 K8s 应用的韧性。

2. 韧性的定义

韧性是系统在发生故障时仍提供服务的能力。我们通常都会对系统有一个稳态假设。如果在故障发生后，系统能恢复到之前的稳态，则可以说该系统有抵抗该故障的能力。同样，这中间可能会发生不同类型的故障，它们之间没有先来后到，往往同时以组合的形式随机发生。

尽管我们都希望系统具有抵御所有故障的能力，或者能抵御所有这些故障的随机组合，但基本上这是不可能的。

世界上没有一个系统具有 100％的韧性。

在 K8s 的环境中，韧性尤为重要，因为 K8s 体系结构是基于面向预期状态的原则，不断使系统当前的状态，向期望的状态移动。状态转移的一致性决定了 K8s 的韧性。下图描述了 K8s 故障的一些示例。

在 K8s 环境中，将 Pod 驱逐、节点进入“未就绪”状态并不少见，但稳态假设因不同的位置而异。如果将 Pod 驱逐并在另一个节点上快速重新部署，则 K8s 将具有韧性。但是，如果依赖于该 Pod 的服务出现故障或变慢，则该服务无法抵御 Pod 驱逐，则不具有韧性。总而言之，韧性是环境相关的，因此需要将其视为一种实践，而不是特定的任务集。

null

上图显示了 K8s 应用韧性的依赖栈。

依赖栈的最底层是物理基础设施。K8s 正在各种基础设施上运行，从虚拟机到裸机及其组合。基础设施的物理性质是在容器内运行应用的故障来源，如上图所示。

往上一层的依赖关系是 K8s 服务。像 Linux 这样的平台软件每年更新一次的日子，已经一去不复返了，但至少在接下来的几年中，K8s 希望每季度升级一次。我们必须考虑对每个升级进行仔细的测试，以确保升级的软件能够解决预期的问题并且不会引入任何破坏性的情况。

除了 K8s 还有其他服务，例如 CoreDNS，Envoy，Istio，Prometheus，数据库，中间件等，这对于用户运行云原生环境都是必不可少的。这些云原生服务也需要频繁升级。

根据上述事实，可以预见到应用韧性实际上更多地取决于基础设施和 K8s 服务，而不是应用程序本身。一旦应用稳定下来，运行在 K8s 上的服务韧性，90%以上依赖于其他组件和基础设施。

因此，这里有个结论：

只要基础设施和 K8s 服务发生更改，就应验证应用程序的韧性。

“持续验证”成为了关键。升级前进行大规模的测试可还不够好，主要是因为在升级测试期间您可能无法考虑到各种故障。这就需要引入了混沌工程的概念。

持续验证应用服务抵抗故障能力的过程称为混沌工程。

由于上述原因，要实现整个基础设施和 K8s 服务的韧性，就必须对其进行混沌工程实验。

3. 在 K8s 上实现韧性

要获得韧性，就要实践混沌工程。SRE 团队在应用迁移到 K8s 的早期阶段，就应该将混沌工程工程实践放在优先位置。

这就是 Adrian Cockcraft 强调的“混沌优先”（Chaos-First）原则。

混沌工程不是简单的几个任务或者步骤就可以搞定，需要特定的理念和实践方法，因此要实践混沌工程仍存在一些基本的障碍。

如果 SRE 团队选择将混沌工程作为 K8s 韧性实现的方式，那么就必须以云原生方式进行。云原生的基本原则是声明式的。基于云原生的混沌工程原则，就应该是公开、声明式地进行混沌工程，并把社区放在心上。我在以前的文章中详细介绍过这个话题。

• https://www.cncf.io/blog/2019/11/06/cloud-native-chaos-engineering-enhancing-kubernetes-application-resiliency/
  

总之，基于云原生的混沌工程中，您将拥有一组 Chaos CRD，混沌实验可用作自定义的资源，并使用通用的声明性 API 来管理混沌实验。

4. Litmus 项目介绍

Litmus 是 K8s 的一个混沌工程框架，提供了 K8s 开发人员和 SRE 所需的一整套工具，以 K8s 云原生方式轻松进行混沌实验。该项目以“声明性混沌实验”为基本设计目标，并使社区成为发展混沌实验的中心。

4.1 Litmus 的组成部件

Chaos Operator 

使用 Operator SDK 框架构建，管理着混沌实验的生命周期

Chaos CRD 

主要包括三个 Chaos CRD：ChaosEngine，ChaosExperiment 和 ChaosResult。使用上述 CRD 构建、运行和管理混沌实验。ChaosEngine CRD 将目标应用程序与 ChaosExperiment 自定义资源绑定在一起。运行时，结果将存储在 ChaosResult 自定义资源中。

混沌实验 ChaosHub 

混沌实验是 K8s 上的自定义资源，以 YAML 规范托管在公共实验库 ChaosHub 上 (https://hub.litmuschaos.io)。

Chaos Scheduler 

混沌调度器支持对混沌实验进行精细化调度。

混沌指标导出器 (Chaos Metrics Exporter) 

这是 Prometheus 指标导出器。诸如数量、实验类型及其结果之类的混沌实验指标都将导出到 Prometheus 中。然后就可以把这些指标和目标应用的指标组合在一起绘制，以显示混沌对应用服务或性能的影响。

混沌事件导出器 (Chaos Events Exporter) 

Litmus 会为每次发生的混沌注入动作生成一个混沌事件。这些混沌事件存储在 etcd 中，然后导出到事件接收器，以便对受混沌注入影响的服务进行关联或调试。

控制台 (Portal) 

Litmus Portal 是用于创建、调度和监控混沌工作流的 Web 控制台。SRE 团队可以共享控制台，同时通过控制台管理混沌实验。

混沌工作流 (Chaos Workflow)

混沌工作流是由一组混沌实验组成，可从控制台在远程 K8s 集群上调度混沌工作流。

4.2 Litmus 实际用例

混沌实验可以在 DevOps 周期中的任何阶段开展，从持续集成到生产，混沌实验的程度各不相同。在持续集成中，您可能会开展特定的混沌实验，用于正开发的应用。当应用走向生产或进入运营时要获得韧性，必然会遇到很多需应对的故障场景，因此混沌实验的数量会大大增加。

null

Litmus 的典型用例包括 CI 流水线中的故障或混沌测试，在预生产环境和生产环境中增加混沌实验、K8s 升级验证、服务更新后验证以及韧性基准测试等。

我们不断从 SRE 那里听到，当他们想注入故障进行混沌实验，通常会遇到很多来自开发人员和管理层的阻力。在混沌工程实践中，从小的混沌实验开始，向开发人员和管理人员展示其优势和安全性，逐步获得信任。随着时间的流逝，实验的数量和应用的韧性也将逐步增加。

null

混沌工程是一种训练。如上图所示，随着时间的流逝，管理层的接纳和 SRE 的信心将逐步增加，并将混沌实验转移到生产中。同样，这个过程会给系统增加韧性。

4.3 Litmus 的体系架构

上图展示了 Litmus 在一个 K8s 集群中执行混沌实验的过程。

Litmus 体系结构将混沌实验的声明性和可伸缩性，视为两个重要的设计目标。

Chaos Operator 监测 ChaosEngine 自定义资源的更改，并在实验目标上为每个实验产生一个实验工作项。多个混沌实验可以并行执行，将结果方便地以自定义资源的形式存储。

因此，您无需为实验结果的跟踪而烦恼，实验结果始终在 K8s 的 etcd 数据库中。混沌指标导出器会从 etcd 数据库中有关 ChaosEngine 和 ChaosResult 的自定义资源中抓取混沌实验指标数据。

null

为了实现可伸缩性和更深层次混沌实验，将一组混沌实验组合到一个混沌工作流中，并通过 argo 工具执行这些实验。混沌工作流的构建和管理都在 Litmus 控制台上完成，并在目标 K8s 集群上运行。控制台还包括直观的混沌实验分析，Portal 还为 SRE 团队提供了一种便捷的方式，使他们可以构建自己的 ChaosHub 来开发新的混沌实验。

4.4 安全实验的注意事项

混沌在设计上是有破坏性的。人们需要谨慎地搞清：谁会造成破坏以及在何处造成破坏。

Litmus 提供了各种配置来通过策略控制混沌的破坏性：

• 注记：可以在应用级别启用注记。默认是启用的，当注记启用后，目标应用只有注记了“chaos = true”

• ServiceAccounts：RBAC 可在每个实验级别进行配置。每个实验根据引入的混沌类型设置不同的权限。

但是，Litmus 也可在 Admin 模式下运行，在该模式下，混沌实验本身在 Litmus 命名空间中运行，并且会有一个拥有管理员权限的 ServiceAccount 被添加至 Litmus 中。当且仅当，出于学习目的或纯粹的开发环境中运行 Litmus 时，才建议使用此模式。建议在预生产和生产环境中以 Limux 命名空间中运行。

4.5 混沌实验的生命周期

Litmus 中的混沌实验被设计为灵活且可扩展的，包含一些可调的参数：

• 混沌实验参数，例如混沌实验间隔和频率

• 混沌注入库。有时，为了执行特定的故障注入动作，需要使用不同的混沌注入库。可选择第三方的混沌注入库，例如：Litmus 支持 PowerfulSeal 和 ChaosToolkit 进行 Pod 删除的故障注入。如果您已经在使用一些混沌实验工具，想按原样继续使用它们，则可以使用 Litmus 框架。

Litmus 实验还包括稳态检查和后期混沌实验监测，具体可以根据您在混沌实施时的要求进行更改。

4.6 ChaosHub 实验库

混沌实验是 Litmus 的核心部分。我们预期到这些实验将不断进行调整，并通过 ChaosHub 添加新的实验。

LitmusChaos 实验大致可以分成两种：

• 通用实验，涵盖任何通用 K8s 资源或物理组件的故障注入场景。

• 应用特定的混沌实验，涵盖了特定于应用逻辑的故障注入场景。我们鼓励云原生应用维护者和开发人员，将失败路径测试共享到 ChaosHub 中，以便他们的用户可以在 Litmus 的生产或预生产阶段进行相同的实验。

ChaosHub 目前有大约 48 个实验，其中重要的实验包括：

4.7 开发自定义实验

ChaosHub 提供了随时可用的实验，并可根据您的需要进行调整。这些实验涵盖了您最初的混沌工程需求，并可以帮助您开始进行混沌工程实践。

很快，您将必须开发针对应用自定义的 LitmusChaos 实验，Litmus 为此提供了一个易于使用的 SDK。Litmus SDK 支持 Go、Python 和 Ansible 语言。

通过使用 SDK，只需几个步骤即可创建出新实验的框架，然后开始添加所需的混沌逻辑，以及实验前和实验后的检查，完成的实验可以在 Litmus 上使用。

4.8 混沌实验监测

Litmus 控制台可添加许多图表，以帮助监控混沌实验、混沌工作流并分析其结果。当然，您也可以使用导出到 Prometheus 的混沌指标，将混沌事件直接绘制到现有应用的监视图上。

下图显示了微服务演示应用“sock-shop”中的混沌监测示例。红色区域是混沌注入的时刻。

4.9 如何快速入门

您可以通过三个简单的步骤来创建您的第一个混沌实验。

1. 通过 Helm 安装 Litmus

2. 从 ChaosHub 中选择示例应用和混沌实验（例如：Pod 删除实验）

3. 创建并运行一个 ChaosEngine

阅读下面的文章，可以为您提供演示应用的 Litmus 快速入门指南。

• https://dev.to/uditgaurav/get-started-with-litmuschaos-in-minutes-4ke1
  

4.10 路线图

Litmus 项目路线图总结在这里：

• https://github.com/litmuschaos/litmus/blob/master/ROADMAP.md
  

每月的社区会议用于获取社区的反馈，确定下个月或季度路线图的优先级。Litmus 的长期路线图是添加特定于应用的实验，以覆盖 CNCF 的全景范围。

4.11 参与贡献

以下是贡献规则：

• https://github.com/litmuschaos/litmus/blob/master/CONTRIBUTING.md
  

Litmus 控制台正在积极开发中，因此许多新的混沌实验也在进行中。请访问我们的路线图部分或问题，以查看是否可以找到符合您需求的内容。如果没有，没问题，请在 K8s Slack 的 #litmus 频道加入我们的社区，打个招呼。

4.12 社区活动

社区同步会议在每个月的第三个星期三举行。加入此会议，与在线维护人员进行交流，并讨论如何为您提供帮助或寻求有关 Bug 或功能请求优先级的问题。该项目鼓励开放式沟通和治理。我们已经创建了特殊兴趣小组（SIG），以允许他们参与贡献者感兴趣的领域。参见：

• https://github.com/orgs/litmuschaos/teams?query=SIG
  

社区互动可在 K8s Slack 中的 #litmus 频道，贡献者沟通可在 K8s Slack 中的 #litmus-dev 频道上。

5. 结束语

K8s SRE 可以通过采用混沌优先 (Chaos-First) 原则和基于云原生的混沌工程来逐步提高应用韧性。Litmus 是这样一套工具框架，可帮助您入门并完全完成此类任务。

排版 | 安然

审校 | 叶笑  

主编 | 木子

---

本文转载自公众号 “混沌工程实践” (ID: chaosops)。

欢迎阅读和关注 原文链接

混沌工程实践社区是一个由热爱混沌工程的技术专家共同发起的实践社区，旨在推广混沌工程技术: 第一时间提供海内外有关混沌工程的最新进展和实践报告，最大程度连接全世界更多的混沌工程爱好者和技术专家，期望可以帮助到对混沌工程有兴趣的新人，使他们熟悉混沌工程的方法和技巧，更快地进入混沌工程领域开展研究和实践。