乐趣区

关于数据库:云原生-混沌工程工具-ChaosBlade-Operator-Pod-篇

jiezi

作者：丁源 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 高可用类型 8C 16G 500GB 4 – –
RadonDB MySQL – 4C 16G POD: 50G DataDir: 10 G 3 2 1

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

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

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

退出移动版