关于云计算:Litmus-实践让群魔在混沌中乱舞看-K8s-能撑到何时

对于云服务而言，如果零碎出现异常，将会带来很大的损失。为了最大水平地升高损失，咱们只能一直探寻零碎何时会出现异常，甚至放大到某些特定参数变动是否会造成零碎异样。然而随着云原生的倒退，一直推动着微服务的进一步解耦，海量的数据与用户规模也带来了基础设施的大规模分布式演进，零碎中的故障变得越来越难以预料。咱们须要在零碎中一直进行试验，被动找出零碎的缺点，这种办法被称作混沌工程。毕竟实际是测验真谛的唯一标准，所以混沌工程能够帮忙咱们更加透彻地把握零碎的运行法则，进步零碎的弹性能力。

Litmus 是一种开源的云原生混沌工程工具集，专一于 Kubernetes 集群进行模仿故障测试，以帮忙开发者和 SRE 发现集群及程序中的缺点，从而进步零碎的健壮性。

Litmus 的架构如图所示：

Litmus 的组件能够划分为两局部：

Portal
Agents

Portal 是一组 Litmus 组件，作为跨云治理混沌试验的管制立体 (WebUI)，用于协调和察看 Agent 上的混沌试验工作流。

Agent 也是一组 Litmus 组件，包含运行在 K8s 集群上的混沌试验工作流。

应用 Portal，用户能够在 Agent 上创立和调度新的混沌试验工作流，并从 Portal 上察看后果。用户还能够将更多的集群连贯到 Portal，并将 Portal 作为跨云混沌工程治理的单个门户。

Litmus WebUI

Litmus WebUI 提供了 Web 用户界面，用户能够在这里轻松构建和察看混沌试验工作流。Litmus WebUI 也充当了跨云混沌试验管制立体。
Litmus Server

Litmus Server 作为中间件，用于解决来自用户界面的 API 申请，并将配置和处理结果详情信息存储到数据库中。它还充当各个申请之间的通信接口，并将工作流程调度到 Agent。
Litmus DB

Litmus DB 作为混沌试验工作流及其测试后果详情的存储系统。

Chaos Operator

Chaos Operator 监督 ChaosEngine 并执行 CR 中提到的混沌试验。Chaos Operator 是命名空间范畴的，默认状况下运行在 litmus 命名空间中。试验实现后，Chaos Operator 会调用 chaos-exporter 将混沌试验的指标导出到 Prometheus 数据库中。

CRDs

Litmus 装置过程中会生成以下几个 CRD：

chaosexperiments.litmuschaos.io
chaosengines.litmuschaos.io
chaosresults.litmuschaos.io

Chaos Experiment

Chaos Experiment（混沌试验）是 LitmusChaos 体系结构中的根本单元，用户能够从 Chaos Hub 上抉择现场的混沌试验或者本人创立新的混沌试验来构建所需的混沌试验工作流。简略来说就是定义一个该测试反对哪些操作、能传入哪些参数、可对哪些类型的对象进行测试等 CRD 资源清单，通常分为三种类别：通用的测试（比方内存，磁盘，CPU 等操作），利用的测试（比方针对 Nginx 来进行测试），平台测试（针对于某个云平台的测试：AWS, Azure, GCP）。详情可参考 Chaos Hub 的文档。
Chaos Engine

ChaosEngine 将 Chaos Experiment 实现的性能具体实施到命名空间中的利用中。该 CR 由 Chaos Operator 监控。
Chaos Results

ChaosResult 保留了混沌试验的后果，它会在试验运行时创立或更新，蕴含了各种信息，包含 Chaos Engine 的配置、试验状态等。chaos-exporter 将会读取后果并导出到 Prometheus 数据库中。
Chaos Probes

Chaos Probes 是可插拔的指标探针，能够在任意混沌试验的 ChaosEngine 中定义，试验 Pod 会依据其定义的模式来执行相应的检测，并将其是否胜利作为决定试验后果的必要条件（还包含了规范的“内置”检测）。
Chaos Exporter

能够抉择将指标导出到 Prometheus 数据库。Chaos Exporter 实现了 Prometheus metrics endpoint。
Subscriber

Subscriber 用来和 Litmus Server 交互，获取混沌试验工作流的具体后果，并发送回 Agent 端。

