-
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
Scheduler extension #13580
Scheduler extension #13580
Conversation
Can one of the admins verify that this patch is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist") If this message is too spammy, please complain to ixdy. |
Please review when you get a chance. |
Labelling this PR as size/XL |
@davidopp Any feedback? Can you please review after 1.1 freeze? |
I briefly took a peek at this last night and am planning to review this by end of tomorrow. Very sorry for the delay. |
Very sorry for the delay. I will review it this Friday. |
I would like to see some kind of documentation included in this PR that describes the capability being added and how people might make use of it to externalize/extend scheduling logic. |
+1 |
@@ -26,6 +29,8 @@ type Policy struct { | |||
Predicates []PredicatePolicy `json:"predicates"` | |||
// Holds the information to configure the priority functions | |||
Priorities []PriorityPolicy `json:"priorities"` | |||
// Holds the information to communicate with the extender | |||
ExtenderConfig *ExtenderConfig `json:"extender"` |
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.
Should we allow an array of these, so the user can configure more than one?
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.
Makes sense, will do.
Sorry it took me so long to take a look at this. This looks OK to me, with all of the caveats @bgrant0607 mentioned here That is -- you are going to need to make significant changes to this when we start making planned scheduler changes that we just haven't had time for yet (e.g. unified extension mechanism, and changing the way we choose the "best" machine from summing up priority scores to using a decision tree). Since we also want to make improvements in scheduler performance and generally make the scheduler implementation a bit cleaner, probably we will just create a new scheduler for all of this, and allow people to continue using the old scheduler but won't do new work on it. Of course, before submitting you need to write unit tests and either e2e or integration test. |
@davidopp Addressed review comments, PTAL. I have implemented unit test only at this point. Need to spend more time on figuring out e2e/integ test cases for this. |
|
||
# Scheduler extender | ||
|
||
Kubernetes scheduler schedules based on resources managed by Kubernetes. Scheduler extender is a way to extend the scheduling capability of k8s for resources that are not managed by k8s. A couple of example use cases are storage affinity and network availability. |
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 this needs a bit more introduction, and actually shouldn't mention "resources that are not managed by k8s" because there are other ways to handle that (e.g. write your own scheduler). I'd just replace this paragraph with:
There are three ways to add new scheduling rules (predicates and priority functions) to Kubernetes: (1) by adding these rules to the scheduler and recompiling (described here: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/scheduler.md), (2) implementing your own scheduler process that runs instead of, or alongside of, the standard Kubernetes scheduler, (3) implementing a "scheduler extender" process that the standard Kubernetes scheduler calls out to as a final pass when making scheduling decisions. This document describes the third approach. (Note that the three approaches are not mutually exclusive.)
LGTM |
GCE e2e test build/test passed for commit 31450b691048532a2001a4b278cf0eb87e311ffb. |
@ravigadde integration test is failing with
Did you try running the integration tests locally? |
PR changed after LGTM, removing LGTM. |
GCE e2e test build/test passed for commit cadc24e. |
@davidopp Done, all tests pass now |
LGTM |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e test build/test passed for commit cadc24e. |
Automatic merge from submit-queue |
Auto commit by PR queue bot
Yay! Thanks for your patience with this, @ravigadde |
@davidopp Thank you for your effort to make this happen |
@ravigadde Hi, is there sample implementation of an extender somewhere? |
@khoi0107 I haven't seen an open implementation. @ping035627 submitted a patch sometime ago, not sure if their implementation is open. If you have any specific questions I can help with, ping me on slack - ravi.gadde |
Implementation of scheduler extension proposal as discussed in #11470