LitmusChaos: K8s上的混沌工程框架
作者：南坪拓哉，来自“混沌工程实践社区”
编者提示：
本文转载自公众号 “混沌工程实践” (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的使用过程是无缝且稳定的。
因此，韧性成为K8s开发人员和SRE需要重点关注的领域之一。作为SRE，要如何确保我的应用可以抵御潜在的故障？如何实现韧性？我们将在本文中进行思考和讨论。
K8s需要框架和工具来验证K8s平台以及K8s应用的韧性。
2. 韧性的定义
韧性是系统在发生故障时仍提供服务的能力。我们通常都会对系统有一个稳态假设。如果在故障发生后，系统能恢复到之前的稳态，则可以说该系统有抵抗该故障的能力。同样，这中间可能会发生不同类型的故障，它们之间没有先来后到，往往同时以组合的形式随机发生。
尽管我们都希望系统具有抵御所有故障的能力，或者能抵御所有这些故障的随机组合，但基本上这是不可能的。
世界上没有一个系统具有100％的韧性。
在K8s的环境中，韧性尤为重要，因为K8s体系结构是基于面向预期状态的原则，不断使系统当前的状态，向期望的状态移动。状态转移的一致性决定了K8s的韧性。下图描述了K8s故障的一些示例。
在K8s环境中，将Pod驱逐、节点进入“未就绪”状态并不少见，但稳态假设因不同的位置而异。如果将Pod驱逐并在另一个节点上快速重新部署，则K8s将具有韧性。但是，如果依赖于该Pod的服务出现故障或变慢，则该服务无法抵御Pod驱逐，则不具有韧性。总而言之，韧性是环境相关的，因此需要将其视为一种实践，而不是特定的任务集。
上图显示了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韧性实现的方式，那么就必须以云原生方式进行。云原生的基本原则是声明式的。基于云原生的混沌工程原则，就应该是公开、声明式地进行混沌工程，并把社区放在心上。我在以前的文章中详细介绍过这个话题。
总之，基于云原生的混沌工程中，您将拥有一组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上 ()。
Chaos Scheduler
混沌调度器支持对混沌实验进行精细化调度。
混沌指标导出器 (Chaos Metrics Exporter)
这是Prometheus指标导出器。诸如数量、实验类型及其结果之类的混沌实验指标都将导出到Prometheus中。然后就可以把这些指标和目标应用的指标组合在一起绘制，以显示混沌对应用服务或性能的影响。
混沌事件导出器 (Chaos Events Exporter)
Litmus会为每次发生的混沌注入动作生成一个混沌事件。这些混沌事件存储在etcd中，然后导出到事件接收器，以便对受混沌注入影响的服务进行关联或调试。
控制台 (Portal)
Litmus Portal是用于创建、调度和监控混沌工作流的Web控制台。SRE团队可以共享控制台，同时通过控制台管理混沌实验。
混沌工作流 (Chaos Workflow)
混沌工作流是由一组混沌实验组成，可从控制台在远程K8s集群上调度混沌工作流。
4.2 Litmus实际用例
混沌实验可以在DevOps周期中的任何阶段开展，从持续集成到生产，混沌实验的程度各不相同。在持续集成中，您可能会开展特定的混沌实验，用于正开发的应用。当应用走向生产或进入运营时要获得韧性，必然会遇到很多需应对的故障场景，因此混沌实验的数量会大大增加。
Litmus的典型用例包括CI流水线中的故障或混沌测试，在预生产环境和生产环境中增加混沌实验、K8s升级验证、服务更新后验证以及韧性基准测试等。
我们不断从SRE那里听到，当他们想注入故障进行混沌实验，通常会遇到很多来自开发人员和管理层的阻力。在混沌工程实践中，从小的混沌实验开始，向开发人员和管理人员展示其优势和安全性，逐步获得信任。随着时间的流逝，实验的数量和应用的韧性也将逐步增加。
混沌工程是一种训练。如上图所示，随着时间的流逝，管理层的接纳和SRE的信心将逐步增加，并将混沌实验转移到生产中。同样，这个过程会给系统增加韧性。
4.3 Litmus的体系架构
上图展示了Litmus在一个K8s集群中执行混沌实验的过程。
Litmus体系结构将混沌实验的声明性和可伸缩性，视为两个重要的设计目标。
Chaos Operator监测ChaosEngine自定义资源的更改，并在实验目标上为每个实验产生一个实验工作项。多个混沌实验可以并行执行，将结果方便地以自定义资源的形式存储。
因此，您无需为实验结果的跟踪而烦恼，实验结果始终在K8s的etcd数据库中。混沌指标导出器会从etcd数据库中有关ChaosEngine和ChaosResult的自定义资源中抓取混沌实验指标数据。
为了实现可伸缩性和更深层次混沌实验，将一组混沌实验组合到一个混沌工作流中，并通过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 如何快速入门
您可以通过三个简单的步骤来创建您的第一个混沌实验。
阅读下面的文章，可以为您提供演示应用的Litmus快速入门指南。
4.10 路线图
Litmus项目路线图总结在这里：
每月的社区会议用于获取社区的反馈，确定下个月或季度路线图的优先级。Litmus的长期路线图是添加特定于应用的实验，以覆盖CNCF的全景范围。
4.11 参与贡献
以下是贡献规则：
Litmus控制台正在积极开发中，因此许多新的混沌实验也在进行中。请访问我们的路线图部分或问题，以查看是否可以找到符合您需求的内容。如果没有，没问题，请在K8s Slack的#litmus频道加入我们的社区，打个招呼。
4.12 社区活动
社区同步会议在每个月的第三个星期三举行。加入此会议，与在线维护人员进行交流，并讨论如何为您提供帮助或寻求有关Bug或功能请求优先级的问题。该项目鼓励开放式沟通和治理。我们已经创建了特殊兴趣小组（SIG），以允许他们参与贡献者感兴趣的领域。参见：
社区互动可在K8s Slack中的#litmus频道，贡献者沟通可在K8s Slack中的#litmus-dev频道上。
5. 结束语
K8s SRE可以通过采用混沌优先 (Chaos-First) 原则和基于云原生的混沌工程来逐步提高应用韧性。Litmus是这样一套工具框架，可帮助您入门并完全完成此类任务。
排版 | 安然
审校 | 叶笑
主编 | 木子
---
本文转载自公众号 “混沌工程实践” (ID: chaosops)。
