大规模 Kubernetes 集群故障注入的利器-ChaosBlade-六虎

作者：叶飞

ChaosBlade

跟着云原生的发展，云原生运用一致性、可靠性、灵活编列的才干让大部分企业选择将运用往云上迁移，但一起云基础设施在安稳性、可观测、也承受的强壮的检测。

ChaosBlade 是阿里巴巴开源的一款遵从混沌工程原理和混沌试验模型的试验注入东西，协助企业提高分布式体系的容错才干，并且在企业上云或往云原生体系迁移进程中事务连续性确保。

ChaosBlade Operator 是 kubernetes 渠道试验场景的完成，将混沌试验经过 Kubernetes 标准的 CRD 方法界说，很便利的运用 Kubernetes 资源操作的方法来创立、更新、删去试验场景，包含运用 kubectl、client-go 等方法履行，一起也可以运用 chaosblade cli 东西履行。

本文将首要介绍 ChaosBlade 在 Kubernetes 中毛病注入的底层完成原理、版别优化进程以及大规划运用演练测试。

资源模型

在 Kubernetes 中布置运用，一般咱们会选择将运用界说为 Pod、Deployment、Statefulset 等资源类型，这些都是 Kubernetes 现已内置的；在实践运用中，面对对杂乱的运用场景，内置的资源类型是无法满足咱们需求的，Operator 是一种解决杂乱运用容器化的一种计划，经过自界说资源和自界说操控器来完成杂乱运用容器化，chaosblade-operator 正是便是基于 Operator 完成的。

在 Kubernetes 中装置完 chaosblade-operator 后，会生成一个 deployment 资源类型的 chaosblade-operator 实例、一个 daemonset 资源类型的 chaosblade-tool 实例、一个自界说资源界说，当然还包含 RABC、SA 等等其他资源；

chaosblade 将自界说资源类型界说为 chaosblade ，简称 blade ；每次新建演练就可以经过 kubectl 或许 chaosblade cli 创立 blade 实例资源，blade 资源自身也包含了 chaosblade 混沌试验界说；

chaosblade-operator 会监听 blade 资源的生命周期，当发现有 blade 资源实例被创立时，一起就能拿到混沌试验界说，然后解析试验界说，去调用 chaosblade-tool 真实的注入毛病；

chaosblade-tool 是 daemonset 资源类型，一个 Node 节点必定会布置一个 Pod，从 Linux Namespace 的维度动身，该 Pod 网络、PID 命名空间与 Node 节点处在同一命名空间，因而可以做到部分 Node 等级的演练。

生命周期

在资源模型中，简略提到了 chaosblade-operator 会监听 blade 资源的创立；chaosblade-operator 实则会监听整个 blade 资源的生命周期，blade 资源的生命周期等同演练试验生命周期；chaosblade-operator 会依据 blade 资源状况去更新试验的状况

blade 资源状况	试验进程	CPU 负载事例
apply(新建)	新建演练	新建 CPU 负载演练
running(运转中)	演练运转中	CPU 负载中
deleted(被删去)	康复演练	康复演练

毛病注入

在资源模型中提到了 chaosblade-operator 发现有 blade 资源实例被创立时，一起就能拿到混沌试验界说，然后解析试验界说，去真实的注入毛病；那么 chaosblade-operator 是如去真实的注入毛病呢？

其实在前期的 chaosblade-operator 版别中，大部分场景是经过将 chaosblade cli 东西经过 kubenetes API 通道仿制到容器内部，然后再去容器内部履行指令来完成毛病注入，全体完成计划入下图；

可以看到左面的 yaml 界说便是 Chaosblade 混沌试验模型界说，也是 blade 资源实例的一部分信息，当 blade 资源经过 kubectl apply 今后，chaosblade-operator 会监听到资源的创立，一起解析到试验界说；

当解析道 scope = node 的时分，会找到 node 节点所在 chaosblade-tool pod 中履行指令，这些动作简直对整个集群来说资源耗费也是很少的；

可是当解析道 scope = pod 或许 scope = container 的时分，大部分场景 chaosblade-operator 会把 chaosblade cli 东西自身仿制到事务容器内部，然后再去事务容器履行指令，东西包的巨细、试验选择的容器数量、决定了资源的耗费巨细，往往兼容性、版别更新等等都得不到很好的确保；

在新版别的 chaosblade-operator 版别中，将在下面开始的问题、优化进程、完成原理等小节详细介绍。

