作者：丁源 RadonDB 测试负责人

负责 RadonDB 云数据库、容器化数据库的品质性能测试，迭代验证。对包含云数据库以及容器化数据库性能和高可用计划有深入研究。

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

• 资源场景，比方删除 Pod
• 网络资源场景，比方网络提早
• 文件系统异样场景
• 不可用异样场景

| 试验环境

测试对象

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

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

环境参数

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

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 被删除并重启，后果合乎预期。

<center>KubeSphere 平台 </center>

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 毫秒 

<center> 配置后 </center>

保留为文件，并部署利用。

$ 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。

<center> 针对指定 IP</center>

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。

<center> 激活指定参数台 </center>

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 测试验证

进入测试 Pod。

$ kubectl exec -ti demo-radondb-mysql-0 bin/bash

Ping 一个域名 www.baidu.com

$ ping www.baidu.com

查看并分析测试后果。

回显信息反馈 ping 无响应。能够看到拜访指定域名 www.baidu.com 异样，后果合乎预期。

| 结语

通过应用 ChaosBlade Operator 对 Kubernetes Pod 资源进行混沌工程测试，可得出如下论断：

对于 Pod 资源，ChaosBlade 的操作简略易懂且功能强大，通过模仿不同的故障，能够测验系统监控报警的时效性，也能够测验零碎在遇到故障时的状况，对系统进行调整，从而欠缺零碎架构，减少可用性。

本篇只是对于每种场景进行了简略的测试，而每个场景不止有一种测试形式，用户能够通过调整参数进行不同的测试。