KubeSphere 集成了 OpenPitrix 来提供应用程序全生命周期治理，OpenPitrix 是一个多云利用治理平台，KubeSphere 利用它实现了利用商店和利用模板，以可视化的形式部署并治理利用。对于利用商店中不存在的利用，用户能够将 Helm Chart 交付至 KubeSphere 的公共仓库，或者导入公有利用仓库来提供利用模板。

本教程将应用 KubeSphere 的利用模板来部署 Litmus。

要想从利用模板部署利用，须要创立一个企业空间、一个我的项目和两个用户帐户（ws-admin 和 project-regular）。ws-admin 必须被授予企业空间中的 workspace-admin 角色，project-regular 必须被授予我的项目中的 operator 角色。在创立之前，咱们先来回顾一下 KubeSphere 的多租户架构。

KubeSphere 的多租户零碎分三个层级，即集群、企业空间和我的项目。KubeSphere 中的我的项目等同于 Kubernetes 的命名空间。

您须要创立一个新的企业空间进行操作，而不是应用零碎企业空间，零碎企业空间中运行着系统资源，绝大部分仅供查看。出于平安思考，强烈建议给不同的租户授予不同的权限在企业空间中进行合作。

您能够在一个 KubeSphere 集群中创立多个企业空间，每个企业空间下能够创立多个我的项目。KubeSphere 为每个级别默认设有多个内置角色。此外，您还能够创立领有自定义权限的角色。KubeSphere 多层次构造实用于具备不同团队或组织以及每个团队中须要不同角色的企业用户。

装置 KubeSphere 之后，您须要向平台增加具备不同角色的用户，以便他们能够针对本人受权的资源在不同的层级进行工作。一开始，零碎默认只有一个帐户 admin，具备 platform-admin 角色。在本步骤中，您将创立一个帐户 user-manager，而后应用 user-manager 创立新帐户。

以 admin 身份应用默认帐户和明码 (admin/P@88w0rd) 登录 Web 控制台。

出于平安思考，强烈建议您在首次登录控制台时更改明码。若要更改明码，在右上角的下拉菜单中抉择 集体设置 ，在 明码设置 中设置新密码，您也能够在 集体设置 中批改控制台语言。

登录控制台后，点击左上角的 平台治理 ，而后抉择 访问控制。

在 帐户角色 中，有如下所示四个可用的内置角色。接下来要创立的第一个帐户将被调配 users-manager 角色。

内置角色	形容
`workspaces-manager`	企业空间管理员，治理平台所有企业空间。
`users-manager`	用户管理员，治理平台所有用户。
`platform-regular`	平台普通用户，在被邀请退出企业空间或集群之前没有任何资源操作权限。
`platform-admin`	平台管理员，能够治理平台内的所有资源。

在 帐户治理 中，点击创立。在弹出窗口中，提供所有必要信息（带有 * 标记），而后在角色字段抉择 users-manager。请参考下图示例。

实现后，点击确定。新创建的帐户将显示在 帐户治理 中的帐户列表中。

切换帐户应用 user-manager 从新登录，创立如下三个新账户。

帐户	角色	形容
`ws-manager`	`workspaces-manager`	创立和治理所有企业空间。
`ws-admin`	`platform-regular`	治理指定企业空间中的所有资源（此帐户用于邀请成员 project-regular 退出该企业空间）。
`project-regular`	`platform-regular`	该帐户将用于在指定我的项目中创立工作负载、流水线和其余资源。

查看创立的三个帐户。

在本步骤中，您须要应用上一个步骤中创立的帐户 ws-manager 创立一个企业空间。作为治理我的项目、创立工作负载和组织成员的根本逻辑单元，企业空间是 KubeSphere 多租户零碎的根底。

以 ws-manager 身份登录 KubeSphere，它具备治理平台上所有企业空间的权限。点击左上角的 平台治理 ，抉择 访问控制 。在 企业空间 中，能够看到仅列出了一个默认企业空间 system-workspace，即零碎企业空间，其中运行着与零碎相干的组件和服务，您无奈删除该企业空间。
点击右侧的创立，将新企业空间命名为 demo-workspace，并将用户 ws-admin 设置为企业空间管理员，如下图所示：

