面向云原生的混沌工程工具-ChaosBlade

作者 | 肖长军(穹谷)阿里云智能事业群技术专家??

导读:随着云原生系统的演进,如何保障系统的稳定性受到很大的挑战,混沌工程通过反脆弱思想,对系统注入故障,提前发现系统问题,提升系统的容错能力。ChaosBlade 工具可以通过声明式配置执行混沌实验,简单高效。本文将会重点介绍 ChaosBlade 以及云原生相关的实验场景实践。

ChaosBlade 介绍

ChaosBlade 是阿里巴巴开源的一款遵循混沌实验模型的混沌实验执行工具,具有场景丰富度高、简单易用等特点,而且可以很方便的扩展实验场景,开源后不久就被加入到 CNCF Landspace 中,成为主流的一款混沌工具。

实验场景

目前支持的实验场景如下:

  • 基础资源场景:CPU 负载、内存占用、磁盘 IO 负载、磁盘占用、网络延迟、网络丢包、网络屏蔽、域名不可访问、shell 脚本篡改、杀进程、进程 Hang、机器重启等;
  • 应用服务场景:支持 Java 应用和 C++ 应用内的实验场景。Java 的场景组件丰富,例如支持 Dubbo、RocketMQ、HttpClient、Servlet、Druid等,而且支持编写 Java 或 Groovy 脚本实现复杂的实验场景;
  • 容器服务场景:支持 Kubernetes 和 Docker 服务,包含 node、pod 和 container 三种资源的实验场景,例如 Pod 网络延迟、丢包等。

混沌实验模型

以上所有的实验场景都遵循混沌实验模型,此模型共分为四层,包含:

  • Target:实验靶点。指实验发生的组件,如容器、应用框架(Dubbo、Redis)等;
  • Scope:实验实施的范围。指具体触发实验的机器或者集群等;
  • Matcher:实验规则匹配器。根据所配置的 Target,定义相关的实验匹配规则,可以配置多个。由于每个 Target 可能有各自特殊的匹配条件,比如 RPC 领域的 Dubbo,可以根据服务提供者提供的服务和服务消费者调用的服务进行匹配,缓存领域的 Redis,可以根据 set、get 操作进行匹配;
  • Action:指实验模拟的具体场景,Target 不同,实施的场景也不一样,比如磁盘,可以演练磁盘满,磁盘 IO 读写高等。如果是应用,可以抽象出延迟、异常、返回指定值(错误码、大对象等)、参数篡改、重复调用等实验场景。

比如一台 IP 是 10.0.0.1 机器上的应用,调用 com.example.HelloService[@1.0.0 ]() Dubbo 服务延迟 3s,基于此模型可以描述为对 Dubbo 组件(Target)进行实验,实验实施的范围是 10.0.0.1 主机(Scope),调用 com.example.HelloService[@1.0.0 ]() (Matcher)服务延迟 3s(Action),对应的 chaosblade 命令为:

blade create dubbo delay --time 3000 --service com.example.HelloService --version 1.0.0

所以此模型很简单清晰的表达出实验场景,易于理解。下文中的云原生实验场景也基于此模型定义。

面向云原生的实验场景

实现方案

将混沌实验场景按照上述的实验模型,定义为 Kubernetes 中的资源,并通过自定义控制器来管理,可以通过 Yaml 配置或者直接执行 blade 命令执行。

ChaosBlade Operator 定义了资源控制器,并且会以 daemonset 的方式,在每个节点上部署一个 chaosblade-tool pod 来执行混沌实验。不同的实验场景内部实现方式不同,比如 Node 实验场景,其上面部署的 chaosblade-tool 内部执行即可,而 Container 内的实验场景,控制器会将 chaosblade 包拷贝到目标 Container 中执行。

使用方式

安装必要组件

安装 ChaosBlade Operator,可通过地址下载 chaosblade-operator-0.0.1.tgz,使用以下命令安装:

helm install --namespace kube-system --name chaosblade-operator chaosblade-operator-0.0.1.tgz

安装在 kube-system 命令空间下。ChaosBlade Operator 启动后会在每个节点部署 chaosblade-tool Pod 和一个 chaosblade-operator Pod。可通过以下命令查看安装结果:

kubectl get pod -n kube-system -o wide | grep chaosblade

执行实验

执行方式有两种:

  • 一种是通过配置 yaml 方式,使用 kubectl 执行;
  • 另一种是直接使用 chaosblade 包中的 blade 命令执行。

