Blade create K8S

参考链接：
https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/

介绍

chaosblade-operator 项目是针对 Kubernetes 平台所实现的混沌实验注入工具，遵循上述混沌实验模型规范化实验场景，把实验定义为 Kubernetes CRD 资源，将实验模型中的四部分映射为 Kubernetes 资源属性，很友好的将混沌实验模型与 Kubernetes 声明式设计结合在一起，依靠混沌实验模型便捷开发场景的同时，又可以很好的结合 Kubernetes 设计理念，通过 kubectl 或者编写代码直接调用 Kubernetes API 来创建、更新、删除混沌实验，而且资源状态可以非常清晰的表示实验的执行状态，标准化实现 Kubernetes 故障注入。

除了使用上述方式执行实验外，还可以使用 chaosblade cli 方式非常方便的执行 kubernetes 实验场景，查询实验状态等。遵循混沌实验模型实现的 chaosblade operator 除上述优势之外，还可以实现基础资源、应用服务、Docker 容器等场景复用，大大方便了 Kubernetes 场景的扩展，所以在符合 Kubernetes 标准化实现场景方式之上，结合混沌实验模型可以更有效、更清晰、更方便的实现、使用混沌实验场景。

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

.blade create k8s node-cpu Node 节点 CPU 负载场景
.blade create k8s node-network Node 节点网络场景
.blade create k8s node-process Node 节点进程场景
.blade create k8s node-disk Node 节点磁盘场景
.blade create k8s pod-pod Pod 资源场景，比如杀 Pod
.blade create k8s pod-network Pod 网络资源场景，比如网络延迟
.blade create k8s pod-IO Pod IO 文件系统异常场景
.blade create k8s pod-fail Pod 不可用异常场景
.blade create k8s container-container Container 资源场景，比如杀容器
.blade create k8s container-cpu 容器内 CPU 负载场景
.blade create k8s container-network 容器内网络场景
.blade create k8s container-process 容器内进程场景

部署

执行 Kubernetes 实验场景，需要提前部署 ChaosBlade Operator，Helm 安装包下载地址：https://github.com/chaosblade-io/chaosblade-operator/releases 。使用以下命令安装:
注意：需要你自己新建一个namespace哦！

helm install kube-system/chaosblade-operator-1.2.0-v3.tgz
helm install chaosblade-operator chaosblade-operator-1.2.0-v3.tgz –namespace chaosblade

会安装在 chaosblade 命令空间下。ChaosBlade Operator 启动后会在每个节点部署 chaosblade-tool Pod 和一个 chaosblade-operator Pod.可通过以下命令查看安装结果:
kubectl get pod -n chaosblade -o wide | grep chaosblade

install-result

如果显示 chaosblade-operator 和 chaosblade-tool Pod 都处于 Running 状态，说明部署成功，如果部署出现问题，可详见下发的QA。

实验环境

环境参数

集群名称	主机类型	CPU	Memory	Total Disk	Node Counts	Replicate counts	Shard counts
KubeSphere	高可用类型	8C	16G	500GB	4	-	-
RadonDB Mysql	-	4C	16G	POD: 50G<br>DataDir: 10 G	RadonDB Mysql 3	2	1

基于Kubernetes容器平台的RadonDB MySQL（容器数据库）
详细部署文档参见《在 KubeSphere 中部署 Mysql 集群》

实验对象：Node

Node节点CPU负载场景

创建实验

下面以指定一台节点，做 CPU 负载 80% 实验举例
yaml 配置方式

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: cpu-lode
spec:
  experiments:
  - scope: node
    target: cpu
    action: fulllode
    desc: "increase node cpu load by names"  ---实验模型名称
    matchers:
    - name: names
      value:
      - "worker-s001"  ---测试对象node名称
    - name: cpu-percent
      value: "80"      ---节点负载百分比
    - name: ip
      value:192.168.0.20      ---节点负载百分比

选择一个节点，修改 node_cpu_load.yaml 中的 names 值。

查看实验结果

进入该 Node 节点，使用 top 命令可以看到该节点 CPU 达到预期效果。

Node节点网络相关场景

实验前，请先登录 node 节点，使用 ifconfig 命令查看网卡信息，不是所有系统默认的网卡名称都是 eth0

实验目标：指定节点worker-s001 添加 3000 毫秒访问延迟，延迟时间上下浮动 1000 毫秒。

开始实验

