[cluster-autoscaler] Additional expander options

[ryanmcnamara]

Users are able to specify the expander option to change which nodegroup (e.g. ASG) is selected when there are multiple that satisfy the scheduling requirements for a pod. The feature request is to allow selecting an additional expanders in the event that the chosen expander still arbitrarily ties multiple nodegroups. This is very similar to this closed ticket #2564.

For our specific use case, we are currently using the least-waste expander, but we want to have some nodegroups which are preferred. What we would then like is to use the priority expander but fall back to least-waste when multiple still match.

I see several ways this feature could be added, in my order of preference

1. Use a list of expanders to use, with some validation of course very similar to what @adrienjt mentions here. Satisfying my above use case would look like setting expander=priority,least-waste.
2. Add a priority-expander option, specifically only used in the case where expander=priority. Satisfying the above use case would look like setting expander=priority and priority-expander=least-waste

I think the first option is cleaner / easier to understand but is perhaps more complicated to implement. I'd be happy to submit a PR for this but wanted to get any feedback first, thanks!

cc @Jeffwan @bpineau @adrienjt

[x13n]

mostpods and waste expanders, similarly to priority, have a notion of fallback strategy. Option 1 is much cleaner from API point of view, and also fairly easy to implement - we'd just need to update expander factory to allow chaining (and return an error if there's an expander configured after a one that doesn't have a fallback).

[ryanmcnamara]

Thanks @x13n
I'll probably take a shot at this over the next several days and push something up for PR review. Would you like to review or know who I should get for a review?

[x13n]

I'm happy to review the change, but you'll still need a repo owner to approve.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[x13n]

This was done in #4233

/close

[k8s-ci-robot]

@x13n: Closing this issue.

In response to this:

This was done in #4233

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[stevehipwell]

@x13n which versions of CA have this code?

I think there is a bigger question here on backporting vs recommending newer CA builds for supported K8s versions, does this need a separate issue opening?

[x13n]

None yet, it will be a part of 1.23 release. I think backporting should mostly be limited to bug fixes, not new features like this one, but if you disagree then yes, a separate issue sounds like a good starting point.