测试环境

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