选择一个节点，修改 delay_node_network_by_names.yaml 中的 names 值。
对 worker-s001 节点访问丢包率 100%。
delay_node_network_by_names.yaml 内容：

执行命令，开始实验：

kubectl apply -f delay_node_network_by_names.yaml

查看实验状态
执行 kubectl get blade delay-node-network-by-names -o json 命令，查看实验状态。

查看实验结果

# 从实验节点访问 Guestbook
$ time echo "" | telnet 192.168.0.18
echo ""  0.00s user 0.00s system 35% cpu 0.003 total
telnet 192.168.1.129 32436  0.01s user 0.00s system 0% cpu 3.248 total

停止实验
执行命令：kubectl delete -f delay_node_network_by_names.yaml
或者直接删除 blade 资源：kubectl delete blade delay-node-network-by-names

节点网络丢包场景

实验目标：指定节点注入丢包率 100% 的故障。

开始实验
选择一个节点，修改loss_node_network_by_names.yaml中的names值。
loss_node_network_by_names.yaml内容：

执行命令，开始实验：

$ kubectl apply -f loss_node_network_by_names.yaml

查看实验状态

执行kubectl get blade loss-node-network-by-names -o json命令，查看实验状态。

查看实验结果

该端口为 Guestbook nodeport 的端口，访问实验端口无响应，但是访问未开启实验的端口可以正常使用：

# 获取节点 IP
$ kubectl get node -o wide

# 从实验节点访问 Guestbook - 无法访问
$ telnet 192.168.0.20

# 从非实验节点访问 Guestbook - 正常访问
$ telnet 192.168.0.18

同样也可以直接从浏览器访问地址，验证实验。

停止实验

执行命令：kubectl delete -f loss_node_network_by_names.yaml
或者直接删除 blade 资源：kubectl delete blade loss-node-network-by-names

节点进程相关场景

kubernetes 节点进程相关场景。

杀节点上指定进程

实验目标：此实验会删除指定节点上的 mysql 进程。

开始实验
选择一个节点，修改 kill_node_process_by_names.yaml 中的 names 值。
kill_node_process_by_names.yaml 内容：

执行命令，开始实验：

$ kubectl apply -f kill_node_process_by_names.yaml

查看实验状态

执行 kubectl get blade kill-node-process-by-names -o json 命令，查看实验状态。

查看实验结果

# 进入实验 node
$ ssh 192.168.0.18
# 查看 redis-server 进程号
$ ps -ef | grep mysql
root     10913 10040  0 14:10 pts/0    00:00:00 grep --color=auto mysql
# 可以看到进程号发生了变化
$ ps -ef | grep redis-server

Mysql 的进程号发生改变，说明被杀掉后，又被重新拉起。

停止实验

执行命令：kubectl delete -f kill_node_process_by_names.yaml
或者直接删除 blade 资源：kubectl delete blade kill-node-process-by-names

挂起节点上指定进程

实验目标：此实验会挂起指定节点上的 mysql 进程。

开始实验

选择一个节点，修改 stop_node_process_by_names.yaml 中的 names 值。
stop_node_process_by_names.yaml 内容：

执行命令，开始实验：

$ kubectl apply -f stop_node_process_by_names.yaml

查看实验状态

执行 kubectl get blade stop-node-process-by-names -o json 命令，查看实验状态。

查看实验结果

# 进入实验 node
$ ssh 192.168.0.18
# 查看 redis-server 进程号
$ ps aux| grep mysql

可以看到mysql此刻处于暂时停止状态了。

停止实验

执行命令：kubectl delete -f stop_node_process_by_names.yaml
或者直接删除 blade 资源：kubectl delete blade stop-node-process-by-names

结语

以上我们使用 ChaosBlade Operator 对 Kubernetes Node 资源进行混沌工程实验，可以看到对于 Node 节点，ChaosBlade 依旧有简单的配置及操作来完成复杂的实验，可以通过自由组合，实现各种 Node 节点级别的复杂故障，验证 Kubernetes 集群的稳定性及可用性。同时当真正的故障来临时，由于早已模拟了各种故障情况，可以快速定位故障源，做到处变不惊，轻松处理故障。

Pod 实验场景

创建实验

Pod 网络资源场景，比如网络延迟

实验目标：对 chaosblade 命名空间中，对 demo-radondb-mysql-0 Pod 的本地 3306 端口添加 3000 毫秒访问延迟，延迟时间上下浮动 1000 毫秒。

