Skip to content

Commit

Permalink
Add performance implications of inter-pod affinity/anti-affinity (#5979)
Browse files Browse the repository at this point in the history
  • Loading branch information
bsalamat authored and zacharysarah committed Nov 3, 2017
1 parent 461698d commit f4fdc4e
Showing 1 changed file with 4 additions and 0 deletions.
4 changes: 4 additions & 0 deletions docs/concepts/configuration/assign-pod-node.md
Original file line number Diff line number Diff line change
Expand Up @@ -157,6 +157,10 @@ like node, rack, cloud provider zone, cloud provider region, etc. You express it
key for the node label that the system uses to denote such a topology domain, e.g. see the label keys listed above
in the section [Interlude: built-in node labels](#interlude-built-in-node-labels).

**Note:** Inter-pod affinity and anti-affinity require substantial amount of
processing which can slow down scheduling in large clusters significantly. We do
not recommend using them in clusters larger than several hundred nodes.

As with node affinity, there are currently two types of pod affinity and anti-affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and
`preferredDuringSchedulingIgnoredDuringExecution` which denote "hard" vs. "soft" requirements.
See the description in the node affinity section earlier.
Expand Down

0 comments on commit f4fdc4e

Please sign in to comment.