- Node Affinity ensures that a certain pod is assigned to a particular node (one with large resources for example).
- The output is more complex that with
nodeSelectors:
```
pod-definition.yaml
apiVersion:
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: data-processor
image: data-processor
affinity:
nodeAffinity;
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: size
operator: In
values:
- Large
```
nodeSelectorTerms: is the array. The key:value pairs are underneath that.- The
operator: In key value, regarding In, that ensures the pod will be placed on a node with a value that is located in the values: key below that, in this case Large.
- To place a pod on either a large or medium node, you can also add the
Medium value:
```
values:
- Large
- Medium
```
- You can also tel the pod to not be assigned to any nodes that are labelled as
Small:
```
- matchExpressions:
- key: size
operator: NotIn
values:
- There is also the
Exists operator, which can provide a similar result to NotIn. This checks if the label exists on the node and thus the values section is not required.
```
- matchExpressions:
- key: size
operator: Exists
```
- What if a Node Affinity cannot match any nodes - for example, no nodes had the label of
size. How do we assign the pod?
- What if someone changes the label on the node at a later date.
- This is handled by the
requiredDuringSchedulingIgnoredDuringExecution property under nodeAffinity.
- This defines the Scheduler in respect to Node Affinity and defines the lifecycle of the pod.
- There are two types of node Affinity:
requiredDuringSchedulingIgnoredDuringExecution
preferredDuringSchedulingIgnoredDuringExecution
- There is an additional Node Affinity being planned:
requiredDuringSchedulingRequiredDuringExecution
- Regarding the below two types:
requiredDuringSchedulingIgnoredDuringExecution
preferredDuringSchedulingIgnoredDuringExecution
- In a pod’s lifecycle, there are two things to be aware of:
- This is when a pod does not exist and is created for the first time.
- For
requiredDuringScheduling, the Scheduler will mandate the pod be applied with the given affinity rules.
- If it cannot find an applicable node, the pod will not be scheduled.
- What if the pod placement is better than running the workload itself? In that case we set it to
preferredDuringScheduling.
- If a node is not found, the Scheduler then ignores Node Affinity rules and places the pod on any available node.
- I.E. the Scheduler will do its best to find a matching node, but if it cannot find one, it will place it on any node.
- The other state as shown above is
DuringExecution.
- This is where a change is applied in the environment and affects Node Affinity - for example, the change in a label of the node.
- In the current example, the current is
IgnoredDuringExecution. This means that the pods will continue to run and any changes in Node Affinity will not impact them once they are scheduled.
- The upcoming one in the future only has differences in the
DuringExecution phase. This is the requiredDuringSchedulingRequiredDuringExecution Affinity.
- This will therefore automatically evict any pods that running on the nodes that do not meet the Node Affinity rules.
- If the label
Large is removed from a node for example, it will be affected.