测试环境
- 阿里云 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 创建速度有要求(如弹性业务)的场景。