开始的痛点

当一个云原生运用到达一定规划时，去进行演练；

集群环境：1000 个 node 节点
方针运用：deployment 有 5000 个副本数
演练场景：对该运用对外供给的接口返回推迟 1000 毫秒

注入慢

首要需求找到 5000 个副本，将东西仿制到容器，在进入容器履行指令，假定一个仿制东西耗费 100 毫秒，那么整个进程耗费时刻 500000 毫秒，这对用户来说简直是不行承受的。

网络带宽占用

将东西仿制到容器，至少需求调用 kubernetes api 5000次，假定一个可执文件巨细 5MB , 5000 次需求占用总带宽流量 5000×5=25000MB ，对 IO 影响简直便是灾祸等级的；

兼容性问题

假定咱们现现已过层层检测，现已东西将东西仿制进去，当东西自身依靠了依靠一些指令，比方网络（tc）、磁盘（dd）等容器中又没有这些指令，或许版别不兼容改怎么处理？

只读 Pod

关于配置了只读文件体系的 Pod，文件是不行写入的，因而压根就没发将东西仿制进去

侵入型

将东西留在事务容器内部，等同于将东西生命周期与容器绑定在一起；

优化进程

在开始版别的迭代进程咱们做过许多优化，同步转异步、包减肥、按需仿制等等优化计划，尽管一定程度上提高了注入的功率，可是没有解决问题的实质，还是受限于主机的 IO 功能；

不管是同步转异步、包减肥、按需仿制等优化计划，实质无法解决东西仿制带来的一些问题；羊毛出在羊身上，解决问题就得解决问题的实质，从 Linux 虚拟化技能的视点考虑，怎么不仿制东西就在能容器中注入毛病呢？

Linux 虚拟化

关于 Linux 虚拟化技能而言，核心完成原理便是 Linux Namespace 的阻隔才干、Linux Cgroups 的约束才干，以及基于 rootfs 的文件体系；

Linux Namespace 可以让进程（容器）处在一个独立的沙箱环境，Linux Cgroups 可以约束该沙箱内进程的资源运用，比方约束 CPU、内存的运用率等等；

Linux Cgroups

Linux Cgroups 可以约束沙箱内进程的资源运用，并且也可以人为将某个进程的资源运用交给现已存在的某个的 Linux Cgroups 操控，而一般容器的资源运用率计算也是 Linux Cgroups 操控组下面进程的运用状况计算出来的；此刻在宿主机发动的一个 CPU 负载的进程，并且将改进程交给某个现已存在的容器的操控组操控，就相当于给该容器注入了 CPU 负载场景。

在 docker 上面测验在不侵入该容器的状况下，给容器 nginx 注入 CPU 负载的场景。首要发动一个 nginx 容器 docker run -it -d -p 8087:80 –cpus 0 –name nginx nginx，容器发动后 docker 会给该容器新建一个 Cgroups 操控组，在改指令中会约束该容器只能运用一个核心的 CPU 。

找到容器的进程 PID，该进程是容器发动时第一个进程

docker inspect --format "{{.State.Pid}}" nginx

检查进程的 Cgroups 操控组，可以看到有 CPU、内存、blkio 等等许多 Cgroup 子体系

cat /proc/$(docker inspect --format "{{.State.Pid}}" nginx)/cgroup
11:devices:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
10:blkio:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
9:pids:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
8:memory:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
7:freezer:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
6:perf_event:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
5:cpuset:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
4:hugetlb:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
3:cpuacct,cpu:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
2:net_prio,net_cls:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa
1:name=systemd:/docker/4bcf3de8de2904b3308d8fc8dbdf6155cad7763fa108a32e538402156b6eacaa

检查 CPU 操控组进程列表，可以有许多进程受该容器 Cgroup CPU 子体系操控；依照这个思路，咱们只需求发动一个 CPU 负载进程，并且将进程 PID 写入这个文件，就可以做到容器 CPU 注入；

cat /sys/fs/cgroup/cpu$(cat /proc/$(docker inspect --format "{{.State.Pid}}" nginx)/cgroup | head -n 1 | awk -F ':' '{print $3}')/tas
ks
7921
7980
7981
7982
7983

CPU 负载脚本

#! /bin/bash
while [ 1 ]
do
        echo "" > /dev/null
done

履行 CPU 负载脚本后找到 PID ，将进程写入容器进程列表文件

echo PID >> /sys/fs/cgroup/cpu$(cat /proc/$(docker inspect --format "{{.State.Pid}}" nginx)/cgroup | head -n 1 | awk -F ':' '{print $3}')/tas
ks

此刻可以调查到容器 CPU 到达 100%，而宿主机未到达，说明 CPU 负载只对容器产生了作用，运用相同的方法，可以做到资源占用形的任何毛病场景，比方内存、IO 等。

终究成功在不侵入该容器的状况下，给该容器注入 CPU 负载的场景。经过 Cgroups 操控组，还能做到其他 Cgroups 支撑的子体系的场景注入，比方 CPU 高负载、内存占用高、IO 高负载等等；

Linux Namespace

经过 Linux Cgroups 做到了不侵入该容器的状况下，给该容器注入 CPU 负载的场景，一起也能支撑CPU 高负载、内存占用高、IO 高负载等等；关于其他类型的毛病，比方网络延时、文件删去等等，则需求经过别的一种方法来完成，便是 Linux Namespace 的阻隔才干。

Linux Namespace 网络、IPC、MNT 等命名空间阻隔的才干，在容器独立的 Namespace 下，新建一个文件，新发动一个进程等等操作也是其他容器不行感知和观测到的；

在 docker 上面测验在不侵入该容器的状况下，给 nginx 容器注入网络延时的场景。首要发动一个 nginx 容器 docker run -it -d -p 8087:80 –cpus 0 –name nginx nginx，在宿主机开放端口 8080 代理到容器内 80 端口，容器发动后会有独立的网络命名空间，监听 80 端口。

1）宿主机网络延时

TC (TrafficControl) 用于Linux内核的流量操控，可以做到网络延时、丢包等等，先测验利用 TC 在宿主机上注入网络延时，比方需求注入一个网络延时 100ms 的场景，在宿主机上履行如下指令

#延时
tc qdisc add dev eth0 root netem delay 100ms

此刻在客户端翻开浏览器访问 http://IP:8087会检查到有安稳 100ms 的延时，而仔细观测后会发现其他端口也会有延时，比方 22、3306 等等；（留意，只能在别的客户端机器访问，不能在直接在当前机器经过 curl http://127.0.0.1:8087验证）

#  康复
tc qdisc del dev eth0 root

2）容器内网络延时

怎么在容器中注入一个网络延时呢？其实非常简略，Linux 供给了 setns() 函数，可以便利进入指定进程所在命名空间；假如注入网络延时，只需求进入方针容器的网络命名空间即可；

找到容器的进程

docker inspect --format "{{.State.Pid}}" nginx

进入容器所在命名空间，nsenter 指令终究会调用 setns() 函数，假如没有此指令，需求装置 util-linux 包

nsenter -t 7921 -n

此刻检查 IP 相关信息，返回的则是容器内 IP 相关信息

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
124: eth0@if125: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:13 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.19/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

注入网络延时也只会对容器收效

tc qdisc add dev eth0 root netem delay 100ms

此刻在客户端翻开浏览器访问 http://IP:8087会检查到有安稳 100ms 的延时，可是并不会对其他端口收效，比方 22、3306 等等；由于实践延时自身是作用在容器网络命名空间内，并且不会对宿主机收效。

终究成功在不侵入该容器的状况下，给该容器注入网络延时的毛病场景。LInux 供给了许多维度的命名空间阻隔，并且答应参加任何类型的命名空间，经过 Linux Namespace ，还能做到文件删去、杀进程等等场景。

ChaosBlade 完成

在 Chaosblade 1.6.x 版别现现已过 Linux Namespace 的阻隔才干、Linux Cgroups 的约束才干完成容器化毛病注入，chaosblade-operator 首要负责监听 crd 资源状况改变，chaosblade-operator 不在去履行毛病注入的操作，并且由作为 dasemonset 类型资源 chaosblade-tool 首要负责真实的注入毛病，全体完成计划如下图：

同理可以看到左面的 yaml 界说便是 Chaosblade 混沌试验模型界说，也是 blade 资源实例的一部分信息，当 blade 资源经过 kubectl apply 今后，chaosblade-operator 会监听到资源的创立，一起解析到试验界说；

当解析到 scope = node 的时分，会找到 node 节点所在 chaosblade-tool pod 中履行指令，这些动作简直对整个集群来说资源耗费也是很少的，这部分和前期版别简直是没有任何差异的；

