Skip to content
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.

Sign up for GitHub

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

Add user docs for pod priority and preemption #5328

Merged
merged 3 commits into from
Sep 13, 2017
Merged

Add user docs for pod priority and preemption #5328

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4036aae
Add user docs for pod priority and preemption
bsalamat Sep 6, 2017
92ce2eb
Update pod-priority-preemption.md
steveperry-53 Sep 13, 2017
812db65
More updates
bsalamat Sep 13, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
More updates
  • Loading branch information
@bsalamat
bsalamat committed Sep 13, 2017
commit 812db656e5b9f002f4a96f2315490ee1e0259ad6
30 changes: 6 additions & 24 deletions docs/concepts/configuration/pod-priority-preemption.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ To use priority and preemption in Kubernetes 1.8, follow these steps:

1. Create Pods with `PriorityClassName` set to one of the added PriorityClasses.
Of course you do not need to create the Pods directly; normally you would add
`PriorityClassName` to the Pod template of a collection object likea Deployment.
`PriorityClassName` to the Pod template of a collection object like a Deployment.

The following sections provide more information about these steps.

Expand Down Expand Up @@ -188,7 +188,7 @@ the answer to this question is yes: "If all the Pods with lower priority than
the pending Pod are removed from the Node, can the pending pod be scheduled on
the Node?"

**Note**: Preemption does not necessarily remove all lower-priority Pods. If the
**Note:** Preemption does not necessarily remove all lower-priority Pods. If the
pending pod can be scheduled by removing fewer than all lower-priority Pods, then
only a portion of the lower-priority Pods are removed. Even so, the answer to the
preceding question must be yes. If the answer is no, the Node is not considered
Expand Down Expand Up @@ -223,32 +223,14 @@ Node is preempted. Here's an example:
* Pod Q is running on another Node in the same zone as Node N.
* Pod P has anit-affinity with Pod Q.
* There are no other cases of anti-affinity between Pod P and other Pods in the zone.
* In order to schedule Pod P on Node N, Pod Q should be preempted, but scheduler
does not perform cross-node preemption. So, Pod P will be deemed unschedulable
on Node N.

If Pod Q were removed from its Node, the anti-affinity violation would be gone,
and Pod P could possibly be scheduled on Node N.

TODO: Revise this next example.
@bsalamat, I don't understand the example with Node M. I took a stab at it below,
but I don't think I've gotten it right. I don't see why if we start by considerin N,
we need a third Node M.

Here's another example:

* Pod P is being considered for Node N.
* Pod Q is running on another Node in the same zone as Node N.
* Pod P has anit-affinity with Pod Q.
* There are no other cases of anti-affinity between Pod P and other Pods in the zone.
* Pod Q is preempted from its Node.
* Pod P is bigger than Pod Q, so there still isn't enough room to run Pod P on Pod Q's Node.
* For reasons of size and priority, Pod P can't run on Node N either.
* There is another Node M is the same zone as Node N and Q's Node.

The anti-affinity violation is gone because Pod Q has been removed. If lower-priority
Pods can be prempted from Node M, Pod P could possibly be scheduled on Node M.

Version 1.8 docs not support either of these examples of cross Node preemption.

We considering adding cross Node preemption in future versions if we find an
We may consider adding cross Node preemption in future versions if we find an
algorithm with reasonable performance. We cannot promise anything at this point,
and cross Node preemption will not be considered a blocker for Beta or GA.

Expand Down