Kubernetes下web服务的性能测试三部曲之三:横向扩容
【摘要】 本篇实战了应用的横向扩容并验证,检查扩容带来性能提升的详细情况
欢迎访问我的GitHub
这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos
本篇概览
- 本章是《Kubernetes下web服务的性能测试三部曲》系列的终篇,之前我们用AB和JMeter两种工具压测了k8s环境下的Tomcat,并通过调整内存和CPU来验证纵向扩容的效果,本章我们来验证横向扩容对吞吐量的影响;
前文列表
《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
欢迎关注华为云博客:程序员欣宸
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)