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.
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.