云原生混沌工程 - 增强Kubernetes应用容错性

作者：Uma Mukkara，COO，MayaData

将云原生原理扩展到混沌工程

不管在将软件投入生产之前进行多么困难的测试以发现错误，错误总是会发生 - 云和可用区域会出现问题，网络会崩溃，是的，错误会让人感觉它们的存在。容错性（Resilience/弹性）是指一个系统承受这些错误的能力 - 例如，一个高度容错性的系统，一个由松散耦合的微服务构建的系统，它本身可以很容易地重新启动和扩展，在不影响用户的情况下克服这些错误。混沌工程是在系统出现故障之前，将其注入系统的实践。混沌工程现在被认为是确保当今频繁变化和高度复杂的系统实现所需的容错性的基本方法。通过混沌工程，可以在引起用户问题之前发现和纠正未预料到的故障场景。

广泛的采用使Kubernetes成为最重要的软件开发和操作平台之一。“云原生”这个词是一个被许多传统供应商用来指代几乎所有事物的术语；甚至CNCF也允许使用术语“云原生”来描述那些比云原生模式早几十年的技术。出于这篇博客的目的，我想使用云原生的更技术性的定义；在这里，云本地被定义为一种架构，其中的组件是松散耦合的微服务，更具体地说，部署在Kubernetes和相关项目编排的容器中。

在本博客中，我想介绍一个相对较新的或较少使用的术语“云原生混沌工程”，它的定义是专注于（并构建于）Kubernetes环境、应用程序、微服务和基础设施的工程实践。

CNCF首要是一个开源社区（虽然有些项目可能不是严格意义上的原生云，但它们都是开源的）。如果Kubernetes不是开源的，它就不会成为软件开发和运营的实际标准平台。考虑到这一点，我想断言云原生混沌工程必然基于开源技术。

云原生混沌工程框架的四个原则

1. 开源 - 该框架必须在Apache2许可下完全开源，以鼓励更广泛的社区参与和检查。迁移到Kubernetes平台的应用程序数量是无限的。在如此大的范围内，只有开放的混沌模型才能蓬勃发展并得到所需的采用。
2. 混沌管理的CRD - Kubernetes原生 - 在这里定义为使用Kubernetes CRD作为API，供开发者和SREs构建和编排混沌测试。CRD充当标准API来提供和管理混沌。
3. 可扩展和可插拔 - 云原生方法胜出的一个教训是，它们的组件可以相对容易地换出，并根据需要引入新的组件。其他开源开发者开发的任何标准的混沌管理库，或功能都应该能够通过这个可插拔的框架集成并编排测试。
4. 广泛的社区采用 - 一旦我们有了API、操作器和插件框架，我们就有了注入混沌所需的所有元素。这种混沌将在著名的基础设施，如Kubernetes或应用程序，如数据库，或其他基础设施组件，如存储或网络，上运行。这些混沌的实验可以被重用，一个基础广泛的社区对于识别和贡献其他高价值的场景是很有用的。因此，混沌工程框架应该提供一个中心枢纽或仓库，在那里开源的ChaosExperiment是共享的，并通过代码协作是可行的。

介绍Litmus

Litmus是Kubernetes的云原生混沌工程框架。它在满足上述四个参数方面是独一无二的。Litmus最初是作为一种混沌的工具集来运行CNCF沙箱项目OpenEBS的E2E流水线 - 例如，OpenEBS.ci - 已经发展成为一个完全开源的框架，用于在基于Kubernetes的系统上构建和运行混沌测试。它由四个主要部分组成

• Chaos CRDs or API
• Chaos Operator
• Chaos libraries and plugin framework
• Chaos Hub

Chaos API

目前，Litmus提供三个API：

• ChaosEngine
• ChaosExperiment
• ChaosResult

ChaosEngine：为给定的应用程序创建ChaosEngine CR，并用appLabel标记。此CR将一个或多个ChaosExperiment与一个应用程序绑定在一起。

ChaosExperiment：创建ChaosExperiment CR来保存和操作应用程序中实际混沌的细节。它定义了实验的类型和实验的关键参数。

ChaosResult：操作器在运行实验后创建ChaosResult CR。每个ChaosEngine维护一个ChaosResult CR。ChaosResult CR对于理解给定的ChaosExperiment是有用的。这个CR用于生成非常有用的混沌分析 - 例如，当某些组件在ChaosExperiment之间进行升级时，需要轻松地比较结果

Chaos Operator

Litmus操作器是使用Operator-SDK实现的。该操作器管理混沌CR的生命周期。Litmus的生命周期本身可以使用这个操作器来管理，因为它遵循生命周期管理API的要求。在operatorhub.io中也可以找到chaos operator。

Chaos Libraries and external Plugins

实际的混沌注入是由混沌库或混沌执行器完成的。例如，Litmus项目已经建立了一个名为“LitmusLib”的chaos库。LitmusLib知道如何杀死pod、如何引入CPU占用、如何占用内存或如何杀死节点，以及其他一些错误和降级。与LitmusLib一样，还有其它一些开源混沌项目，如Pumba或PowerfulSeal。CNCF景观有更多的各种混沌工程项目的细节。Litmus plugin框架允许其它混沌项目使用Litmus进行混沌编制。例如，可以使用Pumba或PowerfulSeal创建一个用于点杀实验的混沌chart，并通过Litmus framework执行它。

Chaos Hub

混沌chart位于hub.litmuschaos.io。ChaosHub将所有可重用的ChaosExperiment集合在一起。应用程序开发者和SRE共享他们的混沌体验，供其他人重用。中心的目标是让开发者共享他们用来在CI流水线中向用户（通常是SREs）验证他们的应用程序的失败测试。

目前，chaos hub包含Kubernetes chaos和OpenEBS chaos的chart。我们期望未来能从社区得到更多的贡献。

Litmus的例子用例

Litmus最简单的用例是在开发阶段本身使用Litmus的应用程序开发者。混沌工程已经被限制在生产环境中，最近，我们看到在CI流水线中采用了这种实践。但是有了Litmus，在开发过程中也可以进行混沌测试。与单元测试、集成测试和行为驱动测试一样，混沌测试是开发者在代码合并到存储库之前，执行负面测试场景以测试代码容错性的一种测试哲学。混沌测试可以很容易地附加到应用程序。

Litmus的其它用例用于在CI流水线和生产环境中引发混沌。

总结

随着chaos operator、chaos CRD以及chaos hub的引入，Litmus具备了云原生混沌工程的所有关键要素。

重要的链接：

GitHub：github.com/litmuschaos

Twitter：@litmuschaos

混沌的Chart：hub.litmuschaos.io

社区Slack：K8s Slack上的#litmus频道

https://twitter.com/litmuschaos

https://github.com/litmuschaos/litmus

https://kubernetes.slack.com/messages/CNXNB0ZTN