-
Notifications
You must be signed in to change notification settings - Fork 262
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
[workload] Get default resource values from LimitRanges #600
[workload] Get default resource values from LimitRanges #600
Conversation
✅ Deploy Preview for kubernetes-sigs-kueue ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Welcome @trasc! |
Hi @trasc. Thanks for your PR. I'm waiting for a kubernetes-sigs 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. |
/ok-to-test |
392c99d
to
b37ee3c
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.
Just take an overview of this PR, I think we have something to come to an agreement at first:
- About the defaulting orders:
- Respect container resources first
- Respect LimitRange, we should not defaulting the requests to limits as we want before applying the policy, it's a hard constraint required by the administrators.
- Defaulting the requests to limits if not set
- About the validation
- We should also reject the creation if violating the LimitRange, in validation I think.
- If no request set in final, reject the creation also.
cc @alculquicondor for advices also.
ret := make([]corev1.LimitRangeItem, 0, len(list.Items)) | ||
|
||
for _, lr := range list.Items { | ||
for _, lri := range lr.Spec.Limits { |
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 we should only consider defaults
here, if no defaults, then we'll set defaults to limits.
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'm afraid I don't understand.
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.
We need to consider all the fields. min
and max
would also affect the containers requests.
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.
Yes, what @alculquicondor said is what I mean. Sorry for the confusion.
In my option, the approach should be consider the default
and defaultRequest
in webhook defaulting, consider the min
and max
in webhook validating.
When comparing jobAndWorkloadEqual
:
- if job is suspend, we'll query the limitRange again
- if job is unsuspend, we can ignore the resources in comparation because pod will not be affected by LimitRange after creation.
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.
Indeed we could also validate the boundaries, however I propose to do this in another Issue/PR otherwise it will get to hard to track. Also we should decide what should happen if the validation fails, as of now, the job controller will just endlessly to to create the workload and fail.
In my opinion, tracking the defaults used in order to recreate the workload add too much coupling between the job-controllers and the workloads, with very little added value (in practice I don't expect the LimitRanges
to change very often).
For the defaulting order, in my opinion, the value set in the limits of the job has better chances to be closer to the actual need of the job that a value set for the entire namespace. The same happens for pods. Regarding the validation, sure, it could be added. |
b37ee3c
to
7a97422
Compare
ret := make([]corev1.LimitRangeItem, 0, len(list.Items)) | ||
|
||
for _, lr := range list.Items { | ||
for _, lri := range lr.Spec.Limits { |
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.
We need to consider all the fields. min
and max
would also affect the containers requests.
Defaulting Limits to Requests is not transparent to users, if we have LimitRange with defaultRequest set, workload can be constructed successfully, why we get involved with the |
7a97422
to
a8d7f70
Compare
a8d7f70
to
595a5a1
Compare
19cb368
to
4758735
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.
With this PR, if a LimitRange changes, then the usage of admitted Workloads would change.
I think this is fine as an intermediate step given that we do have the same problem with RuntimeClass.
67709c3
to
afa1a94
Compare
Use the LimitRange within the same namespace to adjust the podSet's resource requirements before adding the to cache and queues.
afa1a94
to
453f4f2
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.
Comments that can be done in follow ups
/lgtm
/approve
/label tide/merge-method-squash
@@ -58,6 +60,20 @@ func IndexWorkloadClusterQueue(obj client.Object) []string { | |||
return []string{string(wl.Status.Admission.ClusterQueue)} | |||
} | |||
|
|||
func IndexLimitRangeHasContainerType(obj client.Object) []string { |
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.
We might need to also check type Pod when we do validation (for min/max).
So an alternative implementation would be IndexLimitRangeByType
. Then you can return all the types that the LimitRange has.
But we can leave this for later.
|
||
"github.com/google/go-cmp/cmp" | ||
corev1 "k8s.io/api/core/v1" | ||
apiresource "k8s.io/apimachinery/pkg/api/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.
we avoid aliases when there are no conflicts.
Max: corev1.ResourceList{}, | ||
Min: corev1.ResourceList{}, | ||
Default: corev1.ResourceList{}, | ||
DefaultRequest: corev1.ResourceList{}, | ||
MaxLimitRequestRatio: corev1.ResourceList{}, |
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.
you could remove these lines.
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.
yes, but then you need to check / alocate the empty map for every value set
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.
ahhh, sorry, I forgot these were maps :)
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alculquicondor, trasc 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 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Add the possibility to use default workload resource values based on LimitRanges if present in the target namespace.
The order by which Requested resource values are set becomes:
In addition, this provides a more generic alternative approach to fix #590, by moving the limits to request default in the workload controller without an impact to the workload's spec .
Which issue(s) this PR fixes:
Fixes #541, #590
Special notes for your reviewer: