-
Notifications
You must be signed in to change notification settings - Fork 40k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable HorizontalPodAutoscaler #74525
Configurable HorizontalPodAutoscaler #74525
Conversation
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
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. I understand the commands that are listed here. |
Hi @gliush. 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 Once the patch is verified, the new status will be reflected by the 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/test-infra repository. |
/sig autoscaling |
Is there a KEP for this? Generally we want to see the design work independent of the code. I am happy to take up the API review, but can't really do that until I know the domain experts (e.g. @mwielgus) are happy with the design. |
I see there's a doc but that's not a KEP |
Why not allow the user to specify the denominator? "1 pod per 2 minutes"
is more expressive than "0.5 pods per minute".
…On Fri, Mar 1, 2019 at 2:09 PM Marcin Wielgus ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In staging/src/k8s.io/api/autoscaling/v2beta2/types.go
<#74525 (comment)>
:
> @@ -117,6 +120,26 @@ type MetricSpec struct {
// MetricSourceType indicates the type of metric.
type MetricSourceType string
+// HorizontalPodAutoscalerScaleConstraints configures the scaling velocity
+// by specifying the "absolute" value (in number of pods) and "relative" values (in percents)
+// All the parameters of the struct are "per minute".
+// For each scale direction (Up or Down) if both parameters are specified
+// the largest constraint is used.
+type HorizontalPodAutoscalerScaleConstraints struct {
+ // scaleUpPercent specifies the scale up relative speed, in percentages
+ // i.e. if scaleUpPercent = 150 , then we can add 150% more pods (10 -> 25 pods)
+ ScaleUpPercent *resource.Quantity `json:"scaleUpPercent,omitempty" protobuf:"bytes,1,opt,name=scaleUpPercent"`
The idea behind quantity is that all values are per minute. So if you want
to add/remove at most 1 pod every 2 minutes you need to put 0.5 here.
Quantity is used for consistency with pods. We can however use ints in
percent-like values if you prefer.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#74525 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVP4C-s8uVJwcXpXK-UG_wxalviTAks5vSaUCgaJpZM4bP7bw>
.
|
3ababc8
to
8b159e8
Compare
@arjunrn thanks for fixing the controller-manager crash! I've done some manual testing in a cluster and it works nicely. Added and removed behaviors which are respected. Just two requests:
|
8b159e8
to
bad0417
Compare
Signed-off-by: Arjun Naik <arjun@arjunnaik.in>
bad0417
to
8ab2262
Compare
/lgtm I checked and there is no difference between the latest squash and the unsquashed changes I tested. Nice work! |
/hold cancel |
/test pull-kubernetes-kubemark-e2e-gce-big |
Hey @gliush 👋, Im currently looking at the latest generated releases notes and saw that this note needs to either state the user facing change or set it to |
@saschagrunert : I've updated the release notes, could you check, please? I'm a little bit concerned about the style and the amount of details. |
Thank you @gliush 🙏 I assume the API is new and we should state that to the user as well, like:
So in general it is looking good, but we have include information like mentioned here: https://github.com/saschagrunert/community/blob/master/contributors/guide/release-notes.md#contents-of-a-release-note |
@saschagrunert : thank you! Done! |
Wonderful, thank you again! :) |
Configurable HorizontalPodAutoscaler Kubernetes-commit: 928817a
I introduce an algorithm-agnostic HPA object configuration that will configure each particular HPA scaling behavior.
KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md
This PR contains only API changes for now. The business logic will be introduced in a separate PR. For now I keep all the changes in my local repo until the current PR is approved:
gliush#2
What type of PR is this?
/kind feature
What this PR does / why we need it:
Different applications may have different business values, different logic and may require different scaling behaviors.
At the moment, there’s only one cluster-level configuration parameter that influence how fast the cluster is scaled down:
--horizontal-pod-autoscaler-downscale-stabilization-window (default to 5 min)
And a couple of hard-coded constants that specify how fast the cluster can scale up:
This PR introduces an algorithm-agnostic HPA object configuration that will configure each particular HPA scaling behavior.
For both directions (scale up and scale down) it will be possible to specify one or several
behavior
that will control how the HPA controller will scale the resources. Effectively eachbehavior
is a specification of "how many percents/pods could be added/removed per some period of time".Additionally, each direction might have a
StabilizationWindowSeconds
parameter set to gather recommendations for some time and pick the safest change.For more information and motivation read the KEPs (links are above).
Which issue(s) this PR fixes:
Fixes #39090
Fixes #65097
Fixes #69428
It covers partly #56335
Special notes for your reviewer:
The API changes are backward compatible. All current defaults are kept the same.
Does this PR introduce a user-facing change?: