概述

高可用测试是通过向系统中注入故障来确认服务在某些故障场景下是不中断的。目前很多容器云产品是基于k8s架构设计的，k8s的replicationSet，deployment，daemonset等容器部署方式天然具有高可用特性，为开发人员和用户提供了便利的高可用服务部署方式。另外容器云产品的集群一般是由多个node和master节点组成的，这些节点之间也是具有高可用的。所以容器产品中的高可用设计是一个常见且必备的功能，本文来介绍容器云产品中的高可用特性测试方法。

高可用测试类别

按照服务的部署运行方式和粒度大小可将高可用测试分为以下几类：线程/进程高可用，pod 高可用，node高可用，可用区高可用。

线程/进程高可用

云平台中有些服务是通过线程、进程启动的，这种服务的高可用测试故障注入往往通过命令停止/启动，如果是系统级进程，可通过systemctl命令操作，如果是普通线程则使用ps命令控制。测试的目的是确认停止/关闭某些进程或者线程之后，不影响整个服务的运行。

容器高可用

云平台中更常见的服务部署方式是容器，将服务封装在容器中运行，具有更好的可移植性。K8S架构中容器是运行在pod中的，pod是最小的调度单位，且pod往往是通过一些副本管理器来进行管理, 副本管理器通常是自身具备高可用特性的，比如K8S中的replicationSet、deployment和daemonSet，通过副本管理器管理的pod被删除之后可自动重新创建，整个过程不影响服务运行。如果要测试这种服务的高可用性，即down掉其中一个副本的故障场景，需采用K8S的scale方法对副本进行缩容，反之，通过扩容进行恢复副本。

另外还有些服务是部署在静态pod中的，通常用于运行集群中管控面的组件。静态pod仅存在于特定的节点上，由其对应的配置文件来创建，当配置文件被周期性扫描到的时候就会自动创建pod。这种pod是不可以直接被删除的，删除之后，当配置文件再次被扫描到的时候pod又会被重新创建。所以如果要注入这种pod被删除的故障,只能到其所在node上将其定义的配置文件从特定目录下移除或者将node 关掉，反之，通过将配置文件放回去或重启node来恢复pod。

Node高可用

容器云平台通常是部署在集群中，集群由多个节点组成，包括主节点和工作节点，主节点上主要运行集群管控面的服务，这些服务都是比较重要的服务，所以通常会以多副本的形式运行在多个节点上，这样如果一个节点down掉，不影响整个集群的功能，所以这是一种节点高可用设计。这种节点高可用测试通常会采取对节点重启/关机/断电/断网的方式制造故障，确认节点故障不影响整个系统的运行。如图1，当其中一个node发生故障的时候，其上面的pod会被迁移到其他node上，从而不影响容器中服务的运行。

                                                                                            图1 集群中pod在node上的分布

AZ高可用

       AZ(Available Zone)高可用设计通常用于对数据存储容灾性要求较高的场景，用户一般会选择将数据存放在支持多AZ的区域，以保证在断电/断网/火灾等故障和灾害发生时，数据不丢失、业务不中断。目前容器云平台部署的时候也会考虑多AZ的部署方式，比如将一个集群的节点平均分散到各个AZ上，这样集群就具备了AZ高可用性能，当一个AZ发生故障时，集群仍然可以正常运行。而这种AZ级别的故障通常影响比较大，因为AZ上部署的业务比较多，所以测试的时候，如果只是单纯测试AZ故障对集群的影响，通常采取对一个AZ上的集群节点进行关机/断电/断网操作来注入故障。如图2，当一个AZ发生故障时，即此AZ上所有node都不可用的时候，集群中仍有其他node在运行，此时不影响整个集群的功能。

                                                                                                       图2 集群的多AZ部署架构

    以上就是容器云平台部署架构中常见的高可用测试类别和测试方法，当然高可用还包括region级别的容灾，这个就是行业中普遍采用的高可用设计了，就不在这里介绍了。