云原生|混沌工程工具ChaosBladeOperatorPod篇

Z时代
2024-01-10
分类：综合

database

作者：丁源 RadonDB 测试负责人
负责 RadonDB 云数据库、容器化数据库的质量性能测试，迭代验证。对包括云数据库以及容器化数据库性能和高可用方案有深入研究。

继《混沌工程工具 ChaosBlade Opeator 系列》的入门篇和 Node 篇之后。本期将针对 Pod 类资源的应用场景进行测试，测试场景包括：

资源场景，比如删除 Pod

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

文件系统异常场景

不可用异常场景

| 实验环境

测试对象

基于 KubeSphere 平台的 RadonDB MySQL 容器化数据库进行测试。

RadonDB MySQL 部署说明请参见《在 KubeSphere 中部署 RadonDB MySQL 集群》。

环境参数

集群名称

主机类型

CPU

Memory

Total Disk

Node Counts

Replicate counts

Shard counts

KubeSphere

高可用类型

16G

500GB

RadonDB MySQL

16G

POD: 50G DataDir: 10 G

测试环境部署完成后，即可从以下五大类场景做相应验证。

1. Pod 删除资源场景

1.1 测试目标

删除 ChaosBlade 命名空间下标签是 chaosblade-tool-nhzds 的 Pod。

1.2 开始测试

查看 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"

新建终端删除 Pod。

$ kubectl apply -f delete_pod_by_labels.yaml

1.3 测试验证

查看测试状态。

$ kubectl get blade delete-pod-by-labels -o json

查看测试结果。

可以看到 Pod 被删除并重启，结果符合预期。

KubeSphere 平台

2. Pod 网络延迟场景

2.1 测试目标

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

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

2.2 开始测试

配置 delay_pod_network_by_names.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毫秒

配置后

保存为文件，并部署应用。

$ kubectl apply -f delay_pod_network_by_names.yaml

查看部署状态。

$ kubectl get blade delay-pod-network-by-names -o json

2.3 测试验证

获取测试 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

进入观测 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 左右，结果符合预期。

3. Pod 网络丢包场景

3.1 测试目标

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

针对指定 IP

3.2 开始测试

执行命令部署应用。

$ kubectl apply -f loss_pod_network_by_names.yaml

查看部署状态。

$ kubectl get blade loss-pod-network-by-names -o json

3.3 测试验证

获取测试 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.

回显信息反馈 Ping 无响应。

进入观测 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...

回显信息反馈 Ping 响应正常。测试结果符合预期。

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

4.1 测试准备

已部署 chaosblade-admission-webhook

已注入故障的 volume ，即设置 mountPropagation 为 HostToContainer。

已在 Pod 中添加了如下 annotations：
- chaosblade/inject-volume: "data" 为需要注入故障的 volume name
- chaosblade/inject-volume-subpath: "conf" //volume 为挂载的子目录

4.2 测试目标

在 Kubernetes 的 Pod 中注入文件系统 I/O 故障。

注意：此场景需要激活 --webhook-enable 参数。可在 ChaosBlad Operator 参数中添加 --webhook-enable，也可在部署数据库时指定 --set webhook.enable=true。

激活指定参数台

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

4.3 开始测试

部署测试 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

4.4 测试验证

进入测试 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

5. Pod 域名访问异常场景

5.1 测试目标

Pod 内访问指定域名异常。

5.2 开始测试

获取 Pod 名称，执行命令部署应用。

$ kubectl apply -f dns_pod_network_by_names.yaml

查看测试状态。

$ kubectl get blade dns-pod-network-by-names -o json

5.3 测试验证