实验yaml配置

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: delay-pod-network-by-names
spec:
  experiments:
  - scope: pod
    target: network
    action: delay
    desc: "delay pod network by names"  ---实验模型名称
    matchers:
    - name: names
      value:
      - "radondb-g4r992-radondb-postgresql-0"  ---测试对象pod名称
    - name: namespace
      value:
      - "chaosblade"      ---namespace名称
    - name: local-port     
      value: ["5432"]     ---pod本地端口6379      
- name: interface
      value: ["eth0"]     ----接口eth0
    - name: time
      value: ["3000"]      ---添加3000毫秒访问
    - name: offset
      value: ["1000"]      ---延迟时间上下浮动1000毫秒

保存为文件delay_pod_network_by_names.yaml 执行命令，开始实验：

$ kubectl apply -f delay_pod_network_by_names.yaml

查看实验状态：

执行kubectl get blade delay-pod-network-by-names -o json 命令，查看实验状态：

可以看到实验成功创建了。

观测结果

# 获取实验 pod ip
$ kubectl get pod -l app=redis,role=master -o jsonpath={.items..status.podIP}
$ kubectl get pod kubectl get pod demo-radondb-mysql-0 -o wide

10.10.131.182
# 进入观测 pod
$  kubectl exec -ti demo-radondb-mysql-1 /bin/bash
# 在 pod 中安装 telnet
$ apt-get update && apt-get install -y telnet

# 测试时间
$ time echo "" | telnet 10.10.131.182 3306

可以看到访问实验 pod 3306 端口的延迟为 3s 左右，结果符合预期。

停止实验

执行命令：kubectl delete -f delay_pod_network_by_names.yaml

或者直接删除 blade 资源：
kubectl delete -f delay_pod_network_by_names

删除 Pod 场景

实验目标：删除 chaosblade 命名空间下标签是 chaosblade-tool-nhzds的 pod。

执行观测：

kubectl get pod chaosblade-tool-nhzds -n chaosblade  -w

开始实验

delete_pod_by_labels.yaml 内容：

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: delete-two-pod-by-labelsspec:
  experiments:
  - scope: pod
    target: pod
    action: delete
    desc: "delete pod by labels"
    matchers:
    - name: labels
      value:
      - "demo-radondb-mysql-1"
    - name: namespace
      value:
      - "chaosblade"
    - name: evict-count
      value:
      - "2"

新建终端，并开始实验：

$ kubectl apply -f delete_pod_by_labels.yaml

查看实验状态

执行命令：kubectl get blade delete-pod-by-labels -o json，查看实验状态。

查看实验结果

通过上面的观测命令，可以看到 pod 被删除并重启，结果符合预期。

停止实验

执行命令：kubectl delete -f delete_pod_by_labels.yaml

或者直接删除 blade 资源：kubectl delete blade delete-pod-by-labels

Pod 网络丢包场景

实验目标：在 chaosblade 命名空间中，对 demo-radondb-mysql-0 Pod 注入丢包率 100% 的故障，只针对 IP 为 192.168.0.18 的 pod 生效，也就是除 192.168.0.18 以外的 pod 都能正常访问 demo-radondb-mysql-0。

执行命令，开始实验：

$ kubectl apply -f loss_pod_network_by_names.yaml

查看实验状态

执行 kubectl get blade loss-pod-network-by-names -o json 命令，查看实验状态。

# 获取实验 pod ip
$ kubectl get pod -l app=redis,role=master -o jsonpath={.items..status.podIP}10.42.69.44
# 进入观测 pod，IP为：10.42.69.42（被设置丢包率 100%）
$ kubectl exec -it redis-slave-6dd975d4c8-lm8jz bash
# Ping 实验Pod ip
$ ping 10.42.69.44
PING 10.42.69.44 (10.42.69.44) 56(84) bytes of data.
# 无响应

# 进入观测 pod，该 pod 未被指定丢包
$ kubectl exec -it redis-slave-6dd975d4c8-2zrkb bash
# Ping 实验Pod ip
$ ping 10.42.69.44
PING 10.42.69.44 (10.42.69.44) 56(84) bytes of data.64 bytes from 10.42.69.44: icmp_seq=1 ttl=63 time=0.128 ms64 bytes from 10.42.69.44: icmp_seq=2 ttl=63 time=0.128 ms64 bytes from 10.42.69.44: icmp_seq=3 ttl=63 time=0.092 ms...
# 响应正常

Pod 域名访问异常场景

