add least-nodes expander to cluster-autoscaler

[com6056]

What type of PR is this?

What this PR does / why we need it:

Adds a new least-nodes expander 🎉

Which issue(s) this PR fixes:

No related issues

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Added a new `least-nodes` expander

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

Hi @com6056. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[com6056]

/kind feature

[com6056]

tiny little perf improvement

[drmorr0]

You can write/run your own expanders using the grpc expander option: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/expander/grpcplugin

My personal opinion is that it's better for users to add new expanders using this approach, rather than adding more special-case expanders into the core autoscaler code.

[MaciekPytel]

I generally agree with @drmorr0, but this expander seems both simple and very generic (*). As such I can imagine it being useful enough for many other users, so personally I'm ok letting it in.

(*) Preference for large nodes is a reasonable high-level strategy, as larger nodes suffer less from "system tax" and resource fragmentation. In small clusters the downside may be lack of HA, but for a cluster with hundreds of nodes I think it is a decent strategy. And there is nothing specific to a provider or environment in the implementation, it will work anywhere as the only input it relies on is absolutely necessary for CA to be able to scale-up at all.

edit: Specifically - I'm ok to lgtm this once the review comments are addressed.

[MaciekPytel]

/ok-to-test

[MaciekPytel]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: com6056, MaciekPytel

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• cluster-autoscaler/OWNERS [MaciekPytel]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[com6056]

/cherrypick cluster-autoscaler-release-1.27

[k8s-infra-cherrypick-robot]

@com6056: only kubernetes org members may request cherry picks. If you are already part of the org, make sure to change your membership to public. Otherwise you can still do the cherry-pick manually.

In response to this:

/cherrypick cluster-autoscaler-release-1.27

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-sigs/prow repository.

[com6056]

@MaciekPytel would you be able to run the cherry-pick command for me? Thanks! 🙏

[rljohnsn]

Would very much like to utilize this expander. Currently our similar node groups spread across AZ's are unevenly scaled. Always bumping the pool that has fewer nodes seams like the easiest logic to keep them all relatively equal.

[jacobrandall]

@MaciekPytel would you be able to run the cherry-pick command for me? Thanks! 🙏

Also looking to use this, any chance it could get into a release soon?