search

gardener / gardener

Homogeneous Kubernetes clusters at scale on any infrastructure using hosted control planes.
https://gardener.cloud
Apache License 2.0
2.92k stars 478 forks source link

Specify ClusterAutoscaler's priority in shoot CR #10683

Open dongyingbo opened 1 day ago

dongyingbo commented 1 day ago

How to categorize this issue?

/area auto-scaling /kind enhancement

What would you like to be added: Currently ClusterAutoscaler's priority configmap cluster-autoscaler-priority-expander is installed by user after cluster creation. It should be part of shoot CR.

Why is this needed: We have more than one node groups to allow system components for cluster resilience. But the cheapest one should take priority for TCO. But we can not do that because configmap cluster-autoscaler-priority-expander is created by us after cluster ready. I would like to make the configmap part of shoot yaml, so that gardener controller can create it in between control plane ready and system component deployment.

gardener-prow[bot] commented 1 day ago

@dongyingbo: The label(s) area/todo cannot be applied, because the repository doesn't have them.

In response to [this](https://github.com/gardener/gardener/issues/10683): >**How to categorize this issue?** > >/area TODO >/kind enhancement > >**What would you like to be added**: >Currently ClusterAutoscaler's priority configmap cluster-autoscaler-priority-expander is installed by user after cluster creation. >It should be part of shoot CR. > >**Why is this needed**: >We have more than one node groups to allow system components for cluster resilience. >But the cheapest one should take priority. >But we can not do that because configmap cluster-autoscaler-priority-expander is created by us after cluster ready. >I would like to make the configmap part of shoot yaml, so that gardener controller can create it in between control plane ready and system component deployment. Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
dongyingbo commented 1 day ago

/area auto-scaling

sunir1 commented 1 day ago

I support this request, and would add that it is not only for TCO, but also for performance. We use fallback options (by priority), due to capacity issues by hyper-scalers which are out of our control. And ideally we would like the 1st/preferred worker-group to be used for better performance and/or cost.

Having randomness (while capacity is available), is limiting us.