Skip to content

Commit

Permalink
Update affinity.md
Browse files Browse the repository at this point in the history
  • Loading branch information
rasika-chivate committed Jan 20, 2025
1 parent a01fd72 commit 77ff211
Showing 1 changed file with 11 additions and 11 deletions.
22 changes: 11 additions & 11 deletions docs/use/affinity.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,8 +28,8 @@ The following table provides details about the different elements involved in se
|**Components**|<ul><li>Config Server</li><li>DB Node</li><li>Router</br></br></li><li>DB Node</br><br></li><li>DB Node</li><li>Proxy</li></ul>|Applicable for **MongoDB sharded cluster**.<br/></br></br></br></br>Applicable for **MongoDB non sharded cluster**.</br></br>Applicable for **MySQL** and **PostgreSQL** databases.|
|**Priority**|Each type of Affinity can implement two distinct levels of rule enforcement:</br><ul><li>Preffered</br></br></br></br></br></li><li>Required</li></ul>|</br></br>Defines the preferences for Pod scheduling instead of strict requirements. Kubernetes will try to place the Pod according to these preferences, but if they cannot be fulfilled, the Pod will still be scheduled.</br></br>A strict requirement that must be met for a Pod to be scheduled. If the conditions in this field are not met, the Pod will remain unscheduled.|
|**Weight (1-100)**|It prioritizes preferred scheduling rules using a numerical value that indicates how strongly Kubernetes should favor specific placement preferences when scheduling Pods. Higher weights signify stronger preferences, meaning Kubernetes will prioritize fulfilling rules with higher weights over those with lower weights.|Weight is only used when the priority is **Preferred**.|
|**Topology key**|It specifies the domain or grouping within which Pods should be scheduled together (for affinity) or apart (for anti-affinity).| Node affinity rules do not include a topology key. </br></br>Here are some examples of **topologyKey**:</br><ul><li>kubernetes.io/hostname</li><li>topology.kubernetes.io/zone </li><li>topology.kubernetes.io/region</li><li>custom node labels (e.g., rack)</li></ul>|
|**key**|The key field is a label that identifies resources like Pods or nodes through their associated labels.|Here are some examples of **key**:</br><ul><li>app</li><li>security</li><li>environment</li><li>custom labels (e.g., security, web-store)</li></ul>|
|**Topology key**|TopologyKey is label key on nodes that defines the grouping or topology scope (e.g., zone, hostname) where the rules are enforced.| Node affinity rules do not include a topology key. </br></br>Here are some examples of **topologyKey**:</br><ul><li>kubernetes.io/hostname</li><li>topology.kubernetes.io/zone </li><li>topology.kubernetes.io/region</li><li>custom node labels (e.g., rack)</li></ul>|
|**key**|Key is a label key on pods used to determine the targets for applying affinity or anti-affinity rules.|Here are some examples of **key**:</br><ul><li>app</li><li>security</li><li>environment</li><li>custom labels (e.g., security, web-store)</li></ul>|
|**Operator**|The operator field specifies how a label's values match a resource, such as a Pod or node. It establishes the logical condition to determine if a resource satisfies the affinity or anti-affinity rule.</br></br>The following are all logical operators you can use in the operator field:</br><ul><li>**In**: Matches label values in a list</li><li>**NotIn**: Matches label values not in a list.</li><li>**Exists**: Matches when a label key exists, regardless of its value.</li><li>**DoesNotExist**: Matches when a label key does not exist.</li></ul>|When using the **In** and **NotIn** operators, you have to provide the values for the key as well.|
|**Values**|The values are the specific label values that must match the key for the affinity rule to apply.|Here are some examples for **values**:</br><ul><li>s2</li><li>database</li><li>production</li><li>custom values</li></ul>|

Expand All @@ -47,7 +47,7 @@ Here are several detailed use cases for affinity that highlight its diverse appl

```sh
affinity:
nodeAffinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
Expand All @@ -68,7 +68,7 @@ Here are several detailed use cases for affinity that highlight its diverse appl
Let's consider a use case in which you want to to ensure that HAProxy pods should be scheduled to run on the same Kubernetes node.

affinity:
podAffinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
Expand All @@ -91,14 +91,14 @@ Here are several detailed use cases for affinity that highlight its diverse appl


affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- haproxy
- key: app
operator: In
values:
- haproxy
topologyKey: "kubernetes.io/hostname"

??? info "What happens under the hood"
Expand Down

0 comments on commit 77ff211

Please sign in to comment.