Kubernetes Pod Startup Lifecycle

Kubernetes Pod Startup Lifecycle is the phase of a Pod's existence that begins once the kubelet has accepted a bound Pod and ends once every container is running and, where configured, reporting ready. This phase covers sandbox creation, volume mounting, image pulling, and the ordered execution of init and application containers, and it is the segment most directly observable through the Pending-to-Running phase transition.

Sandbox and Network Setup

Pod Sandbox Creation

The kubelet instructs the container runtime to create a Pod sandbox before any container starts. The sandbox establishes the shared network namespace, so every container in the Pod will resolve localhost to the same interface and share a single Pod IP address.

kubectl get pod startup-lifecycle-example -o jsonpath='{.status.podIP}'

Volume Provisioning

Any volumes referenced in the PodSpec, ConfigMaps, Secrets, emptyDir, or PersistentVolumeClaims, must be attached and mounted into the sandbox before dependent containers can start, since a container referencing an unavailable volume mount cannot be created.

Image Resolution

Pull Policy Evaluation

For each container, the kubelet evaluates imagePullPolicy to decide whether to use a cached local image or pull fresh: Always forces a pull on every startup, IfNotPresent reuses a cached image when available, and Never fails if the image is not already present locally.

containers:
  - name: app
    image: registry.example.com/app:1.0.0
    imagePullPolicy: IfNotPresent

Pull Failures and Backoff

A failed pull surfaces as ErrImagePull and then, on repeated failure, ImagePullBackOff, with the kubelet applying exponential backoff between retry attempts rather than retrying immediately in a tight loop.

Init Container Execution

Strict Sequential Ordering

Init containers execute one at a time, in the order declared, and each must exit successfully before the next begins. If an init container fails, the kubelet retries it according to the Pod's restartPolicy, and no application container starts until every init container has completed.

initContainers:
  - name: fetch-config
    image: registry.example.com/config-fetcher:1.0.0
  - name: migrate-schema
    image: registry.example.com/migrator:1.0.0

Resource Accounting During Init

Init containers are not scheduled concurrently, so the node only needs to satisfy the resource requests of the largest single init container, or the sum of application container requests, whichever is greater, when reserving capacity for the Pod.

Application Container Startup

Parallel Start

Once init containers finish, application containers typically start together rather than sequentially, since they are not ordered relative to one another by default.

Startup Probe Gating

If a startupProbe is defined, liveness and readiness probes are suppressed until it succeeds, giving slow-initializing applications room to complete their own internal startup sequence without being killed by an impatient liveness check.

containers:
  - name: app
    startupProbe:
      httpGet:
        path: /startupz
        port: 8080
      failureThreshold: 30
      periodSeconds: 2

Reaching the Running Phase

Phase and Condition Transitions

status.phase moves from Pending to Running once every container has started, marking the Initialized condition true. ContainersReady and Ready remain false independently until readiness probes succeed, meaning a Pod can be Running while still ineligible to receive traffic.

Startup Lifecycle Diagram

Each stage in this sequence is a potential point of prolonged Pending status, and diagnosing a slow or stuck Pod startup generally means walking through these stages in order to identify where progress stalled.