作者：叶飞
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 root2）容器内网络延时
如何在容器中注入一个网络延时呢？其实非常简单，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在 kubernetes 中部署 tomcat deployment 资源类型，正本数设置为 20；通过 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":"a4d9c4c9c16642b5"}
real 0m24.519s
user 0m0.597s
sys 0m0.071s资源耗费
在 kubernetes 中部署 tomcat deployment 资源类型，正本数设置为 50；通过 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资源耗费
在 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 齐全可能反对全副场景了。
相干链接
ChaosBlade 官网网址：
https://chaosblade.io/
ChaosBlade Github：
https://github.com/chaosblade-io/chaosblade
ChaosBlade 钉钉社区交换群：23177705
作者简介
叶飞（Github 账号：tiny-x）ChaosBlade Maintainer。目前次要关注于混沌工程、云原生以及 Linux 内核相干。