9.1 Kubernetes Pod Lifecycle Scope
Kubernetes Pod Lifecycle Scope defines how pods transition through phases, from creation to termination, within the Kubernetes environment.
Kubernetes Pod Lifecycle Scope is the defined boundary of states, transitions, and events that a Pod passes through from the moment it is submitted to the API server until it is finally removed from the cluster. This scope establishes the vocabulary and structural framework used to describe everything from initial scheduling through steady-state execution, health evaluation, and eventual graceful or forced termination, and it forms the foundation upon which more specific lifecycle mechanisms, such as probes and hooks, are built.
Boundaries of the Lifecycle
From Submission to Deletion
The lifecycle begins when a Pod object is created in the API server, whether directly by a user or indirectly by a controller, and ends when the Pod object is fully deleted from etcd. Everything occurring within that window, including scheduling delays, image pulls, container starts, restarts, and probe evaluations, falls within the lifecycle scope, while events before creation or after final deletion, such as controller-level decisions to create a replacement Pod, fall outside it.
Node-Bound Versus Cluster-Level Scope
Once scheduled, a significant portion of a Pod's lifecycle is managed locally by the kubelet on the node it has been assigned to, including starting containers, executing probes, and enforcing restart policy. The cluster-level control plane retains a separate, higher-level scope concerned with whether the Pod continues to exist as an object at all, which becomes relevant during eviction, preemption, or node failure scenarios.
Major Lifecycle Stages
Scheduling Stage
Before a Pod can begin executing, it must pass through the scheduling stage, during which the scheduler evaluates resource requirements, affinity rules, taints, and tolerations to select a suitable node. A Pod remains in the Pending phase for the entire duration of this stage, regardless of how long it takes.
Initialization Stage
Once bound to a node, the Pod enters an initialization stage in which any init containers execute sequentially to completion. This stage is fully contained within the lifecycle scope and is tracked through the Initialized condition, and no application container begins until this stage concludes successfully.
Steady-State Execution Stage
After initialization, the Pod enters its steady-state execution stage, during which application containers run, probes are continuously evaluated, and the container runtime may restart individual containers according to the configured restart policy without altering the Pod's overall identity.
Termination Stage
The termination stage begins when the Pod is marked for deletion, either by direct user action, controller-driven replacement, or node-level eviction. This stage encompasses the execution of any preStop hooks, the delivery of termination signals to running processes, and the grace period during which the Pod is allowed to shut down before being forcibly removed.
Scope Relative to Health Signals
Probes as an Ongoing Lifecycle Concern
Liveness, readiness, and startup probes operate continuously throughout the steady-state execution stage, meaning health evaluation is not a discrete lifecycle event but a persistent, recurring process that runs for as long as the Pod remains alive, directly influencing whether the kubelet restarts a container or whether the Pod is considered eligible to receive traffic.
Events That Fall Outside Health Scope
Certain events, such as the scheduler's initial placement decision or a controller's later decision to scale down a Deployment, are not health signals and fall outside the narrower scope of Pod health monitoring, even though they remain within the broader Pod lifecycle scope, since they pertain to placement and desired state rather than the ongoing correctness of a running Pod.
Interaction With Controller-Level Lifecycles
Pod Lifecycle Nested Within Controller Lifecycle
A single Pod's lifecycle, from creation to deletion, is typically nested within the much longer lifecycle of the controller that manages it. A Deployment may persist across dozens of individual Pod lifecycles as Pods are replaced during updates, scaling events, or failures, meaning the Pod lifecycle scope describes one instance's journey rather than the ongoing existence of the workload as a whole.
Grace Periods Spanning Multiple Scopes
The termination grace period, while primarily a Pod-scoped concept enforced by the kubelet, is also referenced by controller-level logic, such as a StatefulSet waiting for a Pod's graceful termination to complete before creating its ordinal replacement, illustrating how Pod-level lifecycle scope and controller-level orchestration scope interact at key transition points.