网络和集群性能测试
准备
测试环境
在以下几种环境下进行测试：
Kubernetes集群node节点上通过Cluster IP方式访问
Kubernetes集群内部通过service访问
Kubernetes集群外部通过traefik ingress暴露的地址访问
测试地址
Cluster IP: 10.254.149.31
Service Port：8000
Ingress Host：traefik.sample-webapp.io
测试工具
Locust：一个简单易用的用户负载测试工具，用来测试web或其他系统能够同时处理的并发用户数。
curl
测试程序：sample-webapp，源码见Github kubernetes的分布式负载测试
测试说明
通过向sample-webapp发送curl请求获取响应时间，直接curl后的结果为：
网络延迟测试
场景一、 Kubernetes集群node节点上通过Cluster IP访问
测试命令
10组测试结果
1
0.000
0.003
0.003
2
0.000
0.002
0.002
3
0.000
0.002
0.002
4
0.000
0.002
0.002
5
0.000
0.002
0.002
6
0.000
0.002
0.002
7
0.000
0.002
0.002
8
0.000
0.002
0.002
9
0.000
0.002
0.002
10
0.000
0.002
0.002
平均响应时间：2ms
时间指标说明
单位：秒
time_connect：建立到服务器的 TCP 连接所用的时间
time_starttransfer：在发出请求之后，Web 服务器返回数据的第一个字节所用的时间
time_total：完成请求所用的时间
场景二、Kubernetes集群内部通过service访问
测试命令
10组测试结果
1
0.004
0.006
0.006
2
0.004
0.006
0.006
3
0.004
0.006
0.006
4
0.004
0.006
0.006
5
0.004
0.006
0.006
6
0.004
0.006
0.006
7
0.004
0.006
0.006
8
0.004
0.006
0.006
9
0.004
0.006
0.006
10
0.004
0.006
0.006
平均响应时间：6ms
场景三、在公网上通过traefik ingress访问
测试命令
10组测试结果
1
0.043
0.085
0.085
2
0.052
0.093
0.093
3
0.043
0.082
0.082
4
0.051
0.093
0.093
5
0.068
0.188
0.188
6
0.049
0.089
0.089
7
0.051
0.113
0.113
8
0.055
0.120
0.120
9
0.065
0.126
0.127
10
0.050
0.111
0.111
平均响应时间：110ms
测试结果
在这三种场景下的响应时间测试结果如下：
Kubernetes集群node节点上通过Cluster IP方式访问：2ms
Kubernetes集群内部通过service访问：6ms
Kubernetes集群外部通过traefik ingress暴露的地址访问：110ms
注意：执行测试的node节点/Pod与serivce所在的pod的距离（是否在同一台主机上），对前两个场景可以能会有一定影响。
网络性能测试
网络使用flannel的vxlan模式。
使用iperf进行测试。
服务端命令：
客户端命令：
场景一、主机之间
场景二、不同主机的Pod之间(使用flannel的vxlan模式)
场景三、Node与非同主机的Pod之间（使用flannel的vxlan模式）
场景四、不同主机的Pod之间（使用flannel的host-gw模式）
场景五、Node与非同主机的Pod之间（使用flannel的host-gw模式）
网络性能对比综述
使用Flannel的vxlan模式实现每个pod一个IP的方式，会比宿主机直接互联的网络性能损耗30%～40%，符合网上流传的测试结论。而flannel的host-gw模式比起宿主机互连的网络性能损耗大约是10%。
Vxlan会有一个封包解包的过程，所以会对网络性能造成较大的损耗，而host-gw模式是直接使用路由信息，网络损耗小。
Kubernete的性能测试
参考Kubernetes集群性能测试中的步骤，对kubernetes的性能进行测试。
我的集群版本是Kubernetes1.6.0，首先克隆代码，将kubernetes目录复制到$GOPATH/src/k8s.io/下然后执行：
测试结果
从kubemark输出的日志中可以看到API calls latencies和Performance。
日志里显示，创建90个pod用时40秒以内，平均创建每个pod耗时0.44秒。
不同type的资源类型API请求耗时分布
services
DELETE
8.472ms
9.841ms
38.226ms
endpoints
PUT
1.641ms
3.161ms
30.715ms
endpoints
GET
931µs
10.412ms
27.97ms
nodes
PATCH
4.245ms
11.117ms
18.63ms
pods
PUT
2.193ms
2.619ms
17.285ms
从log.txt日志中还可以看到更多详细请求的测试指标。
注意事项
测试过程中需要用到docker镜像存储在GCE中，需要翻墙下载，我没看到哪里配置这个镜像的地址。该镜像副本已上传时速云：
用到的镜像有如下两个：
gcr.io/google_containers/pause-amd64:3.0
gcr.io/google_containers/serve_hostname:v1.4
Locust测试
请求统计
POST
/login
5070
78
59000
80551
11218
202140
54
1.17
POST
/metrics
5114232
85879
63000
82280
29518
331330
94
1178.77
None
Total
5119302
85957
63000
82279
11218
331330
94
1179.94
响应时间分布
POST /login
5070
59000
125000
140000
148000
160000
166000
174000
176000
202140
POST /metrics
5114993
63000
127000
142000
149000
160000
166000
172000
176000
331330
None Total
5120063
63000
127000
142000
149000
160000
166000
172000
176000
331330
以上两个表格都是瞬时值。请求失败率在2%左右。
Sample-webapp起了48个pod。
Locust模拟10万用户，每秒增长100个。
关于Locust的使用请参考Github：https://github.com/rootsongjc/distributed-load-testing-using-kubernetes
参考
最后更新于