本篇概览
- 本章是《Kubernetes下web服务的性能测试三部曲》系列的终篇，之前我们用AB和JMeter两种工具压测了k8s环境下的Tomcat，并通过调整内存和CPU来验证纵向扩容的效果，本章我们来验证横向扩容对吞吐量的影响；
前文列表
《Kubernetes下web服务的性能测试三部曲》的前两篇文章请点击以下链接：
- 《Kubernetes下web服务的性能测试三部曲之一：准备工作》；
- 《Kubernetes下web服务的性能测试三部曲之二：纵向扩容》；
基本环境信息
- 基本环境的配置，与第一章一致，Tomcat的deployment配置如下：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: tomcathost
spec:
replicas: 1
template:
metadata:
labels:
name: tomcathost
spec:
containers:
- name: tomcathost
image: bolingcavalry/k8stomcatdemo:0.0.5
tty: true
ports:
- containerPort: 8080
resources:
requests:
memory: "512Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "100m"
注意，本章实战的Pod内存为512M，因为256M的Pod吞吐率太低，从启动到预热(用来应对JIT的第一次测试，丢弃成绩)，都会耗费大量时间，因此用512M可以节省测试时间；
- 请按照上述配置将deployment和service在k8s环境启动起来，启动命令如下，在tomcat.yaml文件所在目录下：
kubectl create -f tomcat.yaml,tomcat-svc.yaml
横向扩容，将Pod数从1增加到8
- 将Pod数从1增加到8，执行以下命令即可：
kubectl scale deployment tomcathost --replicas=8
-
因为新的Pod创建、启动、初始化等操做，需要等待几分钟再进行测试；
-
继续继续AB和JMeter测试，然后再分别将replicas参数设置为4、2、1，得到结果如下表所示：
| 内存 | CPU | Pod数 | 吞吐率（AB） | 吞吐率（JMeter） |
|---|---|---|---|---|
| 512M | 0.1 | 1 | 38.17 | 38.00 |
| 512M | 0.1 | 2 | 62.92 | 78.67 |
| 512M | 0.1 | 4 | 98.11 | 112.91 |
| 512M | 0.1 | 8 | 246.51 | 277.77 |
- 以上的结果可以发现，随着Pod数的翻倍，吞吐量也是在线性增长的，增长的效果接近翻倍，也就是说横向扩容并没有出现纵向扩容时的那种单机极限的瓶颈，在节点数量得以保证的情况下，可以通过横向扩容来提升吞吐量（因为硬件资源的限制，我这里只能将Pod扩展到8个，如果您有条件可以继续测试下去）；
节省测试时间的方法
- 正常的测试顺序是副本数从1到2，然后从2到4，再从4到8，这样每次扩容后都会有容器创建，都要等待Pod创建和初始化，然后还要预热(避免JIT的影响)，所以，本次实战我的顺序是一开始直接扩容到8个Pod，然后等待创建和初始化，再正常预热，用AB和JMeter测试Pod等于8的吞吐量，然后将Pod数从8缩减到4，缩减后剩下的4个Pod都是缩减之前用过的，不需要再预热就能直接压测了，这样从8到4，从4到2，从2到1的几次缩减都不需要等待初始化和执行预热了；
和上一章的数据差异
-
细心的读者会发现，本章在Pod内存为512M的时候，吞吐量的数字和上一章是不同的，因为本章使用的硬件资源和上一章有所不同所致，但是实战的软件环境、步骤和镜像都是完全相同的；
-
至此，《Kubernetes下web服务的性能测试三部曲》就全部结束了，希望能对你您在K8S环境下的扩容和压测都有所帮助，也欢迎您的关注和来信探讨：zq2599@gmail.com
