Add fastpath binpacking algorithm

[yonizxz]

What type of PR is this?

/kind feature

What this PR does / why we need it:

An optimization of the binpacking algorithm.
The standard binpacking algorithm operates by simulating the scheduling of all pods.
If pods cannot be scheduled on existing nodes in the simulation, new nodes are added to the simulation.
The Fastpath logic estimates the required number of nodes using simple arithmetic, avoiding the full simulation. It works by:

• Simulating the scheduling of pods on a single added node.
• Calculating the estimated nodes by dividing the number of remaining unscheduled pods by the number of pods it was able to fit on that single node
  EstimatedNodes = ceil(TotalPods / PodsFittingOnASingleNode)

Current BenchmarkBinpackingEstimate results:

=== RUN   BenchmarkBinpackingEstimate
BenchmarkBinpackingEstimate
BenchmarkBinpackingEstimate-24                 1        3756356278 ns/op        2898666960 B/op  4245672 allocs/op
PASS
ok      k8s.io/autoscaler/cluster-autoscaler/estimator  3.869s

BenchmarkBinpackingEstimate with fastpath enabled:

=== RUN   BenchmarkBinpackingEstimate
BenchmarkBinpackingEstimate
BenchmarkBinpackingEstimate-24                25          41417483 ns/op        25758270 B/op     191593 allocs/op
PASS
ok      k8s.io/autoscaler/cluster-autoscaler/estimator  1.202s

Which issue(s) this PR fixes:

Special notes for your reviewer:

Additional explanation:

Since the algorithm only adds 1 node to the snapshot, subsequent iterations will not take the rest of the upcoming nodes into account during tryToScheduleOnExistingNodes, therefore it is used only in the final iteration.
In order to maximize gains from the optimization, a heuristic determines the pod equivalence group that will benefit the most from the fastpath algorithm and preemptively places it at the end of the list.

Does this PR introduce a user-facing change?

Add fastpath binpacking optimization to scale-ups

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: yonizxz / name: Jonathan Yaniv (07f2cb9, 21d2104, 3b71b04, 550141b, b2bff9d, f0e6ef6)

[k8s-ci-robot]

Welcome @yonizxz!

It looks like this is your first PR to kubernetes/autoscaler 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/autoscaler has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @yonizxz. 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.

Details

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.

[x13n]

I don't believe this is true. Why would zonal/regional anti affinity affect # of pods that can schedule on subsequent nodes?

[yonizxz]

According to - https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#an-example-of-a-pod-that-uses-pod-affinity

With zonal/regional pod anti affinity, a pod can schedule on a node only if it is in a zone/region that doesn't contain another pod with the same value.

So fastpath will create a new node and will be able to schedule the first pod, and then won't be able to schedule the second one (there's already a pod in the same zone/region, since it's on the same node), and will then assume it can schedule the remaining x pods by creating x more nodes. which is not true, because the node group is bound to a location.

[x13n]

Ah, you're right, we'd have to try a second node to check for this. Or just consider anti-affinity matching the pods being considered - this is a bit similar to the discussion in the other thread.

[yonizxz]

Yeah I suppose if the anti affinity for a different workload, we could theoretically fastpath if there isn't a matching pod in the same location as the node group. But it would be more complicated to adjust for that and I'm not too sure about the gains (how common is it and if these type of workloads are usually big enough to benefit from fastpath). It's simpler to just not support zonal/regional anti affinity altogether, at least for now. If it becomes an important use case we can revisit this later.

[x13n]

/ok-to-test
/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: x13n, yonizxz

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• cluster-autoscaler/OWNERS [x13n]

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