实验环境

　　作者：丁源 RadonDB 测试负责人
　　负责 RadonDB 云数据库、容器化数据库的质量性能测试，迭代验证。对包括云数据库以及容器化数据库性能和高可用方案有深入研究。
　　继《混沌工程工具 ChaosBlade Opeator 系列》的 入门篇 和 Node 篇 之后。本期将针对 Pod 类资源的应用场景进行测试，测试场景包括：
　　资源场景，比如删除 Pod
　　网络资源场景，比如网络延迟
　　文件系统异常场景
　　不可用异常场景
　　| 实验环境测试对象
　　基于 KubeSphere平台的 RadonDB MySQL 容器化数据库进行测试。
　　RadonDB MySQL 部署说明请参见 《在 KubeSphere 中部署 RadonDB MySQL 集群》。
　　环境参数集群名称主机类型CPUMemoryTotal DiskNode CountsReplicate countsShard countsKubeSphere高可用类型8C16G500GB--RadonDB MySQL-4C16GPOD: 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-0Pod 的本地 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-0Pod 注入丢包率 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