-
Notifications
You must be signed in to change notification settings - Fork 13
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
sched: controller: set scheduler priority #979
sched: controller: set scheduler priority #979
Conversation
/hold |
@@ -55,7 +55,8 @@ import ( | |||
) | |||
|
|||
const ( | |||
leaderElectionResourceName = "numa-scheduler-leader" | |||
leaderElectionResourceName = "numa-scheduler-leader" | |||
SystemNodeCriticalPriorityClass = "system-node-critical" |
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 make it private and rename to convey the intent, not the value. Maybe schedulerPriorityClassName
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.
In addition, please record in the commit message why system-node-critical
and not system-cluster-critical
(I'm fine with the decision, but let's record the reason)
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.
updated, thanks for raising
So far the scheduler priority is set to default which is 0 this is risky especially when the preemtion of pods is needed to fit more important pods. The NRS is important enough to deserve the most critical priority class system-node-critical which is the same priority for the kube-scheduler. We need this priority set always regardless how many replicas are set for the scheduler, and especially if we look to optimize the HA of the scheduler. We choose system-node-critical over system-cluster-critical because we don't want to allow SS preemption by higher-priority pods. If it was set to system-cluster-critical and an event is triggered that requires pod eviction, which would be for scheduling system-node-critical workloads, the SS would be at risk of being evicted. although this would be very rare and the evicted pod will be rescheduled, there is no convincing reason not to make it node-critical. addresses openshift-kni#974 Signed-off-by: Shereen Haj <[email protected]>
506b82b
to
7844680
Compare
/unhold |
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.
/approve
/lgtm
thanks!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ffromani, shajmakh 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 |
/cherry-pick release-4.16 |
@shajmakh: #979 failed to apply on top of branch "release-4.16":
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. |
Manual backport of openshift-kni#979 Signed-off-by: Shereen Haj <[email protected]>
So far the scheduler priority is set to default which is 0 this is risky especially when the preemtion of pods is needed to fit more important pods.
The NRS is important enough to deserve the most critical priority class system-node-critical which is the same priority for the kube-scheduler.
addresses #974