Kubernetes下web服务的性能测试三部曲之三：横向扩容

本章是《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

将Pod数从1增加到8，执行以下命令即可：

kubectl scale deployment tomcathost --replicas=8

因为新的Pod创建、启动、初始化等操做，需要等待几分钟再进行测试；

继续继续AB和JMeter测试，然后再分别将replicas参数设置为4、2、1，得到结果如下表所示：

以上的结果可以发现，随着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环境下的扩容和压测都有所帮助，