Conversation
|
Welcome @xychu! |
|
Hi @xychu. 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 Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: xychu The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
| can be preempted by other pods with higher priority. | ||
| * PreemptNever means that pod never preempts other pods with lower priority and | ||
| can be preempted by other pods with higher priority. | ||
| * NonPreemptible means that pod can preempt other pods with lower priority and |
There was a problem hiding this comment.
I strongly object to a NonPreemptible policy as it clearly conflicts with high priority classes. It could cause confusion for users, is prone to mis-configuration. If cluster admins are not careful about allocating quota at low priority non-preemptible priorities, these priority classes could create abuse opportunities for users and allow them to hug cluster resources.
An example that could cause a cluster to malfunction: There are some daemon pods with critical priority in a cluster. They cannot be scheduled due to lack of resources. Today, the scheduler will remove any pod with lowest priority in the cluster to create room for such critical priority pods. Now imagine that all of those lower priority pods were non-preemptible. What should the scheduler do? Should it respect the critical priority of the daemons or the fact that lower priority pods are non-preemptible?
For these reasons, I believe we should only allow higher priority pods to yield to lower priority pods, but we should never let victims to decide whether they can be preempted or not.
There was a problem hiding this comment.
I understand that abusing NonPreemptible policy would cause resource problems.
The main motivation here is to separate the preemption from priority value. For each priority class, there will be the "value" for scheduling order and "preemption policy" for preemption part.
There was a problem hiding this comment.
Thanks for your proposal, but I think this could cause issues as I explained above.
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
|
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
|
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
|
@fejta-bot: Closed this PR. DetailsIn 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/test-infra repository. |
As we've have non-preempting(kubernetes/kubernetes#74614) policy, for some cases, users may need non-preemptible PriorityClasses as well.
We could add two more preemption policies to control both preempting and preemptible:
PreemptLowerPrioritymeans that pod can preempt other pods with lower priority and can be preempted by other pods with higher priority.PreemptNevermeans that pod never preempts other pods with lower priority and can be preempted by other pods with higher priority.NonPreemptiblemeans that pod can preempt other pods with lower priority and can not be preempted by other pods with higher priority.NonPreemptiblePreemptNevermeans that pod can not preempt other pods with lower priority and can not be preempted by other pods with higher priority.