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

Correct meaning of scheduling affinity benefits (#18764)

Browse Source 
Commit f5bfa04aa4 incorrectly reworded the
benefits of using affinity / anti-affinity for Pod scheduling.
Revise this with new wording.
This commit is contained in:
Tim Bannister
2020-03-16 05:08:35 +00:00
committed by GitHub
parent 08e21a1e90
commit 83637c1ed2
1 changed files with 3 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/configuration/assign-pod-node.md
+3 -2
View File
@@ -111,9 +111,10 @@ For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.
`nodeSelector` provides a very simple way to constrain pods to nodes with particular labels. The affinity/anti-affinity `nodeSelector` provides a very simple way to constrain pods to nodes with particular labels. The affinity/anti-affinity
feature, greatly expands the types of constraints you can express. The key enhancements are feature, greatly expands the types of constraints you can express. The key enhancements are
1. the language is more expressive (not just "AND or exact match") 1. The affinity/anti-affinity language is more expressive. The language offers more matching rules
besides exact matches created with a logical AND operation;
2. you can indicate that the rule is "soft"/"preference" rather than a hard requirement, so if the scheduler 2. you can indicate that the rule is "soft"/"preference" rather than a hard requirement, so if the scheduler
can't satisfy it, the pod will still be scheduled can't satisfy it, the pod will still be scheduled;
3. you can constrain against labels on other pods running on the node (or other topological domain), 3. you can constrain against labels on other pods running on the node (or other topological domain),
rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located