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

简介: 本篇为系列文章第四篇,将介绍使用 ChaosBlade Operator 对 Kubernetes Node 进行混沌工程实验,实验包括:Node CPU 负载场景、Node 网络延迟场景、Node 网络丢包场景、Node 域名访问异常场景、Node 磁盘填充场景、Node 杀指定进程和Node 挂起指定进程等。

前言

在上篇文章中,我们介绍了如何使用 ChaosBlade Operator 对 pod 资源进行混沌实验。从本章将继续对 Kubernetes Node 资源的混沌实验进行讲解,同时也配套了 katacode 交互式教程,读者可用通过 katacode,在浏览器上操作真实的 Kubernetes 和 ChaosBlade。

chaosblade.io 官网也已经上线,在官网的互动教程模块,也可以找到 ChaosBlade 的 KataCoda 教程,目前官网由我维护,有任何问题,欢迎在 ISSUE 中进行反馈。

KataCoda 教程:《ChaosBlade Node 实验场景》

实验对象:Node

在 Kubernetes 中,节点(Node)是执行工作的机器,以前叫做 minion。根据你的集群环境,节点可以是一个虚拟机或者物理机器。每个节点都包含用于运行 pods 的必要服务,并由主控组件管理。节点上的服务包括 容器运行时、kubelet 和 kube-proxy。

Node 实验场景

上篇文章,本篇默认已安装 guestbook 应用和 ChaosBlade Operator。

节点资源相关场景

节点 CPU 负载实验场景

实验目标:指定一个节点,做 CPU 负载 80% 实验。

开始实验

node_cpu_load.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: cpu-load
spec:
  experiments:
  - scope: node
    target: cpu
    action: fullload
    desc: "increase node cpu load by names"
    matchers:
    - name: names
      value:
      - "docker20"
    - name: cpu-percent
      value:
      - "80"

选择一个节点,修改 node_cpu_load.yaml 中的 names 值。

执行命令,开始实验:

$ kubectl apply -f node_cpu_load.yaml

查看实验状态

执行 kubectl get blade cpu-load -o json 命令,查看实验状态。

查看实验结果

进入该 Node 节点,可以看到该节点 CPU 达到预期效果:

节点 CPU 负载实验

停止实验

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

或者直接删除 blade 资源:kubectl delete blade cpu-load

节点网络相关场景

实验前,请先登录 node 节点,使用 ifconfig 命令查看网卡信息,不是所有系统默认的网卡名称都是 eth0

节点网络延迟场景

实验目标:指定节点的本地 32436 端口添加 3000 毫秒访问延迟,延迟时间上下浮动 1000 毫秒。

开始实验

选择一个节点,修改 delay_node_network_by_names.yaml 中的 names 值。

对 docker20 节点本地端口 32436 访问丢包率 100%。

delay_node_network_by_names.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: delay-node-network-by-names
spec:
  experiments:
  - scope: node
    target: network
    action: delay
    desc: "delay node network loss"
    matchers:
    - name: names
      value: ["docker20"]
    - name: interface
      value: ["ens33"]
    - name: local-port
      value: ["32436"]
    - name: time
      value: ["3000"]
    - name: offset
      value: ["1000"]

执行命令,开始实验:

$ kubectl apply -f delay_node_network_by_names.yaml

查看实验状态

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

观测结果

# 从实验节点访问 Guestbook
$ time echo "" | telnet 192.168.1.129 32436
Trying 192.168.1.129...
Connected to 192.168.1.129.
Escape character is '^]'.
Connection closed by foreign host.
echo ""  0.00s user 0.00s system 35% cpu 0.003 total
telnet 192.168.1.129 32436  0.01s user 0.00s system 0% cpu 3.248 total

节点网络延迟场景

停止实验

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

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

节点网络丢包场景

实验目标:指定节点的 32436 端口注入丢包率 100% 的故障。

开始实验

选择一个节点,修改 loss_node_network_by_names.yaml 中的 names 值。

