主题: 运维环境基准测试-存储基准测试-K8S一致性测试-k8s性能测试

 

简单记录一下今天同事分享的基础环境基准测试方案，主要包括两方面，存储方面的性能、K8S平台的功能和性能.

 

一、存储基准性能测试（以下仅指ETCD存储基准测试）

 

1、背景：目前我们底层采用的是etcd存储方式，由于底层存储的性能会影响上层系统的性能，因此需要对etcd的性能进行一定的评估。

2、决定etcd性能的关键因素：

• 延迟 (latency)：延迟是完成操作的时间。包括2部分时间网络IO（影响因素：本地网络IO延迟 vs异地网络IO延迟）和磁盘IO(不同硬盘类型差别较大)
• 吞吐量 (throughput)：吞吐量是在某个时间期间之内完成操作的总数量。当 etcd 接收并发客户端请求时，通常平均延迟随着总体吞吐量增加而增加。

3、测试方式：使用etcd自带工具benchmark CLI来评测 etcd 的性能，模拟不同场景下的写入和读取

写入测试：构造不同数量的客户端、连接数、key的大小以及写向leader还是所有成员等单、多并发等场景

读取操作：构造单客户端读取、多客户端并发读取场景，同时考虑线性化读取以及串行化读取（由于 etcd 是强一致性的，其默认读取测试就是线性化读取）

• 线性化(Linearizable)读取：请求要通过集群成员的法定人数来获取最新的数据。
• 串行化(Serializable)读取：请求比线性化读取要廉价一些，因为他们是通过任意单台 etcd 服务器来提供服务，而不是成员的法定人数，代价是可能提供过期数据。

4、测试结果：通过对不同场景测试，使用命令模拟串行、并行、高并发等情况下的操作，获取相关场景下的平均写入/读取QPS、请求平均延迟测试报告数据。

5、测试过程监控：必须看，并且截图，以便查看压测过程中etcd的表现

• 看etcd本身监控

Leader指标：集群是否稳定看这个是否一直在涨，如果一直在变，说明集群不稳定，一直在换leader

内存、磁盘IO、网络指标

• 看etcd服务器、集群每台机器的资源是否有问题：

cpu是否特别低，内存不应该涨太快，磁盘不应该涨太快

6、结果物包含：测试脚本+监控+测试结果数据以及和标准的对比偏差，之后在这些数据的基础上结合官方参考测试报告数据进行定性分析。

7、参考博文：

https://blog.51cto.com/dangzhiqiang/2286892

https://blog.csdn.net/alex_yangchuansheng/article/details/102493816

 

二、集群一致性测试（功能方面）（以下仅指K8S集群一致性功能测试）

 

1、目的：我们目前采用k8s集群，集群一致性主要是确认是否符合k8s的功能标准，k8s的功能是否是正常的。

2、测试方案及测试原理：

   测试方式使用标准用例集（约3k个，主要为功能方面），每个用例集的测试过程主要是：测试管理服务启动一个个e2e测试集 ，每个测试集会新建一个namespace，并在该namespace中新建测试使用的POD ，每个测试集完成后，sonobuoy会删除对应的namespace

   3、测试过程及步骤：秋生wiki地址：ps://gitlab.gridsum.com/gov_law_tech/platform/kubernetes-production-ready/blob/master/07-1.%E9%9B%86%E7%BE%A4%E4%B8%80%E8%87%B4%E6%80%A7%E6%B5%8B%E8%AF%95.md#Sonobuoy%E5%8E%9F%E7%90%86

   4、测试结果：生成的报告中有pass、fail项，可以定量分析，同时可以针对fail项进行分析，fail的不一定是问题，要具体分析

   5、测试时长：约3小时

   6、 结果物：测试报告，可不太关注监控，功能测试对性能影响不大

 

三、集群性能测试（以下仅指K8S集群性能测试）

 

1. 简介：集群性能测试通常包括多种性能，比如有：

批量处理性能：如几秒钟内启动、停、重启大批量容器，平台是否有失败、挂起，目前仅关注这部分的性能测试方法

网络性能：虚拟机层面以及虚拟机之上的集群网络，此部分暂不包括

1. K8S批量处理性能

处理过程：镜像放到私有仓库》镜像放到多个node上》master上执行，每台node都放一份打标签》执行>部署到k8s》创建pod…

1. 测试内容：主要是对集群批量启动、如启动几十个的时候多少秒
2. 测试结果：有报告，包括启动时长等数据，可以参考数据进行定量分析
3. 测试时长：10多分钟，比较快
4. 监控：需要看看ETCD、IO、CPU、内存等