Pod scheduling-2: Pod Affinity and Node Affinity

Here in this post we will be exploring in deep dive on the Node Affinity. Node Affinity is more capable alternative to node lables and selector on the Kubernetes cluster.

There are three types of affinities in Kubernetes

1. Node affinity
2. Pod affinity
3. Pod anti-affinity

Node Affinity meaning that the pod should only be scheduled on target nodes with specific lables, this is basically what the node selector does for example only schedule the db-pod on the size=large

Then, We have Pod affinity for dictates that the pod should only be scheduled on nodes where other specific pods are already running. For example cache pod  scheduled only on nodes where the webserver pods already running. In generic way we could say "Schedule Pod X  ' only on where ' Pod Y". Its like Indian girl marrying boy she stay with him! This way we can reduce the network latency between the two pods which need to communication(think about web pod connects with db pods).

Finally, the Pod anti-affinity it is like divorced pair where boy stays there girl wont stay! Pod X should not be scheduled on the same node where Pod Y running. This could be the need where you have two database processing pods don't want to run on the same node therefore you can use Pod anti-affinity to make sure that these database pods repel each other and hence they will get scheduled on two different nodes.

Let's checkout the sample of a node affinity to understand deeper

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:alpine
  affinity:
    nodeAffinity:
	  requiredDuringSchedulingIgnoredDuringExecution:
	    nodeSelectorTerms:
		- matchExpressions:
		  - key: machine-type
		    operator: In
			values:
			- hicpu 
		  - key: disk-type
		    operator: In
			values:
			- solidstate 

The node Affinity comes with two options: 

• requiredDuringSchedulingIgnoredDuringExecution
• preferredDuringSchedulingIgnoredDuringExecution 

These names of fields are really lengthy :) But it make sense to easy to use them because they do that they spell out exactly!! Here the nodeSelectorTerms will be defining the requirements for the nodeAffinitiy, there can be more number of conditions to match. Node Affinity Example -2 Here we have variation in the nodeAffinity section.

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:alpine
  affinity:
    nodeAffinity:
	  preferredDuringSchedulingIgnoredDuringExecution:
	    - weight: 2
		  preference:
	    	matchExpressions:
			- key: machine-type
			  operator: In
			  values:
			  - locpu 
		- weight: 1
		  preference:
	    	matchExpressions:		
			- key: disk-type
			  operator: In
			  values:
			  - harddisk 

In the above nodeAffinity will be look for what node have the higher weight preference given to schedule pod on it. Here the Kubernetes will schedule the pod onto node that have highest total weight on it. You might be wondered the Pod might be scheduled onto the node with no condition matched these labels because the nodeAffinity is preferred not required.

Experiment with changing the Preferred with Required