Why the last applied configuration stored as an annotation within the object definition rather than a seperate object

Kubernetes
,
#1

Hi all,

I am very recent new comer into the field of K8s and still learning the ropes

I am following through with a course, during which I came across a video that whenever we use kubectl apply, it stores the last applied configuration as an annotation within the live object definition

I was a bit stumped since I thought that it might be stored as a seperate object in etcd. I tried asking Claude and it mentioned several reasons such as no new API calls required, updating the config and updating the last applied config requires just a single write, which makes sense but when I asked it for references, it could not share any and shared that it had inferred this knowledge

So just wanted to confirm that are the points that Claude shared above are the actual reasons or is there something missing

Thanks all !

#2

It’s a client-side mechanism (written by kubectl apply ) for determining what changes should be applied to the live object while preserving changes made by others (like kubectl scale ).

This should give some idea of the three-way merge used by kubectl while updating live objects.
After server-side-apply, many controllers are now using metadata.managedFields to track field ownership.

#3

Alright thanks for replying @santosh !

So this means that the info is available to kubectl without making any requests to the server

If we had made it a seperate object, kubectl would have to reach out to the kube-apiserver and that would have added unneccessary latency into the mix

Let me know if my understanding is correct or not

#4

To validate the fields of a live object, kubectl apply still gets a copy from what’s available in etcd.
The validation and merge happen on the client side.

#5

You can refer to these for more info:
client-side-apply, which is superseded by server-side-apply