loss_node_network_by_names.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: loss-node-network-by-names
spec:
  experiments:
  - scope: node
    target: network
    action: loss
    desc: "node network loss"
    matchers:
    - name: names
      value: ["docker20"]
    - name: percent
      value: ["100"]
    - name: interface
      value: ["ens33"]
    - name: local-port
      value: ["32436"]

执行命令,开始实验:

$ kubectl apply -f loss_node_network_by_names.yaml

查看实验状态

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

观测结果

该端口为 Guestbook nodeport 的端口,访问实验端口无响应,但是访问未开启实验的端口可以正常使用:

# 获取节点 IP
$ kubectl get node -o wide
NAME       STATUS   ROLES                      AGE     VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
docker20   Ready    worker                     3d16h   v1.17.6   192.168.1.129   <none>        Ubuntu 18.04.4 LTS   4.15.0-101-generic   docker://19.3.11
kk         Ready    controlplane,etcd,worker   4d16h   v1.17.6   192.168.4.210   <none>        Ubuntu 18.04.4 LTS   4.15.0-101-generic   docker://19.3.11
# 从实验节点访问 Guestbook - 无法访问
$ telnet 192.168.1.129 32436
Trying 192.168.1.129...
telnet: connect to address 192.168.1.129: Operation timed out
telnet: Unable to connect to remote host
# 从非实验节点访问 Guestbook - 正常访问
$ telnet 192.168.4.210 32436
Trying 192.168.4.210...
Connected to 192.168.4.210.
Escape character is '^]'.

节点网络丢包场景

同样也可以直接从浏览器访问地址,验证实验。

停止实验

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

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

节点域名访问异常场景

实验目标:本实验通过修改 Node 的 hosts,篡改域名地址映射,模拟 Pod 内域名访问异常场景。

开始实验

选择一个节点,修改 dns_node_network_by_names.yaml 中的 names 值。

dns_node_network_by_names.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: dns-node-network-by-names
spec:
  experiments:
  - scope: node
    target: network
    action: dns
    desc: "dns node network by names"
    matchers:
    - name: names
      value:
      - "docker20"
    - name: domain
      value: ["www.baidu.com"]
    - name: ip
      value: ["10.0.0.1"]

执行命令,开始实验:

$ kubectl apply -f dns_node_network_by_names.yaml

查看实验状态

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

观测结果

# 进入实验 node
$ ssh kk@192.168.1.129
# Ping www.baidu.com
$ ping www.baidu.com
# 无响应

节点域名访问异常场景

可以看到 Node 的 /etc/hosts 文件被修改,模拟了 dns 解析异常的场景。

停止实验

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

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

节点磁盘相关场景

kubernetes 节点磁盘场景。

节点磁盘填充场景

实验目标:指定节点磁盘占用 80%

开始实验

选择一个节点,修改 fill_node_disk_by_names.yaml 中的 names 值。

fill_node_disk_by_names.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: fill-node-disk-by-names
spec:
  experiments:
  - scope: node
    target: disk
    action: fill
    desc: "node disk fill"
    matchers:
    - name: names
      value: ["docker20"]
    - name: percent
      value: ["80"]

执行命令,开始实验:

$ kubectl apply -f fill_node_disk_by_names.yaml

查看实验状态

执行 kubectl get blade fill-node-disk-by-names -o json 命令,查看实验状态。

观测结果

可以看到磁盘占用 80%。

# 进入实验 node
$ ssh kk@192.168.1.129
# 查看磁盘使用率
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.9G     0  7.9G   0% /dev
tmpfs           1.6G  2.2M  1.6G   1% /run
/dev/sda2        98G   73G   20G  79% /
tmpfs           7.9G     0  7.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/loop1       90M   90M     0 100% /snap/core/8268
tmpfs           1.6G     0  1.6G   0% /run/user/1000
/dev/loop0       98M   98M     0 100% /snap/core/9289

节点磁盘填充场景

停止实验

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

