whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixed cross-node preemption example (#7150)

Browse Source 
* Fixed cross-node preemption example

The constraint between P and Q should be pod affinity rather than anti-affinity in order to the example to be correct.
Fixes #7149

* Fixed example to emphasize Zone namespace in pod anti-affinity
This commit is contained in:
Alex Glikson
2018-02-26 13:47:44 -05:00
committed by k8s-ci-robot
parent 7d85f99953
commit 1f72c7a1b8
1 changed files with 6 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/configuration/pod-priority-preemption.md
+6 -5
View File
@@ -220,14 +220,15 @@ can be scheduled on N. P might become feasible on N only if a Pod on another
Node is preempted. Here's an 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 anti-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
* Pod Q is running on another Node in the same Zone as Node N.
* Pod P has Zone-wide anti-affinity with Pod Q
(`topologyKey: failure-domain.beta.kubernetes.io/zone`).
* 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 can 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,
If Pod Q were removed from its Node, the Pod anti-affinity violation would be gone,
and Pod P could possibly be scheduled on Node N.
We may consider adding cross Node preemption in future versions if we find an