-Hello and welcome to this lecture.
In this lecture,
we will talk about node affinity feature in Kubernetes.
The primary purpose of node affinity feature
is to ensure that pods are hosted on particular nodes.
In this case, to ensure the large data processing pod ends up on node one.
In the previous lecture, we did this easily using node 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,
place 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.
Then you have the node selector terms that is 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 in 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 pod 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 label size to large and medium nodes.
The smaller nodes don't even have the label 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 operator will simply check if the label size exists on the nodes,
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 the 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 behavior 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.
There are two additional types of node affinity planned
as of this recording.
Required during scheduling required during execution
and preferred 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 node.
Now, what if the node 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 the 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 pod on any available node.
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 place it anywhere."
The second part of the property or the other state is during execution.
During execution is the state where a pod 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 set earlier called size equals large from the Node.
Now, what will 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 to ignored, which means pods will continue to run
and any changes in node affinity will not impact them
once they are scheduled.
The two new types expected in the future
only have a difference DuringExecution phase.
A new option called required DuringExecution is introduced,
which will evict any pods that are running on nodes
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 taints and tolerations and node affinity.