故障模拟和稳定性的探索 ｜ DaoCloud Enterprise 5.0 的混沌工程实践

在技术飞速发展的时代，系统的稳定性和高可用性已成为衡量产品质量的关键因素。面对复杂多变的客户应用环境，确保系统在各种极端条件下稳定运行是技术团队必须解决的挑战。

为了应对这一挑战，「DaoCloud 道客」的技术团队在核心产品 DaoCloud Enterprise 5.0 上（以下简称 DCE 5.0）进行了混沌测试，通过引入故障和不稳定因素来验证系统的稳定性和可用性。其主要目标是确保在面对意外事件（如软件故障、硬件故障、网络延迟、服务中断等）时，系统能够保持高可用和稳定运行。

在这个测试中，团队主要使用了混沌测试工具 Chaos Mesh，通过模拟各种故障场景，提前发现并解决潜在的系统问题，提升了 DCE 5.0 的稳定性和可靠性。

混沌工程
的简介

混沌工程的核心思想是通过不断制造故障（软件或硬件故障）来验证和改进系统的容错和恢复能力，从而提升系统的整体稳定性和可靠性。

结合 DCE 5.0 的特点，「DaoCloud 道客」技术团队总结了混沌测试的方法与流程，主要包括以下 7 个关键步骤：

1、确定混沌测试目标和预期效果：

• 明确混沌测试的具体目标，设定可衡量的预期效果。

• 根据产品的功能进行分析后设定目标，明确的目标对故障场景的设计具有指导性。

2、收集系统正常运行时的关键指标：

• 明确系统在正常运行时核心业务的指标和收集方法，以便在故障注入后进行对比分析。

3、分析系统架构，设计故障场景：

• 深入分析系统架构，识别关键组件和组件依赖关系，设计有针对性的故障场景。

4、集成至 Gitlab CI/CD流水线：

• 将设计的故障场景集成到CI/CD流水线，实现混沌测试的自动化和持续执行。

5、执行故障注入与指标、日志收集：

• 按照设计的场景进行故障注入，记录系统状态，持续监控和收集核心业务相关指标和日志，验证系统是否能够及时恢复。

6、混沌测试结果分析：

• 对比故障注入前后的系统指标，分析结果是否符合预期，找出系统的弱点和改进点。

7、问题修复验证：

• 对发现的缺陷进行修复，并重复测试，直到系统在混沌测试中的表现达到预期。

02

工具简介

DCE 5.0 混沌测试使用了 Chaos Mesh，它是一个开源的云原生混沌工程平台，专门用于在云原生环境中进行故障注入和混沌测试。它提供了丰富的故障注入功能，包括但不限于网络延迟、网络分区、服务宕机、资源耗尽、磁盘故障等。它的优势在于能够精确控制故障的类型、范围和时间，从而模拟出真实的故障场景。此外，Chaos Mesh 还提供了可视化界面和丰富的日志记录功能，帮助技术团队实时监控和分析系统在故障注入过程中的表现。

Chaos Mesh 的整体架构如上图所展示，可以自上而下分为三个部分：

• 用户输入和观测。用户输入以用户操作 (User) 为起点到达 Kubernetes API Server。用户不直接和 Chaos Mesh 的 Controller 交互，一切用户操作最终都将反映为某个 Chaos 资源的变更（比如 NetworkChaos 资源的变更）。

• 监听资源变化、调度工作流和开展混沌实验。Chaos Mesh 的 Controller 只接受来自 Kubernetes API Server 的事件，这种事件具体描述某个 Chaos 资源的变更，例如新的工作流对象或者 Chaos 对象被创建。

• 具体节点故障的注入。该部分主要由 Chaos Daemon 组件负责，接受来自 Chaos Controller Manager 组件的指令，侵入到目标 Pod 的 Namespace 下，执行具体的故障注入。例如设置 TC 网络规则，启动 stress-ng 进程抢占 CPU 或内存资源等。

03

新一代云原生操作系统
DaoCloud Enterprise 5.0

04

混沌工程在 DCE 5.0
测试中的应用

为了有效应对系统故障和事件，我们需要深入分析和设计系统故障场景。设计 DCE 5.0 故障场景是一个系统化的过程，涉及对系统架构、关联组件、存储、数据库、应用依赖、系统资源以及历史生产事件的分析，以识别和预防系统可能遇到的故障问题。

根据 DCE 5.0 系统架构，分析和设计出以下故障场景。主要围绕云原生底座、中间件、核心组件 3 个层面：

