9.5 Kubernetes Pod Startup Lifecycle

Kubernetes Pod Startup Lifecycle is the sequence of node-local steps that occur after the kubelet takes ownership of a Pod and before its application containers are considered fully running and ready, encompassing volume preparation, image retrieval, init container execution, and the initial evaluation of startup probes. This portion of the broader Pod lifecycle is entirely coordinated by the kubelet in conjunction with the container runtime on the assigned node.

Preparatory Steps Before Any Container Runs

Volume Setup

Before starting any container, the kubelet resolves and prepares every volume referenced in the Pod specification, which may include attaching a persistent volume through the appropriate storage driver, creating an emptyDir on local storage, or projecting ConfigMap and Secret contents into files the containers will read at defined mount paths.

Pull Secrets and Image Retrieval

The kubelet resolves any imagePullSecrets associated with the Pod's service account or specified directly, then instructs the container runtime to retrieve each required image. The imagePullPolicy field determines whether an already-cached image is reused or a fresh pull is always attempted, which affects both startup latency and the risk of drifting away from a previously validated image version.

Init Container Sequence

Ordered, Blocking Execution

Init containers execute strictly in the order they are declared, and the kubelet does not begin the next init container, nor any application container, until the current one has exited successfully. This ordering guarantee makes init containers well suited to expressing setup steps that have explicit dependencies on one another.

Restart Behavior for Failed Init Containers

If an init container exits with a failure and the Pod's restartPolicy is Always or OnFailure, the kubelet restarts that specific init container rather than moving on, following the same backoff behavior applied to regular container restarts, ensuring the Pod does not proceed into an inconsistent state with incomplete initialization.

Application Container Launch

Concurrent Container Start

Once all init containers have completed, the kubelet starts all application containers within the Pod concurrently rather than sequentially, since these containers are generally expected to run together for the duration of the Pod rather than execute in a dependent order.

postStart Lifecycle Hook

If a container defines a postStart hook, it is invoked immediately after the container is created, running concurrently with the container's main process rather than blocking its start. However, the container is not considered fully started until the postStart hook itself completes, and a failing hook causes the container to be treated as unhealthy.

Startup Probe Gating

Purpose of the Startup Probe

A startup probe, when configured, is evaluated repeatedly until it succeeds or exceeds its configured failure threshold, and its purpose is to accommodate containers whose applications require a longer, variable initialization period than would otherwise be tolerated by a standard liveness probe.

Suppression of Other Probes

While a startup probe is in progress and has not yet succeeded, both the liveness and readiness probes for that container are disabled, preventing the kubelet from prematurely restarting a slow-starting container or marking it as ready before its startup probe confirms it has actually finished initializing.

Transition Into Steady-State Operation

Marking the Container as Started

Once the startup probe succeeds, or immediately if no startup probe is defined, the container's started status field becomes true, and the kubelet begins evaluating the regular liveness and readiness probes on their configured intervals, formally concluding the startup lifecycle and transitioning the container into ongoing steady-state health monitoring.

Pod-Level Readiness Aggregation

The Pod as a whole is only marked ready, reflected in its Ready condition, once every container that requires readiness has reported a passing status, which is the final gate determining whether the Pod becomes eligible to receive traffic through any Services that select it.