-
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
Retry scheduling pods after errors more consistently in scheduler #50106
Retry scheduling pods after errors more consistently in scheduler #50106
Conversation
Hi @julia-stripe. 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 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. I understand the commands that are listed here. |
@@ -222,7 +227,7 @@ func (sched *Scheduler) bind(assumed *v1.Pod, b *v1.Binding) error { | |||
if err != nil { | |||
glog.V(1).Infof("Failed to bind pod: %v/%v", assumed.Namespace, assumed.Name) | |||
if err := sched.config.SchedulerCache.ForgetPod(assumed); err != nil { | |||
return fmt.Errorf("scheduler cache ForgetPod failed: %v", err) | |||
glog.Errorf("scheduler cache ForgetPod failed: %v", err) |
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 need to FinisBinding
before ForgetPod
; if ForgetPod
failed, the assumed pod maybe still in cache.
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.
Agree. There were two problems here. One that we were returning here, the second is what @k82cn pointed at.
// This should be fixed properly though. | ||
|
||
// This is most probably result of a BUG in retrying logic. | ||
// We report an error here so that pod scheduling can be retried. |
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.
This relies on the fact that Error will check if pod was bounded in the meantime and if so will not add it back to the unscheduled pods set (otherwise it would lead to an infinite loop).
This is true now, but can you please add a comment about it.
@@ -222,7 +227,7 @@ func (sched *Scheduler) bind(assumed *v1.Pod, b *v1.Binding) error { | |||
if err != nil { | |||
glog.V(1).Infof("Failed to bind pod: %v/%v", assumed.Namespace, assumed.Name) | |||
if err := sched.config.SchedulerCache.ForgetPod(assumed); err != nil { | |||
return fmt.Errorf("scheduler cache ForgetPod failed: %v", err) | |||
glog.Errorf("scheduler cache ForgetPod failed: %v", err) |
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.
Agree. There were two problems here. One that we were returning here, the second is what @k82cn pointed at.
2540b33
to
e5c9fb3
Compare
e19f4be
to
00c1e74
Compare
Thanks for the review! Added a comment & moved FinishBinding back up after PTAL @wojtek-t |
/ok-to-test |
00c1e74
to
2d9c6df
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: julia-stripe, wojtek-t Associated issue: 49314 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
/test all [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue |
Cherrypick in #50240 |
Commit found in the "release-1.7" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked. |
What this PR does / why we need it:
This fixes 2 places in the scheduler where pods can get stuck in Pending forever. In both these places, errors happen and
sched.config.Error
is not called afterwards. This is a problem becausesched.config.Error
is responsible for requeuing pods to retry scheduling when there are issues (see here), so if we don't callsched.config.Error
then the pod will never get scheduled (unless the scheduler is restarted).One of these (where it returns when
ForgetPod
fails instead of continuing and reporting an error) is a regression from this refactor, and with the old behavior the error was reported correctly. As far as I can tell changing the error handling in that refactor wasn't intentional.When AssumePod fails there's never been an error reported but I think adding this will help the scheduler recover when something goes wrong instead of letting pods possibly never get scheduled.
This will help prevent issues like #49314 in the future.
Release note: