-In this lecture, we will understand more about how the Kubectl Apply command
works.
In the previous lecture, we saw how a Kubectl Apply command
can be used to manage objects in a declarative way.
In this lecture, we will see a bit more about how the command works internally.
The Apply command takes into consideration the local configuration file,
the live object definition on Kubernetes
and the last applied configuration
before making a decision on what changes are to be made.
When you run the Apply command, if the object does not already exist,
the object is created.
When the object is created, an object configuration similar
to what we created locally is created within Kubernetes
but with additional fields to store status of the object.
This is the live configuration of the object on the Kubernetes cluster.
This is how Kubernetes internally stores information
about an object no matter what approach you use to create the object.
When you use the Kubectl Apply command to create an object,
it does something a bit more.
The Yaml version of the local object configuration file
we wrote is converted to a JSON format,
and it is then stored as the last applied configuration.
Going forward, for any updates to the object,
all the three are compared to identify what changes are to be made
on the live object.
For example, say when the Nginx image is updated to 1.19 in our local file,
and we run the Kubectl Apply command,
this value is compared with the value in the live configuration,
and if there is a difference,
the live configuration is updated with the new value.
After any change, the last applied JSON format
is always updated to the late test so that it's always up to date.
Why do we then really need the last applied configuration.
If a field was deleted, say for example, the type label was deleted
and now when we run the Kubectl Apply command,
we see that the last applied configuration had a label,
but it's not present in the local configuration.
This means that the field needs to be removed from the live configuration.
If a field was present in the live configuration
and not present in the local or the last applied configuration,
then it will be left as is.
If a field is missing from the local file,
and it is present in the last applied configuration,
that means that in the previous step or whenever the last time
we ran the Kubectl Apply command, that particular field was there,
and it is now being removed.
The last applied configuration helps us figure out what fields have been removed
from the local file.
That field is then removed from the actual live configuration.
What we just discussed is available for your reference in detail
in the Kubernetes document pages.
Follow this link to view that.
We saw the three sets of files and we know that the local file
is what is stored in our local systems, the live object configuration
is in the Kubernetes memory.
Where is this JSON file that has the last applied configuration stored?
It's stored on the live object configuration
on the Kubernetes cluster itself as an annotation
named last applied configuration.
Remember that this is only done when you use the Apply command.
The Kubectl Create or Replace commands
do not store the last applied configuration like this.
You must bear in mind not to mix the imperative
and declarative approaches while managing the Kubernetes objects.
Once you use the Apply command, going forward, whenever a change is made,
the Apply command compares all three sections,
the local pod definition file, the live object configuration
and the last applied configuration stored within the live object configuration file
for deciding what changes are to be made to the live configuration,
similar to what we saw in the previous slide.
That's it for this lecture.
I will see you in the next.