Kubernetes网络和集群性能测试

    在以下几种环境下进行测试：

    • 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的分布式负载测试

    测试说明

    通过向发送curl请求获取响应时间，直接curl后的结果为：

    网络延迟测试

    测试命令

    1. curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer} %{time_total}' "http://10.254.149.31:8000/"

    10组测试结果

    平均响应时间：2ms

    时间指标说明

    单位：秒

    time_connect：建立到服务器的 TCP 连接所用的时间

    time_starttransfer：在发出请求之后，Web 服务器返回数据的第一个字节所用的时间

    场景二、Kubernetes集群内部通过service访问

    测试命令

    1. curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer} %{time_total}' "http://sample-webapp:8000/"

    10组测试结果

    No time_connect time_starttransfer time_total
    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访问

    测试命令

    1. curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer} %{time_total}' "http://traefik.sample-webapp.io" >>result

    10组测试结果

    平均响应时间：110ms

    测试结果

    在这三种场景下的响应时间测试结果如下：

    • Kubernetes集群node节点上通过Cluster IP方式访问：2ms
    • Kubernetes集群内部通过service访问：6ms
    • Kubernetes集群外部通过traefik ingress暴露的地址访问：110ms

    注意：执行测试的node节点/Pod与serivce所在的pod的距离（是否在同一台主机上），对前两个场景可以能会有一定影响。

    网络使用flannel的vxlan模式。

    使用iperf进行测试。

    服务端命令：

    客户端命令：

    1. iperf -c ${server-ip} -p 12345 -i 1 -t 10 -w 20K
    1. [ ID] Interval       Transfer     Bandwidth
    2. [  3]  0.0- 1.0 sec   598 MBytes  5.02 Gbits/sec
    3. [  3]  1.0- 2.0 sec   637 MBytes  5.35 Gbits/sec
    4. [  3]  2.0- 3.0 sec   664 MBytes  5.57 Gbits/sec
    5. [  3]  3.0- 4.0 sec   657 MBytes  5.51 Gbits/sec
    6. [  3]  4.0- 5.0 sec   641 MBytes  5.38 Gbits/sec
    7. [  3]  6.0- 7.0 sec   628 MBytes  5.26 Gbits/sec
    8. [  3]  7.0- 8.0 sec   649 MBytes  5.44 Gbits/sec
    9. [  3]  8.0- 9.0 sec   638 MBytes  5.35 Gbits/sec
    10. [  3]  9.0-10.0 sec   652 MBytes  5.47 Gbits/sec
    11. [  3]  0.0-10.0 sec  6.25 GBytes  5.37 Gbits/sec

    场景二、不同主机的Pod之间(使用flannel的vxlan模式)

    1. [ ID] Interval       Transfer     Bandwidth
    2. [  3]  0.0- 1.0 sec   372 MBytes  3.12 Gbits/sec
    3. [  3]  1.0- 2.0 sec   345 MBytes  2.89 Gbits/sec
    4. [  3]  2.0- 3.0 sec   361 MBytes  3.03 Gbits/sec
    5. [  3]  3.0- 4.0 sec   397 MBytes  3.33 Gbits/sec
    6. [  3]  4.0- 5.0 sec   405 MBytes  3.40 Gbits/sec
    7. [  3]  5.0- 6.0 sec   410 MBytes  3.44 Gbits/sec
    8. [  3]  6.0- 7.0 sec   404 MBytes  3.39 Gbits/sec
    9. [  3]  7.0- 8.0 sec   408 MBytes  3.42 Gbits/sec
    10. [  3]  8.0- 9.0 sec   451 MBytes  3.78 Gbits/sec
    12. [  3]  0.0-10.0 sec  3.85 GBytes  3.30 Gbits/sec

    场景三、Node与非同主机的Pod之间（使用flannel的vxlan模式）

    场景四、不同主机的Pod之间（使用flannel的host-gw模式）

    1. [ ID] Interval       Transfer     Bandwidth
    2. [  5]  0.0- 1.0 sec   530 MBytes  4.45 Gbits/sec
    3. [  5]  1.0- 2.0 sec   576 MBytes  4.84 Gbits/sec
    4. [  5]  2.0- 3.0 sec   631 MBytes  5.29 Gbits/sec
    5. [  5]  3.0- 4.0 sec   580 MBytes  4.87 Gbits/sec
    6. [  5]  4.0- 5.0 sec   627 MBytes  5.26 Gbits/sec
    7. [  5]  5.0- 6.0 sec   578 MBytes  4.85 Gbits/sec
    8. [  5]  6.0- 7.0 sec   584 MBytes  4.90 Gbits/sec
    9. [  5]  7.0- 8.0 sec   571 MBytes  4.79 Gbits/sec
    10. [  5]  8.0- 9.0 sec   564 MBytes  4.73 Gbits/sec
    11. [  5]  9.0-10.0 sec   572 MBytes  4.80 Gbits/sec
    12. [  5]  0.0-10.0 sec  5.68 GBytes  4.88 Gbits/sec
    1. [ ID] Interval       Transfer     Bandwidth
    2. [  3]  0.0- 1.0 sec   570 MBytes  4.78 Gbits/sec
    3. [  3]  1.0- 2.0 sec   552 MBytes  4.63 Gbits/sec
    4. [  3]  2.0- 3.0 sec   598 MBytes  5.02 Gbits/sec
    5. [  3]  3.0- 4.0 sec   580 MBytes  4.87 Gbits/sec
    6. [  3]  4.0- 5.0 sec   590 MBytes  4.95 Gbits/sec
    7. [  3]  5.0- 6.0 sec   594 MBytes  4.98 Gbits/sec
    8. [  3]  6.0- 7.0 sec   598 MBytes  5.02 Gbits/sec
    9. [  3]  7.0- 8.0 sec   606 MBytes  5.08 Gbits/sec
    10. [  3]  9.0-10.0 sec   604 MBytes  5.07 Gbits/sec
    11. [  3]  0.0-10.0 sec  5.75 GBytes  4.94 Gbits/sec

    网络性能对比综述

    使用Flannel的vxlan模式实现每个pod一个IP的方式，会比宿主机直接互联的网络性能损耗30%～40%，符合网上流传的测试结论。而flannel的host-gw模式比起宿主机互连的网络性能损耗大约是10%。

    Vxlan会有一个封包解包的过程，所以会对网络性能造成较大的损耗，而host-gw模式是直接使用路由信息，网络损耗小，关于host-gw的架构请访问。

    Kubernete的性能测试

    参考中的步骤，对kubernetes的性能进行测试。

    2. /usr/local/src/k8s.io/kubernetes /usr/local/src/k8s.io/kubernetes
    3. Generated bindata file : test/e2e/generated/bindata.go has 13498 test/e2e/generated/bindata.go lines of lovely automated artifacts
    4. No changes in generated bindata file: pkg/generated/bindata.go
    5. /usr/local/src/k8s.io/kubernetes
    6. $ make WHAT="test/e2e/e2e.test"
    7. ...
    8. +++ [0425 17:01:34] Generating bindata:
    9.     test/e2e/generated/gobindata_util.go
    10. /usr/local/src/k8s.io/kubernetes /usr/local/src/k8s.io/kubernetes/test/e2e/generated
    11. /usr/local/src/k8s.io/kubernetes/test/e2e/generated
    12. +++ [0425 17:01:34] Building go targets for linux/amd64:
    13.     test/e2e/e2e.test
    14. $ make ginkgo
    15. +++ [0425 17:05:57] Building the toolchain targets:
    16.     k8s.io/kubernetes/hack/cmd/teststale
    17.     k8s.io/kubernetes/vendor/github.com/jteeuwen/go-bindata/go-bindata
    18. +++ [0425 17:05:57] Generating bindata:
    19.     test/e2e/generated/gobindata_util.go
    20. /usr/local/src/k8s.io/kubernetes /usr/local/src/k8s.io/kubernetes/test/e2e/generated
    21. /usr/local/src/k8s.io/kubernetes/test/e2e/generated
    22. +++ [0425 17:05:58] Building go targets for linux/amd64:
    23.     vendor/github.com/onsi/ginkgo/ginkgo
    25. $ export KUBERNETES_PROVIDER=local
    26. $ export KUBECTL_PATH=/usr/bin/kubectl
    27. $ go run hack/e2e.go -v -test  --test_args="--host=http://172.20.0.113:8080 --ginkgo.focus=\[Feature:Performance\]" >>log.txt

    测试结果

    从kubemark输出的日志中可以看到API calls latencies和Performance。

    日志里显示，创建90个pod用时40秒以内，平均创建每个pod耗时0.44秒。

    不同type的资源类型API请求耗时分布

    Resource Verb 50% 90% 99%
    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

    从日志中还可以看到更多详细请求的测试指标。

    注意事项

    测试过程中需要用到docker镜像存储在GCE中，需要翻墙下载，我没看到哪里配置这个镜像的地址。该镜像副本已上传时速云：

    用到的镜像有如下两个：

    • gcr.io/google_containers/pause-amd64:3.0
    • gcr.io/google_containers/serve_hostname:v1.4

    时速云镜像地址：

    • index.tenxcloud.com/jimmy/pause-amd64:3.0
    • index.tenxcloud.com/jimmy/serve_hostname:v1.4

    将镜像pull到本地后重新打tag。

    请求统计

    响应时间分布

    Name # requests 50% 66% 75% 80% 90% 95% 98% 99% 100%
    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测试页面

    参考