可是当解析道 scope = pod 或许 scope = container 的时分， chaosblade-operator 并不会把 chaosblade cli 东西自身仿制到事务容器内部，更不会去容器里边履行相关指令，极大的减少了对 kubernetes API 的依靠；那么 chaosblade-operator 究竟是怎么做的呢？chaosblade-operator 仅仅经过 kubernetes API 找到试验方针，即方针事务 Pod，然后继续找到方针事务 Pod 所在的节点上布置的 chaosblade-tool pod ，解析 Pod 里边的容器名称，最后封装指令直接在 chaosblade-tool 履行指令，去真实的履行毛病注入；在 chaosblade-tool 层注入毛病的时分现已没有 Pod 的概念，这一层是 chaosblade-operator 去解析和封装的；

为安在方针事务 Pod 所在的节点上布置的 chaosblade-tool 履行指令，可以直接对方针事务 Pod 收效呢？假如你仔细阅读了之前 Linux 虚拟化章节，相信你现已有了答案；chaosblade-tool 作为 daemonset 资源，具有宿主机 PID 指令空间切换的才干，一起在资源界说时也现已宿主机将 /sys/fs 目录挂载进 chaosblade-tool pod，使得 chaosblade-tool 可以自由更改进程的 cgroups 操控组；所以 chaosblade-tool 可以对改宿主机上恣意容器注入毛病，将 chaosblade-operator 的一部分工作剥离了出来，运用 chaosblade-operator 的职责更简略一且轻量级，契合开始的设计理论；

Chaosblade-tool 经过 Linux Namespace 的阻隔才干、Linux Cgroups 的约束才干完成容器化毛病注入，不论是功能、兼容性、安稳性都有极大的提高；由于大部分场景是可以直接 chaosblade-tool 履行的，只需确保 chaosblade-tool 容器依靠库版别和指令可以支撑演练，就不会存在兼容性、安稳性等问题；就比方在早上的版别中，咱们甚至需求考虑方针事务容器中没有 dd、tc 指令怎么，或许 dd 版别指令不兼容又怎么办等等问题。

不管 kubernetes 运用 docker、contained、crio 或许其他容器运转时相关技能，Chaosblade 都能做到快速兼容，由于 Chaosblade 经过 Linux Namespace 的阻隔才干、Linux Cgroups 的约束才干完成容器化毛病注入，对容器运转时相关的 API 依靠并不大，只需求找到容器 1 号进程即可；

场景剖析

首要先从 chaosblade 支撑的毛病场景动身，基于进程纬度毛病注入的方法可以分为两类：资源占用和状况改变。

资源占用：注入的方法很容易了解，经过运转可继续占用资源的进程，并且确保进程的继续运转，来到达占用体系资源的目的，经过有 CPU 满载、内存满载、磁盘IO负载、端口占用等；

状况改变：注入的方法或许不是那么贴切，此“状况”可以了解为磁盘可用巨细、文件权限、POD 状况等等，完成这种类型的毛病注入，咱们需求经过运转一个进程来打包修正方针资源的状况即可，当然【状况改变】的方法也有或许进程需求运转很长时刻来完成，与【资源占用】不同的时，他是需求一个终态来完成毛病的注入，即进程履行成功，而不是需求确保进程的继续运转。

将 chaosblade 支撑的毛病场景分类，得下如下表格：

在资源占用的毛病注入形式下，需求判断资源是否是宿主机等级共享的，并且是 Linux Cgroups 现已支撑的子体系，比方 CPU、内存、磁盘IO 等等，只需求进入方针容器进程的 PID 指令空间，然后参加方针容器进程操控组即完成毛病注入；也有比较特别的，比方网络端口占用，尽管它被列为属于资源占用的毛病注入形式，可是端口是独立命名空间内共享的资源，所以他是需求经过 NET 命名空间切换才干完成的。

在状况改变的毛病注入形式下，经过需求依据详细场景，进入方针容器进程的指令空间去做一些操作，比方网络场景，需求进入 NET Namespace；文件场景需求进入 MNT Namespace 等等。

在 chaosblade-1.6.x 版别下，也现已供给命名空间切换的完成，比方进入容器（进程 PID 是 35941）命名空间履行 ls 指令：

结合场景的注入形式以及 Linux Namespace 的阻隔才干、Linux Cgroups 的约束才干，大都是状况下都能剖析出场景应该经过什么样的方法在容器注入毛病；

