混沌网格有望为混沌工程带来秩序

混沌和工程是您在2010年之前从未见过的两个词。可能是因为工程通常被认为具有建设性，而混乱却恰恰相反。话虽这么说，当您初次了解Netflix的原始混沌工程工具Chaos Monkey时，很容易想像到猴子会随机拔出电线并用扳手敲击系统。但是，恰恰相反，混沌工程是一种在故障变成断电之前发现故障的有纪律的方法。这是通过主动进行故障测试或以受控方式注入故障来完成的，以便可以评估和改进系统的响应能力。这些故障可能是从注入延迟到网络故障再到较高的CPU和内存使用量。您甚至可以模拟DDoS（分布式拒绝服务）攻击或任何其他可能导致服务中断的事件。引用AWS的Seth Eliot的话，“除非您假设工作负载将如何应对故障，否则您不能认为工作负载具有弹性。”这使我们进入了混沌网格。

Chaos Mesh 1.0将于本月初正式面市，它是一个开放源代码，由CNCF托管，云原生的混沌工程解决方案，可为Kubernetes上的复杂系统编排故障注入。 Chaos Mesh是在PingCAP上开发的，用于对其开源数据库系统TiDB进行故障测试。这是继PikCAP之后的第二个由CNCF托管的项目，仅次于分布式键值存储引擎TiKV。 PingCAP首席技术官Ed Huang表示，“传统确定性测试”不足以确保Kubernetes上分布式系统的弹性。

专门为Kubernetes构建的Chaos Mesh涵盖了从Pod到网络到文件系统甚至内核本身的所有混沌实验。 Chaos Mesh的目标是成为一个易于使用且可扩展到PB级的“通用”且中立的混沌测试平台。作为Kube原生的，它不需要特殊的依赖关系或修改，并且可以直接部署在集群上。另一个优点是，它可以与其他测试框架很好地集成，甚至可以在生产环境中执行混乱的实验。

与过去不同，服务器处于“启动”状态表明一切都应运而生，而今天则与功能和用户体验有关。类似于Netflix通过计算按下播放按钮的次数来检查其脉冲的方式，Chaos Mesh的工作原理是使用TiKV模拟pod的停机时间，然后分析其对QPS（每秒查询量）的影响。如果所讨论的按钮没有达到预期的功能，则用户将继续按下该按钮，从而导致QPS上升，并指示某些功能无法正常运行。

在这种情况下，当机顶盒崩溃导致QPS波动，然后在一分钟内恢复到可接受的水平时，您就知道系统具有弹性，可以继续进行下一个测试。但是，如本例所示，在最多需要9分钟才能恢复正常的情况下，需要进一步调查。混沌网格具有两种pod级别的故障注入，即pod-kill和pod-failure。后者模拟了一个不可用的Pod，而前者，顾名思义，模拟了一个Pod被杀死，您还可以创建自定义的Pod级别故障，例如PodNetworkChaos或PodIOChaos。

现在要记住，一个崩溃的吊舱只是Chaos Mesh能够进行故障注入的一个示例。有六种混沌类型：PodChaos，NetworkChaos，TimeChaos，StressChaos，IOChaos和KernelChaos。特别是在网络错误方面，您比其他混乱类型有更多选择。网络延迟，网络损坏，网络丢失，网络复制和网络分区，正如它们的名称所暗示的，所有这些都会影响网络。对于文件系统混乱，您只有两个，即I / O延迟和I / O错误，分别模拟文件系统I / O延迟和错误。

其他主要的混乱实验包括容器杀死，这是一个重要的实验，因为它可以杀死容器中的特定容器，CPU消耗使选定容器的CPU处于压力状态，内存消耗使存储器处于压力状态。 TimeChaos也是重要的一环，尤其是在分布式环境中，在该环境中，跨所有节点维护同步时钟以保持合规性并维护安全至关重要。 TimeChaos引入了一个称为“时钟偏斜”的故障，该故障从根本上引入了不同节点上的时钟之间的时差，以了解您的系统如何响应。

现在，CustomResourceDefinition或CRD是强大的Kubernetes功能，从根本上扩展了Kubernetes API以允许您定义自定义资源。 Chaos Mesh使用Kubernetes的这种功能来定义自定义混沌对象，例如我们前面提到的6种混沌类型。 Chaos Mesh还可以在适用的情况下利用现有的CRD实现，并允许您使用现有的CRD来构建新对象以开始进行混沌实验。可以创建新对象，或使用YAML文件或Kubernetes API更新现有CRD。

YAML方法是此处的首选方法，尤其是因为它可以在部署后进行混乱的实验。要创建自己的自定义混乱实验，您需要创建自己的YAML配置文件，尽管在线查找示例非常容易。或者，可以通过Kubernetes API直接操作CRD。 Chaos Mesh用CRD定义混沌对象的事实使得它很自然地适合Kubernetes用于基于Kubernetes的应用程序。这也使安装变得容易得多，因为它就像将一组CRD应用于集群一样简单。

目前，Chaos Mesh由两个核心组件组成：执行编排的Chaos Operator（GA，并且是完全开源的）和Chaos Dashboard，它实质上是用于创建，管理和监视混沌实验的Web UI（正在开发中）。混沌操作员也称为控制器管理器，它使用对象控制器来管理CRD，并使用准入网钩控制器将Sidecar代理插入到容器中。 Chaos Operator还具有一个Chaos Daemon，它充当代理程序，在每个节点上运行一个pod。

这里的Chaos守护程序是一个具有特定节点特权的守护程序集。控制器管理器将所需的操作中继到守护程序集，该守护程序集继而使用其特权来操纵系统以根据需要影响目标容器。当我们要模拟更严重的IO类型故障时，准入Webhooks出现了，这是通过在应用程序部署期间将混乱的小车注入到pod中并通过拦截文件系统调用来劫持IO来实现的。根据上述情况如何影响QPS，可以进行必要的更改以避免类似情况引起的中断。

混沌网格绝不是混沌工程平台的唯一选择，另一个由CNCF托管并检查很多相同盒子的竞争对手称为Litmus或LitmusChaos。我们之所以这样说，是因为与Chaos Mesh一样，Litmus是开源的云原生平台，使用CRD进行混沌管理，并且是为Kubernetes构建的。其他流行的选项包括原始的混沌工程工具Chaos Monkey，提供混沌工程即服务的Gremlin，Chaos Toolkit和KubeInvader。

虽然混乱的工程听起来像是一种新型的矛盾词，而在生产中破坏事物听起来似乎很疯狂，但“有效地”破坏事物正迅速成为Kubernetes弹性测试的标准。

报告此广告