实现后，点击创立。
登出控制台，而后以 ws-admin 身份从新登录。在 企业空间设置 中，抉择 企业成员 ，而后点击 邀请成员。
邀请 project-regular 进入企业空间，授予其 workspace-viewer 角色。

理论角色名称的格局：<workspace name>-<role name>。例如，在名为 demo-workspace 的企业空间中，角色 viewer 的理论角色名称为 demo-workspace-viewer。

将 project-regular 增加到企业空间后，点击确定。在 企业成员 中，您能够看到列出的两名成员。

帐户	角色	形容
`ws-admin`	`workspace-admin`	治理指定企业空间中的所有资源（在此示例中，此帐户用于邀请新成员退出企业空间、创立我的项目）。
`project-regular`	`workspace-viewer`	该帐户将用于在指定我的项目中创立工作负载和其余资源。

在此步骤中，您须要应用在上一步骤中创立的帐户 ws-admin 来创立我的项目。KubeSphere 中的我的项目与 Kubernetes 中的命名空间雷同，为资源提供了虚构隔离。无关更多信息，请参见命名空间。

以 ws-admin 身份登录 KubeSphere，在 项目管理 中，点击创立。
输出项目名称（例如 litmus），而后点击确定实现，您还能够为我的项目增加别名和形容。
在 项目管理 中，点击刚创立的我的项目查看其详细信息。
邀请 project-regular 至该我的项目，并授予该用户 operator 角色。请参考下图以理解具体步骤。

具备 operator 角色的用户是我的项目维护者，能够治理我的项目中除用户和角色以外的资源。

以 ws-admin 用户登录 KubeSphere 的 Web 控制台。在您的企业空间中，进入 利用治理 下的 利用仓库 页面，并点击 增加仓库。
在弹出的对话框中，将利用仓库名称设置为 litmus，将利用仓库的 URL 设置为 https://litmuschaos.github.io/litmus-helm/，点击验证对 URL 进行验证，再点击确定进入下一步。
利用仓库导入胜利后会显示在如下图所示的列表中。

导入 Litmus 的利用仓库后，就能够通过利用模板来部署 Litmus 了。

登出 KubeSphere 并以 project-regular 用户从新登录。在您的我的项目中，进入 利用负载 下的利用页面，再点击 部署新利用。
在弹出的对话框中抉择 来自利用模板。
在弹出的对话框中抉择 来自利用模板。

来自利用商店：抉择内置的利用和以 Helm Chart 模式独自上传的利用。

来自利用模板：从公有利用仓库和企业空间利用池抉择利用。
从下拉列表中抉择之前增加的公有利用仓库 litmus。
抉择 litmus-2-0-0-beta 进行部署。
您能够查看利用信息和配置文件，在版本下拉列表中抉择版本，而后点击部署。
设置利用名称，确认利用版本和部署地位，点击下一步。
在利用配置页面，您能够手动编辑清单文件或间接点击部署。
期待 Litmus 创立实现并开始运行。

拜访 Portal 服务

Portal 的 Service 名称为 litmusportal-frontend-service。能够先到服务界面查看它的 NodePort：

用 ${Node IP}:${NODEPORT} 地址拜访 Portal：

默认的用户名明码：

Username: admin
Password: litmus

Litmus 蕴含两种类型的 Agent：

Self Agent
External Agent

默认状况下，装置 Litmus 所在的集群会被主动注册为 Self Agent，Portal 默认会在 Self Agent 中执行混沌试验。

后面也说了，Portal 是一个跨云混沌试验管制立体，也就是说，用户能够将多个部署在内部 K8s 集群中的 External Agent 连贯到以后 Portal，以便将混沌试验下发给 Agent，并在 Portal 中察看后果。

对于 External Agent 的部署形式，能够参考 Litmus 的官网文档。

Portal 装置实现后，能够通过 Portal 界面来创立混沌试验，须要先创立一个用来测试的利用：

$ kubectl create deployment nginx --image=nginx --replicas=2 --namespace=default

上面开始创立试验。

