关于云计算:云原生-混沌工程工具-ChaosBlade-Operator-入门篇

37次阅读

共计 4681 个字符，预计需要花费 12 分钟才能阅读完成。

近日，国内多家网站同时产生短期服务不可用景象，一夜冲上圈内热搜。据官网回答，是因为局部服务器机房产生故障，导致网站无法访问。为了防止这种状况，进步零碎架构的可靠性，保障业务的连续性，心愿能在故障之前找到导致“崩盘”的缺口。

十多年前，国外的互联网公司就曾经在云化、分布式、微服务等前沿技术的应用过程中，遇到了相似的问题，并由此诞生了混沌工程。

什么是混沌工程？

混沌工程即 Chaos Engineering[1]，被定义为在分布式系统上进行试验的学科，目标是建设对系统抵挡生产环境中失控条件的能力以及信念。混沌工程属于一门新兴的技术学科，是一种进步技术架构弹性能力的简单技术手段。最早由 Netflix 技术部门创立了名为 Chaos Monkey 的我的项目，通过随机性测试，来检测零碎架构的衰弱状况，并设计足够的预案来应答可能到来的新一轮故障。

随着云化技术的倒退和云原生 (Cloud Native) 的概念的提出，混沌工程的反软弱哲学思想，也引入了云原生体系，可简略高效地为零碎进步容错能力。

什么是 ChaosBlade Operator？

ChaosBlade[2] 是阿里巴巴开源的一款遵循混沌工程原理和混沌试验模型的试验注入工具，帮忙企业晋升分布式系统的容错能力，并且在企业上云或往云原生零碎迁徙过程中业务连续性保障。

而 ChaosBlade Operator[3] 是 Kubernetes 平台试验场景的实现，将混沌试验通过 Kubernetes 规范的 CRD 形式定义，很不便的应用 Kubernetes 资源操作的形式来创立、更新、删除试验场景，包含应用 kubectl、client-go 等形式执行，而且还能够应用上述的 chaosblade cli 工具执行。

把试验定义为 Kubernetes CRD 资源，将试验模型中的四局部映射为 Kubernetes 资源属性，完满将混沌试验模型与 Kubernetes 申明式设计联合在一起（依附混沌试验模型便捷开发场景，并联合 Kubernetes 设计理念）。

  • 通过 kubectl 或者编写代码间接调用 Kubernetes API 来创立、更新、删除混沌试验，可清晰获取资源模拟实验的执行状态，实现 Kubernetes 故障注入的标准化。
  • 通过 Chaosblade cli 形式可十分不便的执行 Kubernetes 试验场景，查问试验状态等。
  • ChaosBlade 混沌试验模型与 Kubernetes CRD 的联合，实现 根底资源、应用服务、Docker 容器 等场景复用，不便 Kubernetes 场景的扩大。

反对的场景

目前反对的试验场景有以下三大类（继续更新中）：

部署 ChaosBlade Operator

执行 Kubernetes 试验场景前，需 提前部署 ChaosBlade Operator。

Helm 包下载地址：https://github.com/chaosblade…

本系列文章默认 Helm v3 版本

留神：须要新建一个 namespace！
部署指令：

helm install kube-system/chaosblade-operator-1.2.0-v3.tgz
helm install chaosblade-operator chaosblade-operator-1.2.0-v3.tgz --namespace chaosblade

回显示例：

ChaosBlade Operator 启动后，将在每个节点别离部署 chaosblade-tool 和 chaosblade-operator Pod。通过如下指令查看部署后果，若 Pod 都处于 Running 状态，则部署胜利。

kubectl get pod -n chaosblade -o wide | grep chaosblade

查问部署后果示例：

对于部署失败的常见起因，请关注后续 混沌工程工具系列 专题介绍。

试验环境

本系列文章将应用在 KubeSphere 上装置的 ChaosBlade Operator，对 RadonDB 系列容器化产品进行测试。

KubeSphere 环境参数：

  • 规格 8 核 16G
  • 磁盘大小 500GB
  • 节点数 4

在 KubeSphere 环境部署胜利后，控制台状态如下图所示。

测试对象

基于 KubeSphere 平台的 RadonDB MySQL 容器化数据库进行测试。
RadonDB MySQL 部署阐明请参见 在 KubeSphere 中部署 RadonDB MySQL 集群。

环境参数

测试环境部署实现后，即可从以下五个针对节点的场景做相应验证。

CPU 负载场景

1. 测试指标

指定节点做 CPU 负载 80% 验证。

2. 开始测试

配置 yaml 测试参数值。

apiVersion: chaosblade.io/v1alpha1
    kind: ChaosBlade
    metadata:
        name: cpu-lode
    spec:
        experiments:
        - scope: node
            target: cpu
            action: fulllode
            desc: "increase node cpu load by names"  #试验模型名称
            matchers:
            - name: names
                value:
                - "worker-s001"  #测试对象 node 名称
            - name: cpu-percent
                value: "80"      #节点负载百分比
            - name: ip
                value:192.168.0.20      #节点负载百分比

抉择一个节点，批改 node_cpu_load.yaml 中的 names 值。

