云原生 | 混沌工程工具 ChaosBlade Operator Pod 篇（文末赠书）

作者: admin 分类: 公众号存档 0 次浏览发布时间: 2021-08-28 22:49

【转载声明】本文为转载文章，原作者「丁源」，版权归原作者所有。　原文链接：https://mp.weixin.qq.com/s/5FN3Av9X1zE7w9fuZEP-dw

公众号：杨建荣的学习笔记 · 作者：丁源 · 发布：2021-08-28 22:49:38 · 原文链接

作者：丁源 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 被删除并重启，结果符合预期。

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

进入测试 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 的操作简单易懂且功能强大，通过模拟不同的故障，可以检验系统监控报警的时效性，也可以检验系统在遇到故障时的情况，对系统进行调整，从而完善系统架构，增加可用性。

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

抽奖活动

参与抽奖活动，价值 119 元的《混沌工程：复杂系统韧性实现之道》等你拿。

奖品介绍

混沌工程开创者撰写，通过谷歌、微软等行业专家的真实故事，系统阐释混沌工程的核心实践，提供实践建议。

抽奖说明

奖品：技术图书《混沌工程》 1 份
活动时间：即日起至 2021 年 8 月 20 日 16:00

活动自动开奖后，请于 48 小时内联系社区微信 radondb，留下领奖信息。

活动规则

参与活动需关注社区公众号
关注后扫描活动小程序码参与抽奖
开奖后 48 小时内领取，超时视为放弃
邀请好友助力增加中奖概率

本次抽奖活动最终解释权归 RadonDB开源社区 所有。

关于 RadonDB

RadonDB开源社区 是一个面向云原生、容器化的数据库开源社区。为数据库技术爱好者提供围绕主流开源数据库（MySQL、PostgreSQL、Redis、MongoDB、ClickHouse 等）的技术分享平台，并提供企业级 RadonDB 开源产品及服务。

目前 RadonDB 开源数据库系列产品已被光大银行、浦发硅谷银行、哈密银行、泰康保险、太平保险、安盛保险、阳光保险、百年人寿、安吉物流、安畅物流、蓝月亮、天财商龙、罗克佳华、升哲科技、无锡汇跑体育、北京电信、江苏交通控股、四川航空、昆明航空、国控生物等上千家企业及社区用户采用。

RadonDB 可基于云平台与 Kubernetes 容器平台交付，不仅提供覆盖多场景的数据库产品解决方案，而且提供专业的集群管理和自动化运维能力，主要功能特性包括：高可用主从切换、数据强一致性、读写分离、一键安装部署、多维指标监控&告警、弹性扩容&缩容、横向自由扩展、自动备份&恢复、同城多活、异地灾备等。RadonDB 仅需企业及社区用户专注于业务层逻辑开发，无需关注集群高可用选型、管理和运维等复杂问题，帮助企业及社区用户大幅度提升业务开发与价值创新的效率！

GitHub:

https://github.com/radondb

微信群： 请搜索添加群助手微信号 radondb

转载