下面以指定一台节点,做 CPU 负载 80% 实验举例。

yaml 配置方式

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: cpu-load
spec:
  experiments:
  - scope: node
    target: cpu
    action: fullload
    desc: "increase node cpu load by names"
    matchers:
    - name: names
      value:
      - "cn-hangzhou.192.168.0.205"
    - name: cpu-percent
      value:
      - "80"

如上所示,配置好文件后,保存为 chaosblade_cpu_load.yaml,使用以下命令执行实验场景:

kubectl apply -f chaosblade_cpu_load.yaml

可通过以下命令查看每个实验的执行状态:

kubectl get blade cpu-load -o json

查看更多实验场景配置事例

blade 命令执行方式

下载 chaosblade 工具包,解压即可使用。还是上述例子,使用 blade 命令执行如下:

blade create k8s node-cpu fullload --names cn-hangzhou.192.168.0.205 --cpu-percent 80 --kubeconfig ~/.kube/config

使用 blade 命令执行,会返回实验的执行结果。

修改实验

yaml 配置文件的方式支持场景动态修改,比如将上述的 cpu 负载调整为 60%,则只需将上述 value 的值从 80 改为 60 即可,例如:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: cpu-load
spec:
  experiments:
  - scope: node
    target: cpu
    action: load
    desc: "cpu load"
    flags:
    - name: cpu-percent
      value: "60"
    - name: ip
      value: 192.168.0.34

然后使用 kubeclt apply -f chaosblade_cpu_load.yaml 命令执行更新即可。

停止实验

可以通过以下三种方式停止实验:

根据实验资源名停止

比如上述 cpu-load 场景,可以执行以下命令停止实验:

kubectl delete chaosblade cpu-load

通过 yaml 配置文件停止

指定上述创建好的 yaml 文件进行删除,命令如下:

kubectl delete -f chaosblade_cpu_load.yaml

通过 blade 命令停止

此方式仅限使用 blade 创建的实验,使用以下命令停止:

blade destroy <UID>

是执行 blade create 命令返回的结果,如果忘记,可使用 blade status --type create 命令查询。

卸载 chaosblade operator

执行 helm del --purge chaosblade-operator 卸载即可,将会停止全部实验,删除所有创建的资源。

总结

ChaosBlade 基于混沌实验模型,友好地将 Kubernetes 资源控制结合,部署简单而且使用简洁,实验可控。除此之外 ChaosBlade 基于实验模型实现了很多领域场景执行器,可以很方便的扩展实验场景,可详见附录中的项目列表。

社区共建

ChaosBlade 自开源以来,共有近 30 多位贡献者加入和很多企业×××常感谢各位。同时非常欢迎更多的人参与进来,使 ChaosBlade 变的更加强大,覆盖更多的场景,成为各个企业稳定的、通用的混沌工程工具。

贡献的形式可以是提 bug、提交代码、编写文档、补充单元测试、参与问题讨论等等。ChaosBlade 相信:开源世界中,任何帮助都是贡献。

附录

项目列表如下:

“ 阿里巴巴云×××icloudnative×××erverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发×××

原文地址:https://blog.51cto.com/13778063/2447968

时间: 2024-11-08 20:46:20

面向云原生的混沌工程工具-ChaosBlade的相关文章

2020云原生7大趋势预测!

2020云原生7大趋势预测! 过去的几年,是云原生技术和理念得到广泛接受的几年.在这个快速发展的领域,预测未来显得尤其困难,但是我们又有着一些坚定的信念,相信以开放创新为支撑的云原生领域会持续重塑软件生命周期,带来不断的价值. 2019,在众多热门技术趋势中,云原生的关注度居高不下,很多开发者都对由此而兴起的一众技术十分追捧,众多企业开始探索云原生架构转型落地.在中国,开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变. 在筹备阿里云首届云原生实践峰会的过程中,我们展开了对云原生技

360&#176;透视:云原生架构及设计原则

