Limit the rate of adding new uneeded nodes #5556
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: x13n 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:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
area/cluster-autoscaler
approved
x13n
force-pushed
the
fast-sd
branch
2 times, most recently
from
1a59ec2 to
07b3783
Compare
k8s-ci-robot
added
size/L
x13n
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
| if u < loopInterval { | ||
| u = loopInterval | ||
| } | ||
| upperBound := n * int(u/loopInterval) |
There was a problem hiding this comment.
Let's have higher limit.
If ScaleDownUnneededTime=60s, and loopInterval=10s we will have upperBound 6n. Imagine it's smaller than limit.
Each loop we will remove n nodes, so 6n nodes we will remove in exactly 1minute. However if CA have filtered some nodes in NodesToDelete (because min size would be violate or resource limits) we would have <6n nodes, let's say 3n which we will be able to remove in 30 seconds and so other empty nodes won't start removal because unneeded time haven't pass yet.
There was a problem hiding this comment.
Right. This is exactly what the extra buffer is for, so adding it here so that it is consistent between limit and upperBound.
This is an optimization to avoid spending too much time in scale down simulation. The main idea is that it doesn't make sense to add new unneeded nodes at a rate that is higher than the rate at which we can delete them afterwards.
|
/lgtm |
k8s-ci-robot
added
the
lgtm
This is an optimization to avoid spending too much time in scale down simulation. The main idea is that it doesn't make sense to add new unneeded nodes at a rate that is higher than the rate at which we can delete them afterwards.
What type of PR is this?
What this PR does / why we need it:
Faster scale down in large clusters.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: