Skip to main content

ChaosBlade:从零开始的混沌工程(三)

· 12 min read
郭旭东(@sunny0826)

前言

在上篇文章中,我们介绍了如何安装 ChaosBlade Operator,并进行了简单的使用。从本章开始,所有的实践章节,都会有配套的 katacode 交互式教程,读者可用通过 katacode,在浏览器上操作真实的 Kubernetes 和 ChaosBlade。

实验对象:Pod

Pod 是 Kubernetes 应用程序的基本执行单元,即它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。Pod 表示在 集群 上运行的进程。

Pod 封装了应用程序容器(或者在某些情况下封装多个容器)、存储资源、唯一网络 IP 以及控制容器应该如何运行的选项。 Pod 表示部署单元:Kubernetes 中应用程序的单个实例,它可能由单个 容器 或少量紧密耦合并共享资源的容器组成。

Pod 实验场景

Pod 作为 Kubernetes 最基本的执行单元,对于 Kubernetes 集群来说十分重要。那么对于混沌工程,从 Pod 入手实践就再合适不过了。

本篇默认已安装 guestbook 应用和 ChaosBlade Operator。

删除 Pod 场景

实验目标:删除 chaosblade 命名空间下标签是 role=master 的 pod。

执行观测

开始观察需要删除的 pod:

$ kubectl get pod -l "role=master" -n chaosblade -w

开始实验

delete_pod_by_labels.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
name: delete-two-pod-by-labels
spec:
experiments:
- scope: pod
target: pod
action: delete
desc: "delete pod by labels"
matchers:
- name: labels
value:
- "role=master"
- name: namespace
value:
- "chaosblade"
- name: evict-count
value:
- "2"

新建终端,并开始实验:

$ kubectl apply -f delete_pod_by_labels.yaml

查看实验状态

执行命令:kubectl get blade delete-two-pod-by-labels -o json,查看实验状态。

查看实验结果

通过上面的观测命令,可以看到 pod 被删除并重启,结果符合预期。

停止实验

执行命令:kubectl delete -f delete_pod_by_labels.yaml

或者直接删除 blade 资源:kubectl delete blade delete-two-pod-by-labels

Pod 网络延迟场景

实验目标:在 chaosblade 命名空间中,对 redis-master-68857cd57c-dzbs9 Pod 的本地 6379 端口添加 3000 毫秒访问延迟,延迟时间上下浮动 1000 毫秒。

开始实验

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:
- "redis-master-68857cd57c-dzbs9"
- name: namespace
value:
- "chaosblade"
- name: local-port
value: ["6379"]
- name: interface
value: ["eth0"]
- name: time
value: ["3000"]
- name: offset
value: ["1000"]

获取 Pod 名称:

$ kubectl get pod -l app=redis,role=master -o jsonpath={.items..metadata.name}

修改 delay_pod_network_by_names.yaml 中的 name 字段的值。

执行命令,开始实验:

$ kubectl apply -f delay_pod_network_by_names.yaml

查看实验状态

执行 kubectl get blade delay-pod-network-by-names -o json 命令,查看实验状态。

观测结果

# 获取实验 pod ip
$ kubectl get pod -l app=redis,role=master -o jsonpath={.items..status.podIP}
10.42.69.44
# 进入观测 pod
$ kubectl exec -it redis-slave-6dd975d4c8-2zrkb bash
# 在 pod 中安装 telnet
$ apt-get update && apt-get install -y telnet
# 测试时间
$ time echo "" | telnet 10.42.69.44 6379
Trying 10.42.69.44...
Connected to 10.42.69.44.
Escape character is '^]'.
Connection closed by foreign host.

real 0m3.790s
user 0m0.007s
sys 0m0.001s

可以看到访问实验 pod 6379 端口的延迟为 3s 左右,结果符合预期。

delay-pod-network

停止实验

执行命令:kubectl delete -f delay_pod_network_by_names.yaml

或者直接删除 blade 资源:kubectl delete blade delay-pod-network-by-names

Pod 网络丢包场景

实验目标:在 chaosblade 命名空间中,对 redis-master-68857cd57c-dzbs9 Pod 注入丢包率 100% 的故障,只针对 IP 为 10.42.69.42 的 pod 生效,也就是除 10.42.69.42 以外的 pod 都能正常访问 redis-master-68857cd57c-dzbs9

开始实验

获取 pod 名称内容同上。

loss_pod_network_by_names.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
name: loss-pod-network-by-names
spec:
experiments:
- scope: pod
target: network
action: loss
desc: "loss pod network by names"
matchers:
- name: names
value:
- "redis-master-68857cd57c-dzbs9"
- name: namespace
value:
- "chaosblade"
- name: interface
value: ["eth0"]
- name: percent
value: ["100"]
- name: timeout
value: ["60"]
- name: destination-ip
value: ["10.42.69.42"]

