Why does it matter?
Currently, DaemonSets and Deployments (via ReplicaSets) offer some level of strategy control for rolling updates, but provide almost nothing for large-range scaling, apart from limiting the request pressure for the API server. As a result, a large number of creating pods will compete simultaneously for the same resources, leading to repeated failures and retries, and very slowly scaling. Therefore, Should user-defined concurrency control be considered for scaling pods in DaemonSets/Deployments?
In terms of pod scaling for DaemonSets/Deployments, the current solutions are based on various Autoscalers, but using Autoscalers to achieve specific-number scaling goals might also be inconsistent and awkward:
- For Deployments, scaling relies on the Horizontal Pod Autoscaler (HPA).
- For DaemonSets, scaling, that is node scaling, typically using the Cluster Autoscaler with Node Pools/Groups and HorizontalNodeScalingPolicy.
However, Node Pools/Groups depend on cloud provider supporting, unusable in local self-built Kubernetes clusters where manual node scaling via adding/removing labels/taints is common.
Additionally, the rolling update strategy for DaemonSets/Deployments is not flexible. It only supports a single fixed updating rate, whereas production environments often require a phased updating strategy of starting slowly and accelerating later
What Effects do you want?
The DaemonSet/Deployment controllers introduce control strategies for scaling pods similar to RollingUpdate. This would include support for fine-grained control via a sequence of (percentage: speed) pairs. Furthermore, consider abstracting a standalone “Progressive Controller” to manage such strategies, which could then be referred by other similar multi-replica resource objects.