3. 测试验证

在 Node 节点，应用 top 命令能够看到节点 CPU 达到负载 80% 预期成果。

网络提早场景

1. 测试筹备

登录 Node 节点，应用 ifconfig 命令查看网卡信息，将零碎默认的网卡名称指定到 eth0。

2. 测试指标

指定节点 worker-s001 增加 3000 毫秒拜访提早，延迟时间高低浮动 1000 毫秒。

3. 开始测试

抉择一个节点，批改 delay_node_network_by_names.yaml 中的 names 值。对 worker-s001 节点拜访丢包率 100%。

开始测试。

kubectl apply -f delay_node_network_by_names.yaml

查看试验状态。

kubectl get blade delay-node-network-by-names -o json

4. 测试验证

从节点拜访 Guestbook。

    $ time echo "" | telnet 192.168.0.18
    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

进行测试。能够删除测试过程或者间接删除 blade 资源。

kubectl delete -f delay_node_network_by_names.yaml
kubectl delete blade delay-node-network-by-names

网络丢包场景

1. 测试指标

指定节点注入丢包率 100% 的故障。

2. 开始测试

抉择一个节点，批改 loss_node_network_by_names.yaml 中的 names 值。

执行以下命令，开始测试。

    kubectl apply -f loss_node_network_by_names.yaml

执行以下命令，查看试验状态。

kubectl get blade loss-node-network-by-names -o json

3. 测试验证

端口为 Guestbook nodeport 端口，拜访试验端口无响应，然而拜访未开启试验的端口能够失常应用。

获取节点 IP。

    $ kubectl get node -o wide

从试验节点拜访 Guestbook – 无法访问。

    $ telnet 192.168.0.20

从非试验节点拜访 Guestbook – 失常拜访。

    $ telnet 192.168.0.18

此外还可间接从浏览器拜访地址，验证测试后果。

进行测试。能够删除测试过程或者间接删除 blade 资源。

    kubectl delete -f delay_node_network_by_names.yaml
    kubectl delete blade delay-node-network-by-names

kill 指定过程

1. 测试指标

删除指定节点上的 MySQL 过程。

2. 开始测试

抉择一个节点，批改 kill_node_process_by_names.yaml 中的 names 值。

执行以下命令，开始测试。

    $ kubectl apply -f kill_node_process_by_names.yaml

执行以下命令，查看试验状态。

    kubectl get blade kill-node-process-by-names -o json

执行以下命令，查看试验状态。

3. 测试验证

进入试验 node。

    $ ssh 192.168.0.18

查看 mysql 过程号。

    $ ps -ef | grep mysql
    root     10913 10040  0 14:10 pts/0    00:00:00 grep --color=auto mysql

能够看到过程号产生了变动。

    $ ps -ef | grep mysql

MySQL 的过程号产生扭转，阐明被杀掉后，又被从新拉起。

进行测试。能够删除测试过程或者间接删除 blade 资源。

    kubectl delete -f delay_node_network_by_names.yaml
    kubectl delete blade delay-node-network-by-names

stop 指定过程

1. 测试指标

挂起指定节点上的 MySQL 过程。

2. 开始测试

抉择一个节点，批改 stop_node_process_by_names.yaml 中的 names 值。

执行以下命令，开始测试。

    $ kubectl apply -f stop_node_process_by_names.yaml

执行以下命令，查看试验状态。

    kubectl get blade stop-node-process-by-names -o json

3. 测试验证

进入试验 node。

    $ ssh 192.168.0.18

查看 mysql 过程号。

    $ ps -ef | grep mysql
    root     10913 10040  0 14:10 pts/0    00:00:00 grep --color=auto mysql

能够看到过程号产生了变动。

    $ ps -ef | grep

MySQL 的过程号产生扭转，阐明被杀掉后，又被从新拉起。

进行测试。能够删除测试过程或者间接删除 blade 资源。

    kubectl delete -f delay_node_network_by_names.yaml
    kubectl delete blade delay-node-network-by-names

结语

通过应用 ChaosBlade Operator 对 KubeSphere Node 资源进行混沌工程试验，可得出如下论断：

对于 Node 节点，ChaosBlade 仍旧有简略的配置及操作来实现简单的试验，能够通过自由组合，实现各种 Node 节点级别的简单故障，验证 Kubernetes 集群的稳定性及可用性。同时当真正的故障来长期，因为早已模仿了各种故障状况，能够疾速定位故障源，做到处变不惊，轻松解决故障。

[1]. 混沌工程准则：https://principlesofchaos.org

[2]. ChaosBlade：https://github.com/chaosblade…

[3]. ChaosBlade Operator：https://github.com/chaosblade…

[4]. Kubernetes 中文文档：https://chaosblade-io.gitbook…

作者

丁源 RadonDB 测试负责人

正文完
云计算
发表至： 云计算
2021-08-16
 0
关于云计算:云端干货云原生定义解析之不可变基础设施-immutable-infrastructure
关于云计算:翻译2020全球API趋势年度报告
关于云计算:API研发实现规范化管理的价值
关于云计算:云鹰卡为什么可以做到不断网