欢迎访问网易云社区,了解更多网易技术产品运营经验. 云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今.这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps.持续交付(Continuous Delivery).微服务(MicroServices).敏捷基础设施(Agile Infrastructure)和12要素(TheTwelve-Factor

云原生存储和云存储有什么区别?

作者 |?李鹏(壮怀) 阿里云智能事业群高级技术专家 导读:新的企业负载/智能工作负载容器化.迁云.存储方面遇到的性能.弹性.高可用.加密.隔离.可观测性以及生命周期等方面的问题,不但需要存储产品层次的改进,更需要在云原生的控制/数据平面的改进,推进云原生存储和云存储的演进.本文将介绍一下问题场景,探讨可行的解决方案,最终得出云原生存储以及云存储目前可以做什么和未来还需要做什么. 引言 最近有幸参加了由 Infra Meetup 联合 Kubernetes & Cloud Native Meet

VMware 完成 27 亿美元的 Pivotal 收购 | 云原生生态周报 Vol. 34

作者 | 汪萌海.王思宇.李鹏 业界要闻 VMware 完成 27 亿美元的?Pivotal 收购 VMware 在 12 月 30 日宣布,已完成 27 亿美元的 Pivotal 收购,同一天 Pivotal 也已被纽约股市除名,成为 VMware 的子公司. 谷歌发布 BeyondCorp 的白皮书 BeyondCorp 是一个"零信任"安全框架,它将访问控制从外围转移到单个设备和用户,允许员工在任何位置安全地工作,而不需要传统的虚拟专用网络.使用 BeyondProd,谷歌实现了

阿里巴巴的云原生与开发者

作者 | 李响 阿里云资深技术专家 关注"阿里巴巴云原生"公众号,回复关键词"容器",可下载云栖大会容器专场全部 PPT 摘要:利用云原生技术构建应用简便快捷,部署应用轻松自如,运行应用按需伸缩.如今,云原生已经成为下一代技术发展的趋势.在?2019?杭州云栖大会开发者峰会上,阿里巴巴资深技术专家李响就为大家分享了阿里巴巴的云原生技术与开发者的那些故事. 为什么选择云原生? 云原生的本质目标就是充分释放云计算带来的红利,阿里巴巴希望开发者能够使用云上极致弹性的资源交

双11 背后的全链路可观测性:阿里巴巴鹰眼在“云原生时代”的全面升级

点击下载<不一样的 双11 技术:阿里巴巴经济体云原生实践> 本文节选自<不一样的 双11 技术:阿里巴巴经济体云原生实践>一书,点击上方图片即可下载! 作者: 周小帆(承嗣)? 阿里云中间件技术部高级技术专家 王华锋(水彧)??阿里云中间件技术部技术专家 徐彤(绍宽)??阿里云中间件技术部技术专家 夏明(涯海)??阿里云中间件技术部技术专家 导读:作为一支深耕多年链路追踪技术 (Tracing) 与性能管理服务 (APM) 的团队,阿里巴巴中间件鹰眼团队的工程师们见证了阿里巴巴基

混沌工程-初识

公司新成立了一个稳定性团队,20年的重要目标之一就是开展混沌工程.为了后续更好的开展工作,记录关于“混沌工程”相关的知识以及工程实践. 内容来源:<混沌工程:Netflix系统稳定性之道>摘录以及个人思考总结...... 概要 定义:主动发现系统中脆弱点的一整套方法论. 目的:如何让系统在不确定性中获益? 接受“系统越复杂,越脆弱”的事实,让系统在每一次失败中获益,然后不断进化. 在实践中,用一系列的实验来真实的验证系统在各类故障场景下的表现,通过频繁大量的实验,使得系统本身的“反脆弱性”持续

从 SOA 到微服务,企业分布式应用架构在云原生时代如何重塑?

作者 | 易立 阿里云资深技术专家 导读:从十余年前的各种分布式系统研发到现在的容器云,从支撑原有业务到孵化各个新业务,企业的发展离不开统一的.与时俱进的技术架构.本篇文章从企业分布式应用架构层面介绍了云原生计算架构带来的变化,希望能够帮助更多企业的 IT 转型,利用云计算技术推动其成为市场竞争中的敏捷力量. 进入 21 世纪以来,我们见证了企业分布式应用架构从 SOA(Service-oriented Architecture),到微服务架构,再到云原生应用架构的演化. 为了说明企业架构演化背

CNCF官方大使张磊:什么是云原生?

作者|张磊 阿里云容器平台高级技术专家,CNCF 官方大使 编者说: 从 2015 年 Google 牵头成立 CNCF 以来,云原生技术开始进入公众的视线并取得快速的发展,到 2018 年包括 Google.AWS.Azure.Alibaba Cloud 等大型云计算供应商都加入了云原生基金会?CNCF,云原生技术也从原来的应用容器化发展出包括容器.Service Mesh.微服务.不可变基础设施.Serverless.FaaS 等众多技术方向,CFCF 旗下也囊括了越来多的开源项目. Kub