大规划运用演练

在 Chaosblade 1.6.x 版别现现已过 Linux Namespace 的阻隔才干、Linux Cgroups 的约束才干完成容器化毛病注入，相比经过东西仿制的方法，功率提高显著、兼容性更强、并且无侵入。

在此章节经过实践场景来观测 chaosblade-operator 前期版别和 Chaosblade chaosblade-operator 1.6.x 版别的注入功能和资源耗费状况。

试验事例

分别在 kubernetes 布置 chaosblade-operator 1.5.0 版别和 chaosblade-operator 1.6.1版别，分三次试验，注入 CPU load 场景来调查注入功能、磁盘IO、网络带宽；

在 kubernetes 中布置 tomcat deployment 资源类型，副本数设置为 20
在 kubernetes 中布置 tomcat deployment 资源类型，副本数设置为 50
在 kubernetes 中布置 tomcat deployment 资源类型，副本数设置为 100

试验环境

三节点 kubernetes 集群，master 为可调度形式

节点/资源	CPU	内存
master1	4c	16g
node1	4c	16g
node2	4c	16g

试验成果

chaosblade-operator 1.5.0 版别

在 kubernetes 中布置 tomcat deployment 资源类型，副本数设置为 20；经过 chaosblade cli 注入 CPU load 场景，指定 CPU 运用率为 60，经过标签来筛选出一切 Pod，设置等待时刻为 5 分钟；

注入耗时

注入耗时到达 57s

time ./blade create k8s pod-cpu load --kubeconfig ~/.kube/config --namespace default --cpu-percent 60 --labels app=tomcat --waiting-time 5m
{"code":200,"success":true,"result":"4fce727793e239cb"}
real  0m57.851s
user  0m0.811s
sys  0m0.208s

资源耗费

可以看到网络带宽承受峰值到达 180MBs 左右，传输峰值到达 140MBs 左右

在 kubernetes 中布置 tomcat deployment 资源类型，副本数设置为 50；经过 chaosblade cli 注入 CPU load 场景，指定 CPU 运用率为 60，经过标签来筛选出一切 Pod，设置等待时刻为 5 分钟；

注入耗时

注入耗时到达 2m25.806s

time ./blade create k8s pod-cpu load --kubeconfig ~/.kube/config --namespace default --cpu-percent 60 --labels app=tomcat --waiting-time 5m
{"code":200,"success":true,"result":"71e07348af26e4aa"}
real  2m25.806s
user  0m1.010s
sys  0m0.239s

资源耗费

在 kubernetes 中布置 tomcat deployment 资源类型，副本数设置为 100；经过 chaosblade cli 注入 CPU load 场景，指定 CPU 运用率为 60，经过标签来筛选出一切 Pod，为了避免出现超时状况，不太好评价注入耗时，一切此刻将等待时刻设置为 20 分钟；

注入耗时

time ./blade create k8s pod-cpu load --kubeconfig ~/.kube/config --namespace default --cpu-percent 60 --labels app=tomcat --waiting-time 20m
{"code":200,"success":true,"result":"cc477f2c632e2510"}
real  4m59.776s
user  0m1.132s
sys  0m0.281s

资源耗费

chaosblade-operator 1.6.1 版别

这次装置 chaosblade-operator 1.6.1 版别

helm install chaosblade-operator chaosblade-operator-1.5.0.tgz

注入耗时

time ./blade create k8s pod-cpu load --kubeconfig ~/.kube/config --namespace default --cpu-percent 60 --labels app=tomcat --waiting-time 5m
{"code":200,"success":true,"result":"a4d9c4c9c16642b5"}
real  0m24.519s
user  0m0.597s
sys  0m0.071s

资源耗费

注入耗时

time ./blade create k8s pod-cpu load --kubeconfig ~/.kube/config --namespace default --cpu-percent 60 --labels app=tomcat --waiting-time 5m
{"code":200,"success":true,"result":"f4f4790a369cc448"}
real  1m46.554s
user  0m0.696s
sys  0m0.055s

资源耗费

在 kubernetes 中布置 tomcat deployment 资源类型，副本数设置为 100；经过 chaosblade cli 注入 CPU load 场景，指定 CPU 运用率为 60，经过标签来筛选出一切 Pod，设置等待时刻为 5 分钟；

注入耗时

