本章是《Kubernetes下web服务的性能测试三部曲》系列的终篇,之前我们用AB和JMeter两种工具压测了k8s环境下的Tomcat,并通过调整内存和CPU来验证纵向扩容的效果,本章我们来验证横向扩容对吞吐量的影响; 本文地址:http://blog.csdn.net/boling_cavalry/article/details/79336661
基本环境的配置,与第一章一致,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,执行以下命令即可:
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环境下的扩容和压测都有所帮助,