Hello and welcome to this lecture. In this lecture
We will talk about known affinity feature in Kubernetes.
The primary purpose of node affinity feature is to ensure that pods are hosted on particular notes.
In this case to ensure the large data processing pod ends up on no one in the previous lecture we did
this easily using notes selectors we discussed that you cannot provide advanced expressions like or
or not with node selectors the node affinity feature provides us with advanced capabilities to limit
pod placement on specific nodes with great power comes great complexity.
So the simple node selector specification will now look like this with node affinity although both does
exactly the same thing plays the pod on the large node let us look at it a bit closer under spec you
have affinity and then node affinity under that and then you have a property that looks like a sentence
called required during scheduling ignored during execution no description needed for that and then you
have the node selector terms that is an array and that is where you will specify the key and value pairs
the key value pairs are in the form key operator and value where the operator is in the operator ensures
that the pod will be placed on a node whose label size has any value in the list of values specified
here in this case it is just one called large.
If you think your part could be placed on a large or a medium node you could simply add the value to
the list of values like this you could use the not in operator to say something like size not in small
where node affinity will match the node with a size not set to small.
We know that we have only set the labels size too large and medium nodes the smaller nodes don't even
have the labels set.
So we don't really have to even check the value of the label as long as we are sure we don't set a label
size to the smaller nodes using the exists operator will give us the same result.
The exists the operator will simply check if the label size exists on the notes and you don't need the
values section for that as it does not compare the values.
There are a number of other operators as well.
Check the documentation for specific details.
Now we understand all of this and we're comfortable with creating a pod with specific affinity rules
when the pods are created.
These rules are considered and the pods are placed onto the right nodes.
But what if node affinity could not match a node with a given expression.
In this case what if there are no nodes with a label called size say we had the labels and the pods
are scheduled.
What if someone changes the label on the node at a future point in time.
Will the pod continue to stay on the Node.
All of this is answered by the long sentence like property under node affinity which happens to be the
type of node affinity the type of node affinity defines the behaviour of the scheduler with respect to
node affinity and the stages in the lifecycle of the pod.
There are currently two types of node affinity available required during scheduling ignored during execution
and preferred during scheduling ignored during execution and there are additional types of node affinity
planed.
As of this recording required during scheduling required during execution we will now break this down
to understand further.
We will start by looking at the two available affinity types.
There are two states in the lifecycle of a pod when considering node affinity during scheduling and
during execution during scheduling.
Is the state where a pod does not exist and is created for the first time.
We have no doubt that when a pod is first created the affinity rules specified are considered to place
the pods on the right note.
Now what if the nodes with matching labels are not available.
For example we forgot to label the node as large.
That is where the type of node affinity used comes into play.
If you select the required type which is the first one the scheduler will mandate that the pod be placed
on a node with a given affinity.
Rules if it cannot find one the pod will not be scheduled.
This type will be used in cases where the placement of the pod is crucial.
If a matching node does not exist the pod will not be scheduled.
But let's say the pod placement is less important than running the workload itself.
In that case you could set it to preferred and in cases where a matching node is not found.
The scheduler will simply ignore node affinity rules and place the card on any available note.
This is a way of telling the scheduler hey try your best to place the pod on matching node but if you
really cannot find one just plays it anywhere.
The second part of the property or the other state is during execution during execution is the state
where a part has been running and a change is made in the environment that affects node affinity such
as a change in the label of a node.
For example say an administrator removed the label we said earlier called size equals large from the
node.
Now what would happen to the pods that are running on the Node.
As you can see the two types of node affinity available today has this value set too ignored which means
pods will continue to run and any changes in node affinity will not impact them once they are scheduled.
The new types expected in the future only have a difference in the during execution phase a new option
called required during execution is introduced which will evict any pods that are running on notes
that do not meet affinity rules.
In the earlier example, a pod running on the large node will be evicted or terminated if the label large
is removed from the node.
Well that's it for this lecture.
Head over to the coding exercises and practice working with node affinity rules in the next lecture.
We will compare tables and toleration and node affinity.