执行命令,开始实验:

$ kubectl apply -f loss_pod_network_by_names.yaml

查看实验状态

执行 kubectl get blade loss-pod-network-by-names -o json 命令,查看实验状态。

观测结果

# 获取实验 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.
# 无响应

# 进入观测 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 ms
64 bytes from 10.42.69.44: icmp_seq=2 ttl=63 time=0.128 ms
64 bytes from 10.42.69.44: icmp_seq=3 ttl=63 time=0.092 ms
...
# 响应正常

可以看到观测 pod 访问实验 pod 丢包率 100%(无法访问),而其他 pod 不受影响,结果符合预期。

loss-pod-network

这里在配置中将 timeout 设置为 60 秒,60 秒后 100% 丢包的情况将会消失,这个配置是为了防止因丢包率设置太高,造成机器无法连接的情况。与其有相似功能的还有 exclude-port,该配置指定一些端口不会丢包,以免该 pod 失联。

停止实验

执行命令:kubectl delete -f loss_pod_network_by_names.yaml

或者直接删除 blade 资源:kubectl delete blade loss-pod-network-by-names)

Pod 域名访问异常场景

实验目标:Pod 内访问指定域名异常。

开始实验

获取 pod 名称内容同上。

dns_pod_network_by_names.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
name: dns-pod-network-by-names
spec:
experiments:
- scope: pod
target: network
action: dns
desc: "dns pod network by names"
matchers:
- name: names
value:
- "redis-slave-6dd975d4c8-lm8jz"
- name: namespace
value:
- "chaosblade"
- name: domain
value: ["www.baidu.com"]
- name: ip
value: ["10.0.0.1"]

执行命令,开始实验:

$ kubectl apply -f dns_pod_network_by_names.yaml

查看实验状态

执行 kubectl get blade dns-pod-network-by-names -o json 命令,查看实验状态。

观测结果

# 进入实验 pod
$ kubectl exec -it redis-slave-6dd975d4c8-lm8jz bash
# Ping www.baidu.com
$ ping www.baidu.com
# 无响应

可以看到访问指定域名 www.baidu.com 异常,结果符合预期。

dns-pod-network

停止实验

执行命令:kubectl delete -f dns_pod_network_by_names.yaml

或者直接删除 blade 资源:kubectl delete blade dns-pod-network-by-names

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

实验目标:给 kubernetes 的 pod 注入文件系统I/O故障。

注意:此场景需要激活 --webhook-enable 参数,如需使用此功能,请在 chaosblade-operator 参数中添加 --webhook-enable,或者在安装时指定:例如 helm 安装时添加 --set webhook.enable=true 指定。

前提条件

  • 集群中部署了 chaosblade-admission-webhook
  • 需要注入故障的 volume 设置 mountPropagationHostToContainer
  • pod上面添加了如下annotations:
    chaosblade/inject-volume: "data" //需要注入故障的volume name
    chaosblade/inject-volume-subpath: "conf" //volume挂载的子目录

部署测试 pod

chaosblade webhook 会根据 pod 的 annotation,注入 fuse 的 sidecar 容器:

  1. chaosblade/inject-volume 指明需要注入故障的 volume name,比如例子中的 data
  2. chaosblade/inject-volume-subpath 指明 volume 挂载路径的子目录。上面的例子中,volume 的挂载路径是 /data,子目录是 conf,则在 pod 内,注入I/O异常的目录是 /data/conf
  3. 指定需要注入故障的 volume 需要指定 mountPropagation:HostToContainer,这个字段的含义可以参考官方文档 Volumes
# 部署测试 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

查看实验状态

执行 kubectl get blade inject-pod-by-labels -o json 命令,查看实验状态。

观测结果

# 进入实验 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

文件读取异常,结果符合预期。

io-pod-read

在本例中,我们对 read 操作注入两种异常,异常率为百分之60:

  • read 操作增加 1s 的延迟。
  • read 操作返回错误 28

这里只是做了一种类型的实验,更多的实验类型详见官方文档

停止实验

执行命令:kubectl delete -f pod_io.yaml

或者直接删除 blade 资源:kubectl delete blade inject-pod-by-labels

删除测试 pod:kubectl delete -f io-test-pod.yaml

结语

本篇我们使用 ChaosBlade Operator 对 Kubernetes Pod 资源进行混沌工程实验,可以看到 ChaosBlade 的操作简单易懂且功能强大,通过模拟不同的故障,可以检验我们系统监控报警的时效性,也可以检验我们系统在遇到故障时的情况,根据这些情况对系统进行调整,从而完善系统架构,增加可用性。

这里只是对于每种场景进行了简单的实验,而每个场景不止有一种实验方式,用户可以通过调整参数进行不同的实验。