WEBVTT

00:00.710 --> 00:05.070
-In this lecture, we will understand more
about how the Kubectl Apply command

00:05.240 --> 00:06.240
works.

00:06.930 --> 00:09.760
In the previous lecture,
we saw how a Kubectl Apply command

00:09.930 --> 00:13.600
can be used to manage objects
in a declarative way.

00:14.250 --> 00:18.370
In this lecture, we will see a bit more
about how the command works internally.

00:20.610 --> 00:25.150
The Apply command takes into consideration
the local configuration file,

00:25.670 --> 00:28.580
the live object definition on Kubernetes

00:29.020 --> 00:31.390
and the last applied configuration

00:31.880 --> 00:35.730
before making a decision
on what changes are to be made.

00:36.640 --> 00:41.710
When you run the Apply command,
if the object does not already exist,

00:42.320 --> 00:43.780
the object is created.

00:44.590 --> 00:48.160
When the object is created,
an object configuration similar

00:48.330 --> 00:52.090
to what we created locally is
created within Kubernetes

00:52.580 --> 00:55.380
but with additional fields
to store status of the object.

00:56.310 --> 01:00.560
This is the live configuration
of the object on the Kubernetes cluster.

01:01.110 --> 01:04.760
This is how Kubernetes
internally stores information

01:04.930 --> 01:09.460
about an object no matter what approach
you use to create the object.

01:10.290 --> 01:13.500
When you use the Kubectl Apply command
to create an object,

01:13.670 --> 01:15.300
it does something a bit more.

01:16.020 --> 01:19.240
The Yaml version
of the local object configuration file

01:19.400 --> 01:23.100
we wrote is converted to a JSON format,

01:23.700 --> 01:27.830
and it is then stored
as the last applied configuration.

01:28.770 --> 01:31.430
Going forward,
for any updates to the object,

01:31.840 --> 01:36.590
all the three are compared to identify
what changes are to be made

01:36.760 --> 01:38.220
on the live object.

01:38.460 --> 01:46.110
For example, say when the Nginx image
is updated to 1.19 in our local file,

01:47.050 --> 01:49.000
and we run the Kubectl Apply command,

01:49.530 --> 01:53.550
this value is compared
with the value in the live configuration,

01:54.180 --> 01:55.680
and if there is a difference,

01:55.920 --> 01:59.190
the live configuration is updated
with the new value.

02:00.270 --> 02:03.640
After any change,
the last applied JSON format

02:03.810 --> 02:08.190
is always updated to the late test
so that it's always up to date.

02:10.120 --> 02:14.430
Why do we then really need
the last applied configuration.

02:15.560 --> 02:20.290
If a field was deleted, say for example,
the type label was deleted

02:20.820 --> 02:23.350
and now when we run
the Kubectl Apply command,

02:23.820 --> 02:27.210
we see that the last applied
configuration had a label,

02:27.590 --> 02:31.040
but it's not present
in the local configuration.

02:31.590 --> 02:35.810
This means that the field needs
to be removed from the live configuration.

02:36.570 --> 02:39.300
If a field was present
in the live configuration

02:39.630 --> 02:43.420
and not present in the local
or the last applied configuration,

02:43.720 --> 02:45.560
then it will be left as is.

02:45.960 --> 02:49.280
If a field is missing from the local file,

02:49.650 --> 02:51.790
and it is present
in the last applied configuration,

02:51.960 --> 02:56.450
that means that in the previous step
or whenever the last time

02:56.620 --> 02:59.920
we ran the Kubectl Apply command,
that particular field was there,

03:00.270 --> 03:01.680
and it is now being removed.

03:02.320 --> 03:09.310
The last applied configuration helps us
figure out what fields have been removed

03:09.760 --> 03:10.900
from the local file.

03:11.330 --> 03:16.410
That field is then removed
from the actual live configuration.

03:17.540 --> 03:21.870
What we just discussed is available
for your reference in detail

03:22.360 --> 03:24.150
in the Kubernetes document pages.

03:24.430 --> 03:27.310
Follow this link to view that.

03:28.270 --> 03:32.350
We saw the three sets of files
and we know that the local file

03:32.510 --> 03:36.340
is what is stored in our local systems,
the live object configuration

03:36.710 --> 03:38.110
is in the Kubernetes memory.

03:38.520 --> 03:42.860
Where is this JSON file that has
the last applied configuration stored?

03:43.910 --> 03:46.910
It's stored
on the live object configuration

03:47.100 --> 03:50.510
on the Kubernetes cluster itself
as an annotation

03:50.680 --> 03:53.340
named last applied configuration.

03:54.340 --> 03:57.440
Remember that this is only done
when you use the Apply command.

03:57.920 --> 04:00.230
The Kubectl Create or Replace commands

04:00.790 --> 04:03.210
do not store
the last applied configuration like this.

04:03.380 --> 04:07.080
You must bear in mind
not to mix the imperative

04:07.240 --> 04:11.240
and declarative approaches
while managing the Kubernetes objects.

04:12.060 --> 04:16.530
Once you use the Apply command,
going forward, whenever a change is made,

04:16.700 --> 04:19.270
the Apply command
compares all three sections,

04:19.490 --> 04:23.030
the local pod definition file,
the live object configuration

04:23.200 --> 04:27.310
and the last applied configuration stored
within the live object configuration file

04:27.810 --> 04:31.650
for deciding what changes are
to be made to the live configuration,

04:31.810 --> 04:34.020
similar to what we saw
in the previous slide.

04:34.270 --> 04:36.090
That's it for this lecture.

04:36.340 --> 04:37.770
I will see you in the next.