测试环境

• 阿里云 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

1.14

对比:

空载下运行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

1.14

对比

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

吞吐量(个数)

对比

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

api 响应延时(ms)

1.14

（Pod）

（Nodes）

1.16

（Pod）

（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 创建速度有要求（如弹性业务）的场景。