WEBVTT

00:00.454 --> 00:02.817
-Hello and welcome to this lecture.

00:02.942 --> 00:03.942
In this lecture,

00:04.023 --> 00:08.208
we will talk about
node affinity feature in Kubernetes.

00:08.511 --> 00:11.276
The primary purpose
of node affinity feature

00:11.356 --> 00:15.763
is to ensure that pods
are hosted on particular nodes.

00:15.887 --> 00:21.842
In this case, to ensure the large data
processing pod ends up on node one.

00:21.983 --> 00:26.874
In the previous lecture,
we did this easily using node selectors.

00:27.105 --> 00:30.914
We discussed that you cannot provide
advanced expressions

00:30.994 --> 00:34.880
like OR, or NOT with node selectors.

00:35.534 --> 00:37.782
The node affinity feature provides us

00:37.862 --> 00:43.501
with advanced capabilities
to limit pod placement on specific nodes.

00:43.666 --> 00:47.026
With great power comes great complexity,

00:47.124 --> 00:53.386
so the simple node selector specification
will now look like this with node affinity

00:53.481 --> 00:56.945
although both does exactly the same thing,

00:57.073 --> 00:59.686
place the pod on the large node.

01:00.313 --> 01:02.535
Let us look at it a bit closer.

01:03.215 --> 01:08.561
Under spec, you have affinity
and then node affinity under that,

01:08.747 --> 01:10.523
and then you have a property

01:10.603 --> 01:14.213
that looks like a sentence
called required during scheduling,

01:14.293 --> 01:16.584
ignored during execution.

01:16.749 --> 01:18.506
No description needed for that.

01:18.801 --> 01:22.004
Then you have the node selector terms
that is array,

01:22.085 --> 01:26.288
and that is where you will specify
the key and value pairs.

01:26.543 --> 01:29.653
The key value pairs are in the form key,

01:29.875 --> 01:34.005
operator, and value
where the operator is in.

01:34.242 --> 01:38.177
The in operator ensures
that the pod will be placed on a node

01:38.257 --> 01:42.828
whose label size has any value
in the list of values specified here.

01:42.918 --> 01:46.595
In this case, it is just one called large.

01:46.810 --> 01:51.091
If you think your pod could be placed
on a large or a medium node,

01:51.200 --> 01:55.483
you could simply add the value
to the list of values like this.

01:56.086 --> 02:02.949
You could use the not-in operator
to say something like size not-in small,

02:03.044 --> 02:07.794
where node affinity will match the node
with a size not set to small.

02:08.678 --> 02:14.148
We know that we have only set
the label size to large and medium nodes.

02:14.289 --> 02:17.385
The smaller nodes
don't even have the label set,

02:17.494 --> 02:21.207
so we don't really have to even
check the value of the label

02:21.502 --> 02:25.668
as long as we are sure we don't set
a label size to the smaller nodes

02:25.836 --> 02:30.251
using the exists operator
will give us the same result.

02:30.410 --> 02:35.750
The exists operator will simply check
if the label size exists on the nodes,

02:35.840 --> 02:38.461
and you don't need the values section
for that,

02:38.541 --> 02:41.042
as it does not compare the values.

02:41.216 --> 02:44.228
There are a number
of other operators as well,

02:44.505 --> 02:47.865
check the documentation
for specific details.

02:48.019 --> 02:50.356
Now, we understand all of this,

02:50.448 --> 02:55.488
and we're comfortable with creating a pod
with specific affinity rules.

02:55.844 --> 02:59.191
When the pods are created,
these rules are considered

02:59.271 --> 03:02.755
and the pods are placed
onto the right nodes,

03:02.901 --> 03:08.108
but what if node affinity could not match
a node with a given expression?

03:08.203 --> 03:13.233
In this case, what if there are no nodes
with the label called size?

03:13.488 --> 03:16.628
Say we had the labels
and the pods are scheduled.

03:16.725 --> 03:21.231
What if someone changes the label
on the node at a future point in time,

03:21.835 --> 03:24.472
will the pod continue to stay on the node?

03:24.811 --> 03:26.495
All of this is answered

03:26.575 --> 03:30.507
by the long sentence-like
property under node affinity

03:30.607 --> 03:34.145
which happens to be
the type of node affinity.

03:34.657 --> 03:36.272
The type of node affinity

03:36.353 --> 03:40.095
defines the behavior of the scheduler
with respect to node affinity

03:40.176 --> 03:43.441
and the stages
in the lifecycle of the pod.

