-
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
Add QueueingHintFn for pvc events in VolumeRestriction plugin #125280
Add QueueingHintFn for pvc events in VolumeRestriction plugin #125280
Conversation
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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-sigs/prow repository. |
/cc @sanposhiho |
/retest |
|
||
pvcs := sets.New[string]() | ||
|
||
for _, volume := range pod.Spec.Volumes { |
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 should only check volumes which can be rejected by volumeRestriction
.
kubernetes/pkg/scheduler/framework/plugins/volumerestrictions/volume_restrictions.go
Lines 157 to 159 in 2d8a3ad
func needsRestrictionsCheck(v v1.Volume) bool { | |
return v.GCEPersistentDisk != nil || v.AWSElasticBlockStore != nil || v.RBD != nil || v.ISCSI != nil | |
} |
I think that means we should only check these 4 types of volumes and pvc with readWriteOncePod accessmode?
And since we only cares PVC in this function, I think we should only do insertion in L365, if this pvc is a readWriteOncePod pvc.
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.
The current code will function correctly. However, the purpose of QHInt is to allow the plugin to determine if a previously rejected pod can potentially pass through it again. If the PVC has not been created, it will not be rejected by VolumeRestriction (I'm not sure but maybe volume_binding?). Although adding this check will not make the performance faster, I believe we should maintain consistent behavior.
Sorry, I checked the code. And we DO check this in code:
kubernetes/pkg/scheduler/framework/plugins/volumerestrictions/volume_restrictions.go
Lines 249 to 252 in 548d50d
pvc, err := pl.pvcLister.PersistentVolumeClaims(pod.Namespace).Get(volume.PersistentVolumeClaim.ClaimName) | |
if err != nil { | |
return nil, err | |
} |
So never mind. Let's keep the behavior for now😅.
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.
Thank you for your careful review :)
@@ -326,10 +328,50 @@ func (pl *VolumeRestrictions) EventsToRegister() []framework.ClusterEventWithHin | |||
{Event: framework.ClusterEvent{Resource: framework.Node, ActionType: framework.Add}}, | |||
// Pods may fail to schedule because the PVC it uses has not yet been created. | |||
// This PVC is required to exist to check its access modes. | |||
{Event: framework.ClusterEvent{Resource: framework.PersistentVolumeClaim, ActionType: framework.Add | framework.Update}}, | |||
{Event: framework.ClusterEvent{Resource: framework.PersistentVolumeClaim, ActionType: framework.Add | framework.Update}, |
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 it safe to remove the PVC's update event? The current Hint function will always ignore the event. After reading the plugin implementation, no update event registered makes sense to me.
I'd like to hear about others' opinions. @sanposhiho @AxeZhan
Related to #122158
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.
The access modes can not be changed after a pvc is created.
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.
Unlike node events, the scheduler never ignore the creation event of a pvc.
kubernetes/pkg/scheduler/eventhandlers.go
Line 441 in 6938c29
// MaxPDVolumeCountPredicate: add/update PVC will affect counts of PV when it is bound. |
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 +1 for removing update event, since related changes to the PVC spec are blocked by immutability protection.
Not sure why we added it first, the comments said it's a future-proof, need opinions from reviewers of #103082
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.
/cc @jsafrane @xing-yang
Can you take a look?
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.
https://github.com/kubernetes/kubernetes/pull/103082/files#r661392954
The question is whether anything has changed since that comment was made, whether any change to the PVC spec or status could cause a Pod to schedule.
ping @jsafrane @xing-yang
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.
The only PVC field that this filter uses is Spec.AccessModes
and it's indeed immutable:
kubernetes/pkg/apis/core/validation/validation.go
Line 2402 in 1589016
allErrs = append(allErrs, field.Forbidden(field.NewPath("spec"), fmt.Sprintf("spec is immutable after creation except resources.requests and volumeAttributesClassName for bound claims\n%v", specDiff))) |
/approve
/hold cancel
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.
Please remove Update, given, that, effectively, it doesn't matter.
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.
removed, after this PR merge we close #122158 as we no longer need it.
pkg/scheduler/framework/plugins/volumerestrictions/volume_restrictions.go
Outdated
Show resolved
Hide resolved
676888d
to
d500e99
Compare
pkg/scheduler/framework/plugins/volumerestrictions/volume_restrictions_test.go
Outdated
Show resolved
Hide resolved
pkg/scheduler/framework/plugins/volumerestrictions/volume_restrictions_test.go
Outdated
Show resolved
Hide resolved
pkg/scheduler/framework/plugins/volumerestrictions/volume_restrictions_test.go
Show resolved
Hide resolved
d500e99
to
6c10218
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.
Thanks for all the fix, my /lgtm
for it will come after the decision in https://github.com/kubernetes/kubernetes/pull/125280/files#r1625269171.
6c10218
to
0fbf3e8
Compare
We can discuss this separately in #122158 :) |
pkg/scheduler/framework/plugins/volumerestrictions/volume_restrictions.go
Outdated
Show resolved
Hide resolved
0fbf3e8
to
32ee19c
Compare
/retest |
@sanposhiho Do you think we can add |
32ee19c
to
cd13be8
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.
/lgtm
/approve
LGTM label has been added. Git tree hash: 3a56488ff4c2912f8f6b7c6090d0a5ce08893e2e
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alculquicondor, HirazawaUi, jsafrane 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:
Which issue(s) this PR fixes:
Fixes Part of #118893
Special notes for your reviewer:
For review purposes, I splitd #119405.
this PR for adding QueueingHintFn for pvc events in VolumeRestriction plugin.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: