在 Ali Kubernetes 系统中,我们这样实践混沌工程

  1. 云栖社区>
  2. 博客>
  3. 正文

在 Ali Kubernetes 系统中,我们这样实践混沌工程

jessie筱姜 2019-03-13 15:39:32 浏览568 评论0

摘要: 作者| 阿里云智能事业群高级测试开发工程师 智妍 在传统的软件测试中,我们通常通过一个给定的条件来判断系统的反馈,通过断言来判断是否符合预期,测试条件和结果通常比较明确和固定。而混沌工程,是通过注入一些“不确定”因素,象放进了一群淘气的猴子,在系统资源、可用性、安全性、延迟、压力等方面进行捣乱,而此过程中,要求系统可以毫无影响的提供服务,用户无感知。


作者| 阿里云智能事业群高级测试开发工程师 智妍


在传统的软件测试中,我们通常通过一个给定的条件来判断系统的反馈,通过断言来判断是否符合预期,测试条件和结果通常比较明确和固定。而混沌工程,是通过注入一些“不确定”因素,象放进了一群淘气的猴子,在系统资源、可用性、安全性、延迟、压力等方面进行捣乱,而此过程中,要求系统可以毫无影响的提供服务,用户无感知。


这其实对系统的自愈能力,健壮性都有很高的要求。故障注入一般是指比较受控的一些实验条件,通过注入一些相对极端的异常场景,为系统提供可靠性测试的过程。 整体来说,混沌是一种故障注入规则,强调了一些不确定性、随机性,比较常见的"猴子"有 Netflix 的"猴子军团",可以用来随机关闭系统实例,注入延时,回收资源,检查安全漏洞等等。

开源工具介绍

除了一般系统的 monkey,基于 Kubernetes 已经有一些"猴子"工具可以测试系统的健壮性。接下来,介绍一下比较常见的三种 Kubernetes monkey:

kube-monkey

https://github.com/asobti/kube-monkey

  • 运行方式:kube-monkey 通过 label 设置受害者 pod,创建了一个单独的 kube-monkey pod 对受害者 pod 施加影响;
  • 注入类型:目前支持的故障注入类型仅有杀容器;
  • 配置项:可以通过配置文件设置运行周期和频率,在一定时间内随机的杀死打标范围内的 pod。

powerfulseal

https://github.com/bloomberg/powerfulseal

  • 注入类型:powerfulseal 的故障注入类型包括杀 pod 和启停 node。
  • 运行方式:包括交互模式,自动模式、打标模式和示例模式。交互模式通过界面交互查询node/namespace/pod,启停 node 或杀死 pod 操作;自动模式通过读取配置文件确定注入范围,注入频率;打标模式通过给 pod 打标确定注入的靶向 pod 及注入频率;示例模式可以反映根据使用资源情况进行故障注入的过程。

Chaos Toolkit-kubernetes

https://github.com/chaostoolkit/chaostoolkit-kubernetes
/>
是 chaos 工具包中的一个,通过 chaos run experiment.json 设置 json 文件来指定 namespace,正则匹配名字等等来随机杀一个 pod。


以上三种"猴子",主要是基于杀 pod 场景来注入故障,虽然是最有力的场面但是比较有局限性,对于商业化系统面临的复杂场景,是值得参考但是不够的。

结合 Ali Kubernetes 故障场景分析


Ali Kubernetes 作为一个管理大规模集群的商业调度系统,需要应对的不仅包括一些基本的 Kubernetes 中 pod 误删误停的故障现象,也包含一些底层 OS、内核、网络、误配置等灾难场景。同时由于其支撑业务生态的复杂性,全链路综合异常流也需要特殊的验证。


为更系统的进行演练,在过程中主要进行了以下几部分工作:



1


FMEA 分析就是失效模式和效果分析,旨在对系统范围内潜在的失效模式加以分析,以便按照严重程度加以分类,或者确定失效对于该系统的影响。
从故障场景上,分析得出较为符合 Ali Kubernetes 的三大类场景:

  • 通用故障场景:包括网络相关故障(网络 iohang ,断网,网络延迟等),宿主机相关故障(机器重启,机器 load 高等)
  • Ali Kubernetes 业务场景故障:包括 Kubernetes 相关的故障(pod 删除,pod patch等),pod 迁移,混部、etcd 等业务相关场景;
  • chaos 故障:较为随机的故障注入,可以为以上任何故障的组合


从影响面上,需要 case by case 确定影响范围为无任何影响,仅影响部分功能,影响核心功能等等;从验证恢复手段上,也可以分为自动恢复、手动恢复,同时需要关注监控情况及恢复时间。


在分析过程中,我们发现,已有的开源工具无法完全满足 Ali Kubernetes 的故障场景。下面举 2 个典型故障场景:

pod 被误删

这个场景并不是简单的 pod 随机删除,而是在 kubelet 连错 apiserver 配置等异常情况下,重启 ali-kubelet 后,al 自行判断了容器在当前集群内不存在,自己做了删除操作。
要引入这个故障需要修改 kubelet 组件的配置,重启 kubelet,才算是真正引入了故障,而当前的无论是 kube-monkey 还是 powerfulseal 场景都无法满足。

master 组件断网

有的人可能会说,直接指定 master 组件的机器引入断网操作,是不是就可以了呢?然鹅现实是比较骨感的,我们也许只知道这个 master 所在集群的 kubeconfig,组件的机器其实也可以随着每次升级变动的。在仅仅已知 kubeconfig 的情况下我们只能先查一下 master 组件的机器信息,再在机器上引入断网的操作,才算是一个整体的故障引入。而目前所有的开源工具也没有此类稍微复杂一些的场景,只是通过指定 pod namespace 来随机的删除一些 pod。
所以综上所述,其实我们需要对此进行扩展开发,除了简单的杀 pod,我们亟需一套可以自由开发的小程序,把这个步骤拼接起来,进行更为复杂的故障注入。


套件实现


为了满足此类复杂的故障注入,我们使用了目前集团内正在开发的一套故障注入系统 monkeyking,并在它的基础上扩展了一些 kubernetes 相关的套件,来达到既可以注入 kubernetes 相关的故障,又可以注入一些通用故障,同时又可以相对自由的扩展故障集合的目的。


这个故障注入的演练流程如下图所示:



2


它的每一个步骤都可以是我们自由扩展的一个或者多个小程序,各个小程序之间的执行顺序也可以自由的定义。考虑到 Ali Kubernetes 的场景,我们在其中扩展了四大类小程序套件。

通用故障小程序

在这一部分主要实现了一些比较通用的 os 故障,网络故障,比如最基本的指定一个宿主机断网,指定宿主机重启这类。

Kubernetes 套件小程序

这一部分主要实现了一些通用的 Kubernetes 命令,通过指定这些命令和入参,我们可以执行比如 create delete apply patch 这些操作,来间接的达到注入一些 Kubernetes 相关故障的目的。
实现原理如下:




要点说明如下:

  • 下载集群证书的地址及证书的 md5 码都作为小程序的输入,在执行实际的 kubectl 生效命令前进行下载校验;
  • 底层 toolkit 中已经加入了 kubectl 命令行工具,无需自己找环境进行配置和下载;
  • 目前已经支持了 apply,create,delete,patch,get 操作,支持指定 label,namespace,-o json 的操作


举个例子,上文中 master 组件故障的场景中,我们就可以利用以上的两类小程序来完成故障注入的操作:

3

开源工具小程序

目前我们和集团安全生产的 MonkeyKing 团队合作,联合在故障注入平台 monkeyking 中集成了开源工具 kube-monkey,实现过程借助了上文的 kubernetes 套件执行,可以通过打标的方式标记受害者,让 kube-monkey 随机的杀受害者 pod。步骤如下:

环境准备

  • 锁演练环境
  • 在当前集群中初始化kube-monkey: 使用kubernetes套件的apply功能提交km-config.yaml文件,部署 kube-monkey deployment

**

给应用标记受害者 label

  • 使用 Kubernetes 套件的 patch 功能,标记受害者

**

验证步骤

  • 自定义组件校验应用服务是否可用

**

故障恢复

  • 使用 Kubernetes 套件的 patch 功能,给受害者去标
  • 使用 Kubernetes 套件的 delete 功能,删除 kube-monkey deployment
  • 解锁演练环境


其他业务相关小程序

这一部分比较自由,主要根据 Ali Kubernetes 的业务需求,接入了一些常用的小程序。


比如故障演练过程中,环境需要独占,不允许其他测试执行,在这里实现了一个小程序用来对环境进行加解锁操作;比如校验阶段需要验证服务是否可用,这里实现了一个通过 curl 命令校验返回值的方式验证服务是否可用的小程序;比如故障注入过程可能影响vip挂载,这里也实现了一个调用 vip 服务校验 vip 下 ip 数量及是否可用的小程序。


总结


在 Ali Kubernetes 中,我们将故障以场景化的方式进行沉淀,将底层 os,内核、网络、误配置等故障联合 Kubernetes 相关故障,引入混沌工程的理念进行注入,有效的发现了很多系统稳定性问题,驱动开发人员更多关注系统健壮性。


后续我们会在 Ali Kubernetes  演进过程中持续发力,基于架构和业务场景输入更多 Kubernetes 相关的故障场景,为系统的高可用保驾护航。


【云栖快讯】一站式开发者服务,海量学习资源免费学  详情请点击

网友评论