或者直接删除 blade 资源:kubectl delete blade fill-node-disk-by-names

节点进程相关场景

kubernetes 节点进程相关场景。

杀节点上指定进程

实验目标:此实验会删除指定节点上的 redis-server 进程。

开始实验

选择一个节点,修改 kill_node_process_by_names.yaml 中的 names 值。

kill_node_process_by_names.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: kill-node-process-by-names
spec:
  experiments:
  - scope: node
    target: process
    action: kill
    desc: "kill node process by names"
    matchers:
    - name: names
      value: ["docker20"]
    - name: process
      value: ["redis-server"]

执行命令,开始实验:

$ kubectl apply -f kill_node_process_by_names.yaml

查看实验状态

执行 kubectl get blade kill-node-process-by-names -o json 命令,查看实验状态。

观测结果

# 进入实验 node
$ ssh kk@192.168.1.129
# 查看 redis-server 进程号
$ ps -ef | grep redis-server
root     31327 31326  0 06:15 ?        00:00:00 redis-server *:6379
# 可以看到进程号发生了变化
$ ps -ef | grep redis-server
root      2873  2872  0 06:23 ?        00:00:00 redis-server *:6379

redis-server 的进程号发生改变,说明被杀掉后,又被重新拉起。

杀节点上指定进程

停止实验

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

或者直接删除 blade 资源:kubectl delete blade kill-node-process-by-names

挂起节点上指定进程

实验目标:此实验会挂起指定节点上的 redis-server 进程。

开始实验

选择一个节点,修改 stop_node_process_by_names.yaml 中的 names 值。

stop_node_process_by_names.yaml 内容:

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: stop-node-process-by-names
spec:
  experiments:
  - scope: node
    target: process
    action: stop
    desc: "kill node process by names"
    matchers:
    - name: names
      value: ["docker20"]
    - name: process
      value: ["redis-server"]

执行命令,开始实验:

$ kubectl apply -f stop_node_process_by_names.yaml

查看实验状态

执行 kubectl get blade stop-node-process-by-names -o json 命令,查看实验状态。

观测结果

# 进入实验 node
$ ssh kk@192.168.1.129
# 查看 redis-server 进程号
$ ps aux| grep redis-server
root      5632  0.0  0.0  41520  4168 ?        Tl   06:28   0:06 redis-server *:6379

可以看到 redis-server 此刻进程处于暂停状态了(T)。

挂起节点上指定进程

停止实验

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

或者直接删除 blade 资源:kubectl delete blade stop-node-process-by-names

结语

本篇我们使用 ChaosBlade Operator 对 Kubernetes Node 资源进行混沌工程实验,可以看到对于 Node 节点,ChaosBlade 依旧有简单的配置及操作来完成复杂的实验,可以通过自由组合,实现各种 Node 节点级别的复杂故障,验证 Kubernetes 集群的稳定性及可用性。同时当真正的故障来临时,由于早已模拟了各种故障情况,可以快速定位故障源,做到处变不惊,轻松处理故障。