4.1 系统测试中的应用

在系统测试中，我们对 DCE 5.0 平台的所有产品组件进行了全面的混沌测试，重点关注以下目标和关键场景：

测试目标：

1、访问入口高可用性：测试 MetalLB 和 Istio-ingressgateway 的高可用性。

2、可观测组件高可用性：测试可观测组件的高可用性。

3、全局集群核心组件高可用性：测试全局集群核心组件的故障恢复能力。

4、中间件高可用性：测试 MySQL-MGR、Redis、Kafka、Elasticsearch、PostgreSQL、Minio 等中间件的高可用性。

5、HwameiStor 存储高可用性：测试 HwameiStor 存储组件的高可用性。

关键场景：

1、Pod 故障：包括 Pod 被系统终止、Pod 崩溃不可用、指定容器运行时被系统终止。

2、网络故障：包括网络断开、网络分区、网络延迟、网络丢包、网络抖动等场景。

3、压力测试：包括 CPU/内存高压力、Pod 内存溢出、磁盘 I/O 缓慢等场景。

4、其他故障场景：包括服务器主机宕机/重启、数据库切换、组件高可用性切换、依赖故障等场景。

依靠 Redis、MySQL-MGR、PostgreSQL 数据库、HwameiStor 存储等，我们期望在"基础设施"异常故障场景下，DCE 5.0 能够正常提供服务和故障自愈。以下是一些常见的故障类型：

故障场景 1：redis-master 实例的 pod failure 30s

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: podfailure-mcamel-common-redis-cluster-master
  namespace: mcamel-system
spec:
  action: pod-failure
  mode: one
  duration: '30s'
  selector:
    labelSelectors:
      'redisfailovers-role': 'master'
      'app.kubernetes.io/name': 'mcamel-common-redis-cluster'

故障场景 2："MySQL-MGR 单主集群"注入网络延迟:1ms、5ms、10ms

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: delay-mcamel-common-mgr-cluster
  namespace: mcamel-system
spec:
  # 进行延迟模拟
  action: delay
  mode: all
  selector:
    namespaces:
      - mcamel-system
    labelSelectors:
      #当前 PRIMARY角色
      'mysql.oracle.com/instance-type': 'group-member'
      'mysql.oracle.com/cluster': 'mcamel-common-mgr-cluster'
      'mysql.oracle.com/cluster-role': 'PRIMARY'
  duration: 5m
  delay:
    latency: '5ms'
    correlation: '0'
    jitter: '0ms'
  direction: from
  target:
    selector:
      namespaces:
        - mcamel-system
      labelSelectors:
        # 当前SECONDARY角色
        'mysql.oracle.com/instance-type': 'group-member'
        'mysql.oracle.com/cluster': 'mcamel-common-mgr-cluster'
        'mysql.oracle.com/cluster-role': 'SECONDARY'

    mode: all

故障场景 3:"MySQL-MGR 单主集群"网络分区场景(PRIMARY 与 SECONDARY 实例)

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: mcamel-common-mgr-cluster-partition
spec:
  action: partition
  mode: all
  selector:
    namespaces:
      - mcamel-system
    labelSelectors:
      #PRIMARY实例
      'statefulset.kubernetes.io/pod-name': 'mcamel-common-mgr-cluster-0'
  direction: to
  target:
    mode: all
    selector:
      namespaces:
        - mcamel-system
      labelSelectors:
        #SECONDARY实例
        'statefulset.kubernetes.io/pod-name': 'mcamel-common-mgr-cluster-1'

4.2 与 GitLab 集成

在测试过程中，团队将系统测试中的故障场景集成到 GitLab 流水线中。通过 GitLab 的定时任务触发混沌测试。同时在"稳定性测试环境"和"每日构建最新的 DCE 5.0 环境"中运行这些场景，实现混沌测试的自动化和持续执行，从而确保产品的高可用性和稳定性。Gitlab 的流程主要分为以下几个步骤：

1、触发 GitLab 流水线以开始混沌测试。

2、启动 GitLab Runner 使用 Docker 启动一个 GitLab Runner 执行混沌测试。

3、执行环境检查，校验 DCE 5.0 环境以及被测对象是否正常运行。

4、安装 Chaos Mesh 工具

• 准备离线的 Chaos Mesh 镜像。

• 使用 Helm 安装 Chaos Mesh 工具。

• 验证工具是否安装成功。

5、创建业务场景（全局管理、容器管理），模拟用户真实负载。

6、执行故障注入