登录 Portal
进入 Workflows 页面点击【Schedule a workflow】
抉择 Agent，比方 Self-Agent：
抉择从 Chaos Hub 中增加混沌试验：
设置 Workflow 的名称：
点击 【Add a new experiment】，向 Workflow 中增加混沌试验：
抉择试验 pod-delete：
立刻开始调度：
在 KubeSphere 中能够看到 Pod 被删除重建了：
Portal 界面也能够看到试验胜利了：

点击具体的 Workflow 节点，能够看到具体的日志：
反复下面的步骤，创立混沌试验 pod-cpu-hog：

在 KubeSphere 中能够看到 Pod 的 CPU 使用率曾经靠近 1C：
上面这个试验用来模仿 Pod 网络丢包，开始试验前先把 Nginx 的正本数设为 1：

当初只有一个 Pod，IP 为 10.233.71.170：

上面反复下面的步骤，创立混沌试验 pod-network-loss，并批改丢包率为 50%：

在进入 KubeSphere 界面，在右下角的 工具箱 图标上悬停，而后在弹出菜单中选择 Kubectl。

通过 ping Pod 的 IP 来测试丢包率，能够看到丢包率靠近 50%，试验胜利：

以上所有试验都是针对 Pod 进行的，除了 Pod 之外，还能够对 Node、K8s 组件等各种服务进行试验，感兴趣的读者能够自行测试。

所谓的 Workflow，实际上就是一个混沌试验的工作流，尽管上一节的演示中每一个 Workflow 只有一个试验，但实际上每个 Workflow 都能够设置多个试验，并依照程序执行。

Workflow 是由 CRD 来实现的，能够在 KubeSphere Console 界面中查看该 CRD，这里能够看到之前创立的所有 Workflow：

以 pod-network-loss 为例，来看看有哪些参数：

Workflow 中的每一个试验也是一个 CRD，CRD 名称为 ChaosEngine。

解释一下这外面各个环境变量的含意：

appns: 要执行对象所在的命名空间。
experiments：要执行测试的名称(例如网络提早测试，Pod 删除测试等), 可用 kubectl get chaosexperiments -n test 进行查看反对的 experiments。
chaosServiceAccount：要应用的 sa。
jobCleanUpPolicy: 是否保留执行该次测试的 Job, 字段可选为 delete/retain。
annotationCheck: 是否进行正文查看, 如果不进行查看, 则所有的 Pod 都被进行测试, 字段可选为 true/false。
engineState: 该次测试的状态, 可被设置为 active/stop。
TOTAL_CHAOS_DURATION：混沌测试持续时间, 默认 15s。
CHAOS_INTERVAL：混沌测试工夫距离, 默认 5s。
FORCE：删除 pod 是否应用 –force 选项。
TARGET_CONTAINER: 删除 Pod 外面的某个容器(默认删除第一个)。
PODS_AFFECTED_PERC：测试 Pod 占总数的百分比, 默认是 0(相当于 1 个正本)。
RAMP_TIME：在进行混沌测试前后须要期待的工夫。
SEQUENCE：测试执行策略, 默认是并行 (parallel) 执行, 可被设置为 serial/parallel。

其余各个试验的具体参数这里就不赘述了，感兴趣的读者能够本人查阅相干文档。

本文向大家介绍了混沌工程框架 Litmus 的架构以及在 KubeSphere 上的部署办法，通过一系列混沌试验来验证整个基础设施和服务抵制故障的能力。Litmus 是一个特地优良的混沌工程框架，背地有弱小的社区反对，它的试验商店（即 Chaos Hub）中内置的试验将会越来越多，你能够将这些混沌试验一键部署到集群中制作凌乱，通过可视化界面来直观展现试验后果，验证集群的弹性能力。有了 Litmus 之后，咱们岂但能够直面故障，还能够主动出击制作故障来找出零碎的缺点，防止黑天鹅事件的产生。

Getting Started with Litmus

本文由博客一文多发平台 OpenWrite 公布！

关于云计算:Litmus-实践让群魔在混沌中乱舞看-K8s-能撑到何时

Litmus 架构

Portal 组件

Agent 组件

筹备 KubeSphere 利用模板

多租户架构

创立帐户

创立企业空间

创立我的项目

增加利用仓库

部署 Litmus 管制立体

拜访 Portal 服务

部署 Agent（可选）

创立混沌试验

Workflow 详解

总结

参考资料