✦ For everyone, free.

Practical knowledge for real and everyday life

Home

3.17 Kubernetes Control Plane Object Lifecycle

Kubernetes Control Plane Object Lifecycle explains how core objects are created, managed, and deleted within the Kubernetes control plane.

Kubernetes Control Plane Object Lifecycle is the specific sequence of stages an object passes through from its initial creation request through eventual deletion, as tracked and enforced entirely by the control plane, describing the role finalizers and deletion timestamps play in ensuring cleanup logic completes before an object's record is actually removed from etcd.


Creation Stage

Admission Before Existence

An object's lifecycle within the control plane begins only once a creation request has passed entirely through authentication, authorization, and the full admission chain; before that point, no object exists in any form, and any rejection at those stages means the object's lifecycle never begins at all.

lifecycle start = successful admission

Active Stage

Continuous Spec and Status Updates

Once created, an object enters its active stage, during which its spec may be updated by clients declaring new desired state, and its status may be updated by controllers reporting newly observed actual state, with this stage persisting indefinitely until deletion is requested.

Resource Version Tracking Every Change

Throughout the active stage, every modification increments the object's resource version, which the control plane uses to detect and reject conflicting concurrent updates, ensuring the object's recorded history of changes remains coherent even under concurrent access.


Deletion Request Stage

A Deletion Timestamp, Not Immediate Removal

When a delete request is received, the control plane's object lifecycle does not necessarily remove the object immediately; instead, if the object has finalizers registered, a deletion timestamp is set, marking the object as pending deletion while it otherwise remains fully present and readable.

Finalizers as a Blocking Mechanism

Finalizers are architected as an explicit list attached to the object, each representing some cleanup work that must complete before deletion can proceed; the control plane will not remove the object's record from etcd until every finalizer in this list has been removed by whatever controller is responsible for it.


Finalization Stage

Controllers Performing Cleanup

During finalization, controllers observing the object's deletion timestamp perform whatever cleanup their finalizer represents, such as releasing an external resource, and then remove their specific finalizer entry from the object once that cleanup is complete.

Final Removal Once the List Is Empty

Only once every finalizer has been removed, leaving the list empty, does the control plane's lifecycle proceed to actually delete the object's record from etcd, completing its lifecycle.


Why This Staged Deletion Exists

Preventing Premature Loss of Cleanup Opportunity

Without this staged approach, an object could be deleted from etcd before external resources it was responsible for, such as a cloud load balancer, had been properly cleaned up, leaving orphaned resources with no remaining trigger to prompt their removal.


Object Lifecycle Diagram

Created Active Finalizing Deleted