<img src="https://tva3.sinaimg.cn/large/ad5fbf65gy1gfm3j2vo79g20b90b9x6r.gif" style="width: 150px;">

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
NoSQL Java 应用服务中间件
ChaosBlade常见问题之无法删除chaosblades.chaosblade.io如何解决
ChaosBlade 是一个开源的混沌工程实验工具,旨在通过模拟各种常见的硬件、软件、网络、应用等故障,帮助开发者在测试环境中验证系统的容错和自动恢复能力。以下是关于ChaosBlade的一些常见问题合集:
369 0
|
9月前
|
存储 算法 关系型数据库
数据库主键与索引详解
本文介绍了主键与索引的核心特性及其区别。主键具有唯一标识、数量限制、存储类型和自动排序等特点,用于确保数据完整性和提升查询效率;而索引通过特殊数据结构(如B+树、哈希)优化查询速度,适用于不同场景。文章分析了主键与索引的优劣、适用场景及工作原理,并对比两者在唯一性、数量限制、功能定位等方面的差异,为数据库设计提供指导。
|
SQL 开发框架 .NET
高级主题:Visual Basic 中的多线程和并发编程
【4月更文挑战第27天】本文深入探讨了Visual Basic中的多线程和并发编程,阐述了其基本概念,如何使用`System.Threading.Thread`类创建线程,以及借助`ThreadPool`、`Monitor`和`SyncLock`进行同步管理。文章还提到了多线程编程面临的挑战如竞态条件、死锁和资源竞争,并介绍了VB的异步编程、TPL和并发集合等高级技术。通过实例展示了多线程在文件处理、网络通信和图像处理中的应用,并给出了多线程编程的最佳实践。总之,理解并掌握VB的多线程和并发编程能有效提升应用程序的性能和响应能力。
599 1
|
存储 弹性计算 安全
阿里云服务器配置选择策略参考及后期使用注意事项
对于初次购买阿里云服务器的一些新手用户来说,在云服务器配置选择和后期使用过程中有一些不清楚的地方,小编分享几点阿里云服务器配置选择策略,以及后期使用注意事项,购买过程中注意好下面这些事项,能让我们选对选好阿里云服务器,购买之后,在使用过程中,注意下面这些事项,能够让我们更好、更安全的使用阿里云服务器。下面是小编分享的一份详尽的阿里云服务器配置与使用指南,以供参考和借鉴。
|
自动驾驶 安全 机器人
ROS2:从初识到深入,探索机器人操作系统的进化之路
前言 最近开始接触到基于DDS的这个系统,是在稚晖君的机器人项目中了解和认识到。于是便开始自己买书学习起来,感觉挺有意思的,但是只是单纯的看书籍,总会显得枯燥无味,于是自己又开始在网上找了一些视频教程结合书籍一起来看,便让我对ROS系统有了更深的认识和理解。 ROS的发展历程 ROS诞生于2007年的斯坦福大学,这是早期PR2机器人的原型,这个项目很快被一家商业公司Willow Garage看中,类似现在的风险投资一样,他们投了一大笔钱给这群年轻人,PR2机器人在资本的助推下成功诞生。 2010年,随着PR2机器人的发布,其中的软件正式确定了名称,就叫做机器人操作系统,Robot Op
695 14
|
域名解析 网络协议 虚拟化
vmware 提供的三种网络工作模式
本文介绍了VMware虚拟机的三种网络工作模式:Bridged(桥接模式)、NAT(网络地址转换模式)和Host-Only(仅主机模式)。桥接模式将虚拟机与主机通过虚拟网桥连接,实现与物理网络的直接通信;NAT模式通过虚拟NAT设备和DHCP服务器使虚拟机联网;Host-Only模式则将虚拟机与外网隔离,仅与主机通信。此外,文章还简要介绍了网络相关的基础知识,包括主机名、IP地址、子网掩码、默认网关和DNS服务器。
728 4
|
算法 Java 开发者
《黑神话:悟空》Xbox版的技术挑战与解决方案
【8月更文第26天】《黑神话:悟空》是一款备受期待的动作角色扮演游戏,以其精美的画面和丰富的中国神话故事背景而闻名。本篇文章将重点介绍游戏在Xbox平台上的技术挑战及其解决方案,特别是针对内存管理的问题。通过深入分析,我们将了解开发团队是如何克服这些挑战,确保游戏在Xbox上能够流畅运行的。
538 4
|
数据采集 搜索推荐 JavaScript
Uniapp连接iBeacon设备——实现无线定位与互动体验(理论篇)
Uniapp连接iBeacon设备——实现无线定位与互动体验(理论篇)
598 0
|
分布式计算 资源调度 Hadoop
Hadoop 1 与 Hadoop 2 的区别详解
【8月更文挑战第31天】
532 0
|
网络协议 安全 网络安全
WireShark 中的数据包捕获和过滤器详解
【8月更文挑战第20天】
2108 0