云平台架构测试（k8s+docker）

云平台架构测试基础检查点

      云平台基础架构测试，在笔者看来，最重要的是保证集群的稳定性，健壮性，面对各种 突发情况都可以自动处理，保证业务功能逻辑正常，数据正常。主要关注集群节点、集群基 础组件、集群服务等。当前各种云平台都采用了各种主从结构的集群方式，例如：一主多从， 多主等形式，采用了各种 HA 策略，有集群本身的 HA，有基础组件的 HA，也有微服务本身 的 HA，基础组件和微服务的区别是是否保存状态服务，是否持久化数据存储这些，有兴趣 可以下来了解一下，每个组件都有自己的特点，例如 mysql 本身的主从同步策略和数据盘日 志盘大小等，rabbitmq 出现脏队列的时候的异常处理等，需要再测试过程中，了解各个组件 的特性，熟悉各个组件的基本操作，然后进行相对的测试设计。 笔者水平有限，全靠脑补，还有很多没写的地方，例如：多实例测试，是否启用分布式 锁，以及微服务链路数据检查，链路压测，资源状态监控等，有不对的地方，还望指正。

                                                                                                                                                                             --成都-阿木木

一、全局配置文件检查

       一般来说，云平台在安装部署过程中，都会进行平台配置，后台在进行集群部署时，可 能是通过一键部署，自动获取集群虚机的环境信息，也可能是手动进行配置文件的修改配置， 也可能是通过浏览器界面进行配置。 针对全局配置文件是否正确初始化进行检查，各个参数配置错误是否有正确的提示信息， 例如：配置的节点数是否符合规范，大于或者小于是否有正确的提示信息；配置的 ip 是否 是正确并且可用的 IP，是否是非法 IP 以及被使用过得 IP；防火墙 IP 段是否配置正确，防火 墙 IP 端口是否配置正确，集群各个节点之间的互信等。

二、集群各组件配置检查

云平台中的各个组件的配置方式同集群安装部署的配置是一样的，要么通过修改配置文件，要么通过浏览器界面进行配置，主要关注异常情况，是否有正确的提示项。 各个组件的正确配置，以及错误参数配置项检查，是否有正确的提示信息。

三、集群安装和卸载检查

集群安装是否正常，各个微服务基础组件状态是否正常，页面数据访问是否正常；集群卸载是否正常，各个微服务包含集群本的框架卸载是否完全卸载，是否有残留的垃圾数据文件，导致二次安装失败。

四、组件监控安装卸载检查

集群通常会安装一些针对各个组件的监控服务。集群中针对各个组件的监控模块的安装卸载是否正常，是否有数据残留。

五、日志中心检查

集群通常会提供一个通用的日志服务，例如 EFK 等。集群的日志服务是否安装卸载正常；数据老化时间是否正常；当微服务的日志过大时，是否有对应的清理策略。

六、增量包安装检查

现在的云平台都是支持增量安装功能的，例如 K8S：通过修改 deployment，service等配置文件，完成服务增量安装，该场景比较常见。针对集群内部需要增量安装或升级某些微服务时，是否可以安装成功，微服务是否可以升级成功，检查微服务的 image 地址是否更改；微服务本身的实例数的修改是否生效，业务功能是否正常。

七、对于依赖公用基础组件的其他组件安装检查

基础组件本身也是会有依赖的，所以基础组件启动先后顺序也需要进行检查，是否可以 正常连接，超时重连，断线重连，是否有组件本身的 HA 策略等。未安装公用基础组件时候，单独安装某一个依赖它的组件，

八、NTP 时钟源配置检查

NTP 时钟源是集群内部需要关注的一个重点，很多时候容易忽视，其实很多时候，我们关注的不是时钟源是否和公网环境时钟源同步，更多的是关注集群各个节点的时间是否同步，当然，如果对于应用界面的数据操作有时间方面的时效性的严格要求，那么保证服务器时钟源和 PC 时钟源同步是非常重要的了。举个例子，我们在对于集群各个节点所在虚拟机进行快照的时候，会导致集群停顿一段时间，造成数据的写入不同步，集群的时间不同步等情况，如果没有对应的处理机制，会导致集群崩溃，各个服务直接 terminal 掉。未配置时钟源情况，公网环境是否会自动获取时钟源，内网环境各个节点的时钟源是否会同步；构造主节点和从节点时间跳变情况，查看集群时间以及状态是否正常，时钟源是否会自动校准。配置了时钟源情况，不通公网，当本地 PC 和集群所在服务器时钟源不匹配情况，集群时间状态如何处理。安装部署集群后，集群断电、断网情况；修改时钟源向前或者向后调整情况；集群恢复后查看集群时间以及状态。当集群中某一个节点接入了公网，其他节点不接入公网，集群时间以及状态是否正常。

九、本地化仓库检查

现在的私有云，公有云，混合云，都会有一个镜像仓库的概念在里面，镜像仓库通常都是本地仓库，针对镜像仓库所在节点进行测试也是非常有必要的，防止出现镜像拉取失败，镜像的 tar 包加载到本地镜像仓库失败等情况。当本地化仓库所在 master 节点，或者 node 节点出现问题，例如网络原因等，从本地化仓库中拉取镜像资源是否有正确的提示信息。

十、磁盘检查

磁盘大小检测，防止数据盘不够组件使用，安装前或扩容前报错；数据盘够组件使用，检查是否可以正确安装。磁盘速率检测，检查安装速率等情况，如果不满足要求，安装失败退出。

十一、集群各节点运行微服务数量状态检查

