-
Notifications
You must be signed in to change notification settings - Fork 918
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
[Proposal] Support for resource scheduling suspend and resume capabilities #5690
[Proposal] Support for resource scheduling suspend and resume capabilities #5690
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #5690 +/- ##
==========================================
+ Coverage 48.37% 48.40% +0.03%
==========================================
Files 665 665
Lines 54795 54850 +55
==========================================
+ Hits 26507 26552 +45
- Misses 26569 26584 +15
+ Partials 1719 1714 -5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Should also add rb status condition just like #5317. |
4e3260e
to
e0ca35f
Compare
e0ca35f
to
ba71093
Compare
/assign |
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.
/assign
<!-- | ||
Karmada 目前已经允许用户通过 Suspension 来暂停和恢复资源的 propagation 行为,这提高了 Karmada 的灵活性。 | ||
|
||
但是目前 Suspension 支持的不够彻底,在 Karmada 中资源的分发可以简单理解为两个阶段,资源的调度和资源的传播。 | ||
|
||
目前传播阶段可以较为灵活的由用户暂停和恢复,但是没有在调度阶段,没有提供暂停和恢复的能力。 | ||
|
||
我们希望在 Karmada 的基础之上,通过暂停调度的方式,实现队列和配额管理等高阶能力,从而将集群有限的资源优先调度给高优先级的工作负载,增强 Karmada 在多集群调度的能力,从而满足用户在复杂场景下的需求。 | ||
|
||
本文基于 [#5118](https://github.com/karmada-io/karmada/pull/5118) 在其中的 Suspension 基础之上,提供了暂停资源调度的能力。 | ||
--> |
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 all Chinese content from the proposal. We should only use English to describe and review the proposal to avoid issues like being out of sync.
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.
done
--> | ||
Karmada scheduler listens the `ResourceBinding` resource , ignores the `ResourceBinding` resource when `ResourceBinding.Suspension.Scheduling`=true, pauses scheduling, and resumes scheduling when `ResourceBinding.Suspension.Scheduling`=false. | ||
|
||
And when the `ResourceBinding` has been successfully scheduled, it is no longer allowed to modify the `ResourceBinding` from non-suspended to suspended, and when `ResourceBinding.Suspension.Scheduling` is set to true or false, the corresponding condition is refreshed in the status of the `ResourceBinding`. |
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.
And when the
ResourceBinding
has been successfully scheduled, it is no longer allowed to modify theResourceBinding
from non-suspended to suspended,
It sounds like we need to introduce a validating webhook to force this, right? Can you explain why we need to do that?
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.
Yeah I have considered that, becaue the scheduling suspension happened before scheduling success, and after rb is successfully scheduled it's no necessary to suspend rb again, which will also confuse users.
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 the work
suspension has the same problem.
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.
and after rb is successfully scheduled it's no necessary to suspend rb again, which will also confuse users.
Yeah, I agree, it brings ambiguousness if we don't force that.
I will track this on #5977.
ba71093
to
971f7d1
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.
Generally looks good to me.
But, would you like to squash the commits?
Signed-off-by: Vacant2333 <[email protected]> Signed-off-by: Monokaix <[email protected]>
971f7d1
to
2fdd66a
Compare
done |
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: RainbowMango 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 |
/reopen |
@Monokaix: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
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. |
/reopen |
@RainbowMango: Reopened this PR. In response to this:
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. |
What type of PR is this?
/kind design
/kind documentation
Which issue(s) this PR fixes:
Fixes #4937
Special notes for your reviewer:
Does this PR introduce a user-facing change?: