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