Make the number of ramp steps configurable #374
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jonathanbeber
force-pushed
the
configurable-buckets
branch
from
7e5ee89
to
db18d74
Compare
In #371 we introduced steps to make the scaling up possible even when the HPA forces a 10% change. The problem is that 10% might not be sufficient for some specific scaling scenarios. For example, a an application targeting 12 pods and using a ScalingSchedule with the value of 10000 to achieve that, will require a target of 833. With 10 ramp steps the 90% bucket will return a metric of 9000 and the HPA calculates (9000/833) 10.8 pods, rounding to 11 pods. Once the metric reaches the time to return 100% it will won't be effective, since the change of the current number of pods (11) and the desired one (12) is less than 10%. This commit does not try to tackle this problem completely, since the 10% rule is not fixed, might change among different clusters and is also dependent on the value given to each ScalingSchedule. Therefore, this commit makes the number of ramp steps configurable via the `--scaling-schedule-ramp-steps` config flag, defaulting to 10. Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
jonathanbeber
force-pushed
the
configurable-buckets
branch
from
db18d74
to
fd4ead8
Compare
|
👍 |
1 similar comment
|
👍 |
jonathanbeber
added a commit
to zalando-incubator/kubernetes-on-aws
that referenced
this pull request
Oct 25, 2021
This commit updates the kube-metrics-adapter to include the changes introduced in [kube-metrics-adapter#374][kube-metrics-adapter_374]. It sets the default values to 5 steps, allowing 20% chunks of scaling. In simulations, any deployment bigger than 5 pods should face the issue of the change being smaller than 10%. [kube-metrics-adapter_374]: zalando-incubator/kube-metrics-adapter#374
|
👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #371 we introduced steps to make the scaling up possible even when
the HPA forces a 10% change. The problem is that 10% might not be
sufficient for some specific scaling scenarios.
For example, a an application targeting 12 pods and using a
ScalingSchedule with the value of 10000 to achieve that, will require a
target of 833. With 10 ramp steps the 90% bucket will return a metric of
9000 and the HPA calculates (9000/833) 10.8 pods, rounding to 11 pods.
Once the metric reaches the time to return 100% it will won't be
effective, since the change of the current number of pods (11) and the
desired one (12) is less than 10%.
This commit does not try to tackle this problem completely, since the
10% rule is not fixed, might change among different clusters and is also
dependent on the value given to each ScalingSchedule. Therefore, this
commit makes the number of ramp steps configurable via the
--scaling-schedule-ramp-stepsconfig flag, defaulting to 10.