实验目标：Pod 内访问指定域名异常。

开始实验

获取 pod 名称内容同上

执行命令，开始实验：

$ kubectl apply -f dns_pod_network_by_names.yaml

查看实验状态

执行 kubectl get blade dns-pod-network-by-names -o json 命令，查看实验状态。

观测结果

# 进入实验 pod
$ kubectl exec -ti demo-radondb-mysql-0 bin/bash
# Ping www.baidu.com
$ ping www.baidu.com
# 无响应

可以看到访问指定域名 www.baidu.com 异常，结果符合预期。

停止实验

执行命令：kubectl delete -f dns_pod_network_by_names.yaml

或者直接删除 blade 资源：kubectl delete blade dns-pod-network-by-names

Pod 文件系统 I/O 故障场景

实验目标：给 kubernetes 的 pod 注入文件系统I/O故障。

注意：此场景需要激活 --webhook-enable 参数，如需使用此功能，请在 chaosblade-operator 参数中添加 --webhook-enable，或者在安装时指定：例如 helm 安装时添加 --set webhook.enable=true 指定。

前提条件

集群中部署了 chaosblade-admission-webhook
需要注入故障的 volume 设置 mountPropagation 为 HostToContainer
pod上面添加了如下annotations:

chaosblade/inject-volume: "data" //需要注入故障的volume name
chaosblade/inject-volume-subpath: "conf" //volume 挂载的子目录

部署测试 pod

chaosblade webhook 会根据 pod 的 annotation，注入 fuse 的 sidecar 容器：

chaosblade/inject-volume 指明需要注入故障的 volume name，比如例子中的 data。
chaosblade/inject-volume-subpath 指明 volume 挂载路径的子目录。上面的例子中，volume 的挂载路径是 /data,子目录是 conf，则在 pod 内，注入I/O异常的目录是 /data/conf。
指定需要注入故障的 volume 需要指定 mountPropagation：HostToContainer。

# 部署测试 pod
$ kubectl apply -f io-test-pod.yaml
# 查看 sidecar 是否注入成功
$ kubectl get pod test-7c9fc6fd88-7lx6b -n chaosblade
NAME                    READY   STATUS    RESTARTS   AGE
test-7c9fc6fd88-7lx6b   2/2     Running   0          4m8s

开始实验

pod_io.yaml 内容：

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: inject-pod-by-labels
spec:
  experiments:
  - scope: pod
    target: pod
    action: IO
    desc: "Pod IO Exception by labels"
    matchers:
    - name: labels
      value:
      - "app=test"
    - name: namespace
      value:
      - "chaosblade"
    - name: method
      value:
      - "read"
    - name: delay
      value:
      - "1000"
    - name: path
      value:
      - ""
    - name: percent
      value:
      - "60"
    - name: errno
      value:
      - "28"

执行命令，开始实验：

$ kubectl apply -f pod_io.yaml

观测结果

# 进入实验 pod
$ kubectl exec -it test-7c9fc6fd88-7lx6b bash
# 在 pod 内读取指定目录中的文件，如果没有可以新建一个
$ time cat /data/conf/test.yaml
cat: read error: No space left on device

real    0m3.007s
user    0m0.002s
sys     0m0.002s
# 因为有重试，显示有 3s 的延迟
# 因为设置了 60% 的异常，所有还是有成功的情况
$ time cat /data/conf/test.yaml
123

real    0m0.004s
user    0m0.002s
sys     0m0.000s

文件读取异常，结果符合预期。

在本例中，我们对 read 操作注入两种异常，异常率为百分之60:

对 read 操作增加 1s 的延迟。
对 read 操作返回错误 28。

这里只是做了一种类型的实验，更多的实验类型详见官方文档[4]。

停止实验

执行命令：kubectl delete -f pod_io.yaml

或者直接删除 blade 资源：kubectl delete blade inject-pod-by-labels

删除测试 pod：kubectl delete -f io-test-pod.yaml

结语

以上我们使用 ChaosBlade Operator 对 Kubernetes Pod 资源进行混沌工程实验，可以看到 ChaosBlade 的操作简单易懂且功能强大，通过模拟不同的故障，可以检验我们系统监控报警的时效性，也可以检验我们系统在遇到故障时的情况，根据这些情况对系统进行调整，从而完善系统架构，增加可用性。

这里只是对于每种场景进行了简单的实验，而每个场景不止有一种实验方式，用户可以通过调整参数进行不同的实验。