通常一个集群在安装完成后，各个节点的微服务是调度中心使用调度算法，根据当前节点的 CPU、内存、磁盘等信息，计算各个节点运行的微服务数量，各个节点运行的微服务数量应该相差不大。版本安装后，各个 node 节点的微服务数量应该是均匀分配，数量差距不大。

十二、集群节点突然宕机微服务检查

当某一个集群节点突然宕机后，宕机节点的微服务是否可以正确的迁移到正常的 node节点上，并且，微服务恢复正常，页面数据访问正常。

十三、微服务重启检查

微服务本身也是有调用顺序的，通过更改各个微服务的启用顺序，进行检查。重启各个微服务，查看微服务运行状态，如果微服务之间有依赖，可以改变重启顺序，进行检查，重启过后的微服务状态是否正常。

十四、微服务与组件启动先后顺序检查

集群的普通服务除了依赖其他普通服务之外，也会依赖基础组件，例如：在 K8S 中，有状态服务通过 statefulset 副本控制器控制，普通服务（无状态服务）通过 deployment 副本控制器控制，当普通服务依赖于公共基础组件的时候。如果普通服务先于基础组件服务启动，如果普通服务本身没有 HA，或者超时重连、断线重连机制，那么，除了手动重启普通服务本身可以恢复业务之外，会导致集群本身的健壮性有问题，给用户造成不好的体验。反过来，如果普通微服务后于基础组件服务启动，是否可以正常连接组件，保证业务功能正常，数据正常，微服务状态正常。

十五、微服务运行过程中关闭组件服务再开启组件微服务的重连机制检查

集群中如果出现组件重启（组件本身的状态检查策略，异常情况重启），那么对于普通微服务来说，是否会重新建立连接就是至关重要的了。主要检查微服务与基础组件有依赖，基础组件本身是一个有状态服务，重启有状态服务时，普通的无状态微服务可能会断开连接，如果没有重连（连接超时机制等策略），会导致微服务不可用。例如 mysql、Redis、hdfs、mongodb、fastdfs、kafka、kong、rabbitmq 等组件。普通服务已经连接组件的情况，先关闭组件，然后再重启，主要是检查普通服务对于基础组件的依赖情况，普通服务是否会自动重连，如果说组件本身是一个集群，关闭某一个组件实例，是否会对普通服务提供的业务本身造成影响等等，检查是双向的。

十六、微服务首次连接组件失败后的重连检查

普通服务未连接组件的情况，首先关闭基础组件，然后启动依赖基础组件的相关的服务，然后启动基础组件，查看微服务运行状态是否正常，业务功能是否正常。

十七、节点故障检查

1、集群单节点故障，检查是否启用 HA 检查（高可用策略）

集群单节点故障有很多种原因，通常是该节点已经宕机，或者该节点的网络通信异常，IP 被更改等多种情况，主要遍历主节点和从节点分别出现节点故障的情况，集群还是否可用，也就是现在常说的高可用策略是否生效检查。各业务场景运行流量正常上送，宕机主节点，不重启主节点，集群的 HA 是否生效，如果是 K8S 集群，VIP 是否会跟随权重漂移，组件的 HA 策略是否生效，各场景的环境恢复后，微服务自动重启或者手动重启，各微服务资源占用正常，组件正常，业务功能数据正常。各业务场景运行流量正常上送，宕机主节点，并重启所有服务，检查集群和组件的 HA 是否生效。各业务场景运行流量正常上送，宕机从节点，微服务进行节点迁移，各微服务资源占用正常，组件正常，业务功能数据正常。各业务场景运行流量正常上送，宕机从节点，微服务进行节点迁移，并且重启服务，微服务迁移到该节点，各微服务资源占用正常，组件正常，业务功能数据正常。

2、单节点重启组合检查

各业务场景运行流量正常上送，宕机主节点，VIP 是否自动漂移，重启主节点，VIP 是否自动漂移回原来的节点，所有组件的 HA 策略是否生效，微服务是否迁移到从节点，各微服务资源占用正常，组件正常，业务功能数据正常。各业务场景运行流量正常上送，宕机从节点，微服务是否迁移到其他节点，重启从节点，微服务是否自动调度迁移到该节点，各微服务资源占用正常，组件正常，业务功能数据正常。

3、多节点故障组合检查

各业务场景运行流量正常上送，宕机主节点，然后宕机从节点，VIP 是否迁移到正常的从节点，各组件的 HA 策略是否生效，各微服务资源占用正常，组件正常，业务功能数据正常。

4、多节点重启组合检查

各业务场景运行流量正常上送，宕机主节点，宕机从节点，重启从节点，再重启主节点，查看 VIP 漂移的过程是否正常，是否会回到原来的主节点，查看微服务的迁移是否正常，查看组件的 HA 策略是否生效，各微服务资源占用正常，组件正常，业务功能数据正常。

十八、整个集群异常断电重启检查

集群异常断电重启过程中，可能会导致集群本身的一些数据文件损坏，有些是不可避免的，通常采用双路电源，或者使用 UPS 等，当某些数据文件损坏时，我们集群需要对这些文件进行处理，使集群功能恢复运转。关闭整个集群后重启，所有微服务状态应该恢复正常，页面数据，功能正常；拔插服务器电源，整个集群断电恢复后，所有微服务状态应该恢复正常，页面数据，功能正常；节点与节点之间重启的时间间隔，是否会出现时钟源不同步的情况，导致整个集群崩溃。

**欢迎加入测试交流群：夜行者自动化测试（816489363）进行交流学习QAQ**

本文地址：https://blog.csdn.net/qq_39214101/article/details/107331199