• 通过 shell 脚本执行故障注入，包括 Pod 异常、节点宕机、网络延迟、磁盘故障。

• 检查被测对象是否在正常时间范围内恢复。

7、观察混沌测试结果

• 观察混沌测试结果，收集测试过程日志

• 使用 DCE 5.0 可观测组件，监控系统整个的行为和响应。

8、故障恢复与清理

完成测试后，进行故障恢复并清理测试环境。

以下是 .gitlab-ci.yaml 的部分示例（chaos-redis 场景）：

#环境检查 precheck

#检查redis的状态
redis_precheck:
  rules:
      - if: '$CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_TYPE == "chaos-redis"'
  stage: redis_precheckchaos
  script:
    - make redis_precheckchaos  
  tags:  
    - hse2e 
  timeout: 1h

#安装 Chaos Mesh

install-chaos:  
  rules: 
    - if: '$CI_PIPELINE_SOURCE == "schedule" && ($SCHEDULE_TYPE == "chaos-redis")'   
    - when: never  
  stage: installchaos  
  script:    
    - make installchaos  
  tags:  
    - hse2e 
  timeout: 3h

#流水线触发故障注入：删除 redis-master 实例的 pod

#删除 redis-master实例的pod
chaos_delete_redis_master:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_TYPE == "chaos-redis"'
  stage: chaos_delete_redis_master
  script:
    - make chaos_delete_redis_master
  tags:
    - hse2e

#流水线触发故障注入：删除 redis 哨兵+实例的 pod

#删除 redis哨兵+实例的pod
chaos_delete_redis_all_pods:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_TYPE == "chaos-redis"'
  stage: chaos_delete_redis_all_pods
  script:
    - make chaos_delete_redis_all_pods
  tags:
    - hse2e

#清理环境

clean:  
  rules:    
    - if: '$CI_PIPELINE_SOURCE == "schedule" && ($SCHEDULE_TYPE == "chaos-mysql" || $SCHEDULE_TYPE == "chaos-redis")'    
    - when: never  
  stage: cleanchaos  
  script:    
    - make cleanchaos  
  tags:    
    - hse2e  
  timeout: 3h

05

结论

在引入 Chaos Mesh 之前，DCE 5.0 的混沌测试过程充满了挑战和困难：

• 手动测试繁琐：早期的混沌测试需要大量的手动操作，包括模拟故障、监控系统状态和记录结果。这不仅耗时耗力，还容易出现人为错误，导致测试结果的不准确。

• 故障模拟有限：手动测试的故障模拟范围有限，难以覆盖所有可能的异常场景。常见的测试场景如网络延迟、节点宕机、Pod 频繁启动、网络抖动，往往需要手动干预和复杂的操作步骤，难以实现精确控制。

通过在 DCE 5.0 中引入 Chaos Mesh 并实施全面的混沌工程测试，显著提升了 DCE 5.0 的稳定性和高可用性。具体体现在：

• 提前发现潜在问题：通过模拟各种极端故障场景，我们能够提前发现 DCE 5.0 中的潜在脆弱点，比如中间件组件，很多有状态负载运行在中间件组件之上，需要中间件稳定高可用。这些问题在生产环境中可能会导致严重的服务中断，但通过提前发现和修复，我们减少了这些潜在风险。

• 多维度测试覆盖：Chaos Mesh 提供了丰富的故障注入功能，使我们能够在多个层面上进行测试，包括但不限于网络延迟、节点宕机、磁盘故障等。这样的多维度测试覆盖确保了 DCE 5.0 在各种条件下的可靠性。

• 优化系统架构：在测试过程中，团队发现了一些系统架构上的不足之处，并进行了相应的优化，比如可观测组件的高可用，系统日志需要持续读写，不然会影响监控和告警的实时性和准确性。通过设置重要有状态负载的亲和性，反亲和性，污点，副本数量以及其他参数配置，提升了系统的高可用。

参考

[1] chaos-mesh：
https://chaos-mesh.org/

[2]《混沌工程实践指南》中国信通院：
http://www.caict.ac.cn/kxyj/qwfb/ztbg/202112/P020211223588643401747.pdf

[3]《混沌工程：复杂系统韧性实现之道》：
https://xueshu.baidu.com/usercenter/paper/show?paperid=135v06u0s81h00w0v92002f08f344674&site=xueshu_se

 本文作者 

「DaoCloud 道客」云原生测试工程师

热门推荐

            

访问以下网址，或点击文末【阅读原文】立即体验