time ./blade create k8s pod-cpu load --kubeconfig ~/.kube/config --namespace default --cpu-percent 60 --labels app=tomcat --waiting-time 5m
{"code":200,"success":true,"result":"f4f4790a369cc448"}
real  1m46.554s
user  0m0.696s
sys  0m0.055s

资源耗费

试验总结

chaosblade-operator 1.5.0 版别

pod 数量/影响规模	注入耗时	磁盘IO影响	网络带宽影响
20	57s	稍微影响	影响大
50	2m25s	影响大	影响大
100	4m59s	影响极大	影响极大

chaosblade-operator 1.6.1 版别

pod 数量/影响规模	注入耗时	磁盘IO影响	网络带宽影响
20	5s	简直无影响	简直无影响
50	27s	简直无影响	简直无影响
100	1m46s	简直无影响	简直无影响

经过试验成果对比和观测图可以很明显的看到，chaosblade-operator 1.6.1 版别在注入进程中对在资源耗费方面简直没有任何影响，注入耗时也有明显的提高；

关于其他新特性，比方兼容性提高、只读文件体系Pod支撑、无侵入等，也可以自动测验去做更多的试验，相信你会有更深的了解。

考虑

Java 场景支撑

ChaosBlade 关于容器 Java 场景的完成，是经过 JVM attach javaagent 的才干完成的，也就意味着 JVM 在 attach 的时分有必要可以查找到 javaagent.jar 包所在路径，所以现在有必要将 javaagent.jar 仿制进容器；怎么可以更高雅做到容器 Java 场景的注入仍然值得咱们去探究和打破。

Node 等级演练支撑

ChaosBlade Operator 关于 Kubernetes Node 等级的演练支撑是有限的，在 Node 场景注入毛病时分，真实注入的是 chaosblade-tool 容器，chaosblade-tool 默许也仅仅进程和网络指令空间处在宿主机等级，因而在 chaosblade-tool 容器中支撑网络延时、网络丢包、杀进程等场景，其实也是等同 Node 维度的网络延时、网络丢包、杀进程等场景；

关于其他 Kubernetes Node 的支撑、并不能真实做到 Node 维度，比方 CPU、内存、磁盘 IO 等有必要得在 chaosblade-tool 容器没有被约束资源的情形下，才勉强算 Node 维度；而文件体系、Java 场景等现在是没有办法做到的；从别的一个视点动身考虑，咱们是否需求这些场景，在一般状况下在主机（Node）上装置 chaosblade彻底可以支撑悉数场景了。

作者简介

叶飞（Github账号：tiny-x）ChaosBlade Maintainer。现在首要重视于混沌工程、云原生以及 Linux 内核相关。

大规模 Kubernetes 集群故障注入的利器-ChaosBlade

ChaosBlade

资源模型

生命周期

毛病注入

开始的痛点

注入慢

网络带宽占用

兼容性问题

只读 Pod

侵入型

优化进程

Linux 虚拟化

1）宿主机网络延时

2）容器内网络延时

ChaosBlade 完成

大规划运用演练

试验事例

试验环境

试验成果

注入耗时

资源耗费

注入耗时

资源耗费

注入耗时

资源耗费

注入耗时

资源耗费

注入耗时

资源耗费

注入耗时

资源耗费

试验总结

考虑

Java 场景支撑

Node 等级演练支撑

相关链接

作者简介

作者信息

推广

大规模 Kubernetes 集群故障注入的利器-ChaosBlade

ChaosBlade

资源模型

生命周期

毛病注入

开始的痛点

注入慢

网络带宽占用

兼容性问题

只读 Pod

侵入型

优化进程

Linux 虚拟化

1）宿主机网络延时

2）容器内网络延时

ChaosBlade 完成

大规划运用演练

试验事例

试验环境

试验成果

注入耗时

资源耗费

注入耗时

资源耗费

注入耗时

资源耗费

注入耗时

资源耗费

注入耗时

资源耗费

注入耗时

资源耗费

试验总结

考虑

Java 场景支撑

Node 等级演练支撑

相关链接

作者简介

相关文章

EventBridge 集成云服务实践

3个问题！验明GPT-4真身；基于GPT科研加速技巧汇总；Midjourney神仙教程；印象笔记有AI功能啦 | ShowMeAI日报

MinIO 高性能分布式存储最新版单机与分布式部署

哈啰基于轨迹与端智能的还车体验优化

作者信息

推广