From 1f72c7a1b88fb29e3221fa4d3fd144ae5ca0bf00 Mon Sep 17 00:00:00 2001 From: Alex Glikson Date: Mon, 26 Feb 2018 13:47:44 -0500 Subject: [PATCH] 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 --- .../concepts/configuration/pod-priority-preemption.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/concepts/configuration/pod-priority-preemption.md b/docs/concepts/configuration/pod-priority-preemption.md index 1a85f4593b..01c1c764ed 100644 --- a/docs/concepts/configuration/pod-priority-preemption.md +++ b/docs/concepts/configuration/pod-priority-preemption.md @@ -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