Kubernetes 1.16 与 1.14性能对比

测试环境

  • 阿里云 ACK 1.16.6 3master 3worker(4c 8g) 独占版, kubemark 模拟 100 个 node;
  • 阿里云 ACK 1.14.8 3master 3worker(4c 8g) 独占版, kubemark 模拟 100 个 node。

测试指标

PodstartuplatencySaturate(饱和测试)

在 1 个 namespace 下创建 replicas 为 3000 的 deployment,记录每个 pod 所需时间,按照时间大小排序后得到(50 90 99 百分点结果)。

Podstartuplatencylatency(存量测试)

在已创建 3000 个 pod 的场景下,连续创建 500 个 replicas 为 1 的 deployment,测试 pod 的创建时间。

吞吐量

在创建 pod 的过程中,测试每秒创建的 pod 个数。

api 响应时间

在整个测试过程(创建 pod,删除 pod)中,api-server 收到请求到响应的时间汇总,按 verb、resouce、scope、percentage 区分。

实验结果

PodstartuplatencySaturate(ms)

1.16

PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup
50 0 1000 1044.237 1749.131 1749.184
90 0 1000 1640.885 2401.273 2401.273
99 0 1000 2126.116 2958.44 2958.44

1.14

PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup
50 0 1000 1083.588 1836.33 1838.244
90 0 1000 1790.928 2610.571 2611.449
99 0 2000 2852.53 4303.789 4303.789
对比:

空载下运行3000个pod,50%pod启动时间1.16相比1.14快5%左右。 90%的pod启动时间,1.16启动时间提升3%-10%,99%的pod启动时间上1.16提升最大,速度提升25%-50%。在最坏情况下,1.16的效果明显好于1.14.

Podstartuplatency(ms)

1.16

PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup
50 0 1000 1004.569 1727.642 1727.662
90 0 1000 1692.732 2414.719 2429.138
99 0 1000 2124.746 2892.659 2897.378

1.14

PodStartupLatency create_to_schedule schedule_to_run run_to_watch schedule_to_watch pod_startup
50 0 1000 1046.108 1772.073 1774.335
90 0 1000 1772.192 2613.083 2613.083
99 0 1000 2260.846 2959.74 2959.74

对比

在存量测试下,50% pod 启动时间上, 1.16 效率提升 3%;90% 和 99% pod 的启动时间上,1.16 效率提升 5%。总体来说 1.16 效果略微好于 1.14。

吞吐量(个数)

版本 average 50 90 99
1.14 19.354 20 20 23.6
1.16 19.354 20 20 24.2

对比

  • 在创建 pod 过程中,50%、90% 和平均情况下,1.14 和 1.16 创建 pod 吞吐量相同;
  • 99 分位点情况,1.16 提升 3%。在最坏情况下,1.16 的效果优于 1.14。

api 响应延时(ms)

1.14

Resource Scope Verb Perc50 Perc90 Perc99
pods namespace DELETE 25.279 45.502 54.906
pods namespace GET 25.17 45.307 49.837
pods namespace LIST 25 45 49.5

(Pod)

Resource Scope Verb Perc50 Perc90 Perc99
nodes cluster PATCH 25.41 45.74 78.87
nodes cluster LIST 25 45 49.5
nodes cluster GET 25 45 49.5

(Nodes)

1.16

Resource Scope Verb Perc50 Perc90 Perc99
pods namespace DELETE 25.432 45.779 76.445
pods namespaces GET 25.018 45.033 49.536
pods namespaces LIST 25 45 49.5

(Pod)

Resource Scope Verb Perc50 Perc90 Perc99
nodes cluster PATCH 25 45 49.5
nodes cluster LIST 25 45 49.5
nodes cluster GET 25 45 49.5

(Nodes)

对比

统计整个创建 Pod 和删除 Pod 过程中 api 响应时间,将其根据时间大小排序后对 pod 和 node 操作选取时间最长的三项进行对比。

对比可以发现,对 pod 和 node 操作的 api 时间,1.14 和 1.16 基本一致:

  • 最坏情况下(99 分点)对 pod 的 delete 操作时间,1.14 相比 1.16 要快 30% 左右;
  • 对 node 的 PATCH 操作,1.16 相比 1.14 要快 40% 左右;
  • 对于其它 apicall(如 LIST 和 GET)二者并没有明显差距。

总结

总体来说,1.16 版本相对于 1.14 版本的主要提高在无状态 Pod(Pod 不用挂载 configmap、secret 等 volume)的创建速度上:

  • 1.16 和 1.14 的 pod 创建时间都满足 Kubernetes sig-scalability 定义的 SLA((99% 的已拉取好镜像的 pod 启动时间在 5s 内);
  • 但在最差情况下(99 分位点),1.14 版本的 Pod 创建速度接近 5s,表现差于同指标下 K8s 1.16 的 3s。

说明 1.16 版本更适用于对 pod 创建速度有要求(如弹性业务)的场景。

上一篇:【COCOS2DX-LUA 脚本开发之五】Lua 使用OOP免Binding创建自定义lua类


下一篇:黑客控制 Dridex 服务器 用杀毒软件替代恶意程序