Fixed cross-node preemption example (#7150)

* 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
@@ -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: Node is preempted. Here's an example:
* Pod P is being considered for Node N. * Pod P is being considered for Node N.
* Pod Q is running on another Node in the same zone as Node N. * Pod Q is running on another Node in the same Zone as Node N.
* Pod P has anti-affinity with Pod Q. * Pod P has Zone-wide anti-affinity with Pod Q
* There are no other cases of anti-affinity between Pod P and other Pods in the zone. (`topologyKey: failure-domain.beta.kubernetes.io/zone`).
* In order to schedule Pod P on Node N, Pod Q should be preempted, but scheduler * 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 does not perform cross-node preemption. So, Pod P will be deemed unschedulable
on Node N. 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. and Pod P could possibly be scheduled on Node N.
We may consider 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