为什么需要
当前，Daemonset/Deployment（ReplicaSet）对滚动更新做了一定程度的策略控制，但是对于大批量扩容却基本没做什么，除了限制对API-Server的请求压力。这使得当它们大批量扩容也就是大量Pod同时创建时，会引发对同类资源的并发争抢，进而不断的失败重试，导致扩容过程什么缓慢。所以，是否应该考虑对Daemonset/Deployment扩缩容Pod也进行用户可定义的并发控制？
在Daemonset/Deployment Pod扩缩容方面，当前仅有基于各种AutoScaler自动扩缩容的方案。而且采用自动扩缩容实现特定目标数量的扩容和缩容也是有不同的、别扭的。针对Deployment，自动扩缩容方案基于Horizontal Pod Autoscaler（HPA）；而针对Daemonset，也就是Node的扩缩容，有Cluster Autoscaler结合Node Pool/Group以及HorizontalNodeScalingPolicy的方案。不过，针对后者的Node Pool/Group需要云服务商支持，对于本地自建集群采用增删lables/taints手动扩缩容Node的场景，基本并不可用。
另一方面，Daemonset/Deployment的滚动方案并不灵活，只能支持单一速率的滚动更新，而生产中更需要的可能是前面更新慢、后面更新快的分阶段可控制的更新策略。
期待效果
Daemonset/Deployment控制器对扩缩容Pod增加类似RollingUpdate的控制策略，同时支持(百分比:速度)的顺序控制列表的细粒度控制。更进一步，可以考虑直接抽离出来一个灰度控制器，供其他类似的多副本对象进行引用。