03:43.837 --> 03:47.224
There are currently two types
of node affinity available,

03:47.535 --> 03:51.628
required during scheduling,
ignored during execution,

03:51.820 --> 03:56.316
and preferred during scheduling
ignored during execution.

03:56.618 --> 03:59.996
There are two additional types
of node affinity planned

04:00.170 --> 04:02.036
as of this recording.

04:02.317 --> 04:05.633
Required during scheduling
required during execution

04:05.924 --> 04:09.977
and preferred during scheduling
required during execution.

04:11.743 --> 04:14.349
We will now break this down
to understand further.

04:14.580 --> 04:18.780
We will start by looking
at the two available affinity types.

04:18.932 --> 04:21.429
There are two states
in the lifecycle of a pod

04:21.510 --> 04:23.906
when considering node affinity,

04:24.059 --> 04:27.274
during scheduling and during execution.

04:27.665 --> 04:29.575
During scheduling is the state

04:29.655 --> 04:33.875
where a pod does not exist
and is created for the first time.

04:34.040 --> 04:37.261
We have no doubt that
when a pod is first created,

04:37.341 --> 04:39.202
the affinity rules specified

04:39.283 --> 04:42.723
are considered to place
the pods on the right node.

04:42.863 --> 04:46.422
Now, what if the node
with matching labels are not available?

04:46.502 --> 04:50.579
For example,
we forgot to label the node as large.

04:50.698 --> 04:54.092
That is where the type
of node affinity used

04:54.173 --> 04:55.609
comes into play.

04:55.740 --> 04:59.418
If you select the required type
which is the first one,

04:59.518 --> 05:01.165
the scheduler will mandate

05:01.245 --> 05:05.904
that the pod be placed on a node
with the given affinity rules.

05:06.235 --> 05:10.073
If it cannot find one,
the pod will not be scheduled.

05:10.314 --> 05:15.468
This type will be used in cases
where the placement of the pod is crucial.

05:15.624 --> 05:19.692
If a matching node does not exist,
the pod will not be scheduled,

05:20.197 --> 05:23.015
but let's say the pod placement
is less important

05:23.109 --> 05:25.620
than running the workload itself.

05:26.007 --> 05:28.987
In that case,
you could set it to preferred,

05:29.089 --> 05:32.591
and in cases
where a matching node is not found,

05:32.751 --> 05:36.305
the scheduler will simply ignore
node affinity rules

05:36.418 --> 05:39.667
and place the pod on any available node.

05:39.973 --> 05:42.365
This is a way of telling the scheduler,

05:42.463 --> 05:45.827
"Hey, try your best to place
the pod on matching node,

05:45.953 --> 05:50.066
but if you really cannot find one,
just place it anywhere."

05:50.331 --> 05:55.137
The second part of the property
or the other state is during execution.

05:55.406 --> 05:59.331
During execution is the state
where a pod has been running

05:59.442 --> 06:03.603
and a change is made in the environment
that affects node affinity,

06:03.683 --> 06:06.452
such as a change in the label of a node.

06:06.649 --> 06:10.279
For example,
say an administrator removed the label

06:10.359 --> 06:14.635
we set earlier called size
equals large from the Node.

06:14.753 --> 06:18.317
Now, what will happen to the pods
that are running on the node?

06:18.641 --> 06:19.898
As you can see,

06:20.092 --> 06:23.056
the two types of node affinity
available today

06:23.136 --> 06:28.099
has this value set to ignored,
which means pods will continue to run

06:28.179 --> 06:32.493
and any changes in node affinity
will not impact them

06:32.644 --> 06:34.173
once they are scheduled.

06:35.673 --> 06:38.414
The two new types
expected in the future

06:38.495 --> 06:42.078
only have a difference
DuringExecution phase.

06:42.221 --> 06:46.487
A new option called
required DuringExecution is introduced,

06:46.583 --> 06:49.577
which will evict any pods
that are running on nodes

06:49.657 --> 06:52.249
that do not meet affinity rules.

06:52.475 --> 06:53.668
In the earlier example,

06:53.795 --> 06:58.244
a pod running on the large node
will be evicted or terminated

06:58.328 --> 07:01.736
if the label large
is removed from the node.

07:02.305 --> 07:06.164
Well, that's it for this lecture,
head over to the coding exercises

07:06.244 --> 07:09.568
and practice working
with node affinity rules.

07:09.889 --> 07:14.859
In the next lecture, we will compare
taints and tolerations and node affinity.