-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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
Add container based scaling to HPA #90691
Add container based scaling to HPA #90691
Conversation
Hi @arjunrn. 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. |
/label api-review |
bd6fa22
to
e6a2ed7
Compare
/assign @josephburnett |
Thanks for the PR. It looks like the linked proposal is not yet marked as implementable and is missing test plan info. Unflagging for API review. |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
/label api-review |
edc135a
to
1051fbe
Compare
@arjunrn please split out the cli changes into a separate PR, or at least commit. |
1051fbe
to
36c04e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sig-cli related changes lgtm
36c04e9
to
a14e75a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one comment on API docs, one question about the containerResource name validation, rebase, then lgtm
if len(src.Name) == 0 { | ||
allErrs = append(allErrs, field.Required(fldPath.Child("name"), "must specify a resource name")) | ||
} else { | ||
if !helper.IsStandardContainerResourceName(string(src.Name)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this intending to allow all resources a container could request/limit? if so, this doesn't allow as much as validateContainerResourceName
. is that ok?
if this intending to allow only cpu/memory? if so, this also allows ephemeral-storage and hugepage resources. is that ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now the resource field for the regular resource type does not have any validation in it. So users can specify even ephemeral-storage
and hugepage-
resources for scaling. However metrics-server
which is used by the HPA controller does not support those resources at the moment. But if they were, the HPA controller would support them out of the box because the resource name is not validated. So should I now restrict which resources can be specified(limit to cpu and memory) or should I be a bit more permissive and allow all container resources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think replica_calculator.go is pretty generic all the way through. So we should allow any valid resource.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephburnett @liggitt In that case the current validation is correct. So I will leave this as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case the current validation is correct
are you sure? this validation is narrower than validateContainerResourceName
, so it would disallow resources a container could request, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I misunderstood your first comment. You're right this is more restrictive. So now I have 3 options:
- Copy the
validateContainerResourceName
function. - Turn the
validateContainerResourceName
into a public function and add tests. - Remove the validation to keep it the same as validation for the resource name in the
ResourceMetricSource
.
I prefer option 2. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 sounds good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liggitt I've made changes. Can you take another look.
e1e437c
to
1b730d9
Compare
API doc updates lgtm. I'll defer to @josephburnett on the desired allowed values for the container resource. Once that is determined, add validation unit tests demonstrating the allowed/disallowed values. |
1b730d9
to
1b3d3a3
Compare
…sources Signed-off-by: Arjun Naik <[email protected]>
1b3d3a3
to
0fec7b0
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: arjunrn, josephburnett, liggitt, soltysh 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 |
thanks, changes look good |
/retest Review the full test history for this PR. Silence the bot with an |
/retest |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR introduces a new metric source called
ContainerResourceMetricSource
and a correspondingContainerResourceMetricStatus
types which are used to specify metric targets for individual containers in the target pods and the status of those metrics.Which issue(s) this PR fixes:
Fixes #86349
Special notes for your reviewer:
/label api-review
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: