Kubernetes Container State Progression

Kubernetes Container State Progression is the sequence of transitions an individual container within a Pod moves through over its execution history, as tracked by the kubelet and surfaced in status.containerStatuses[].state and .lastState. Unlike Pod phase, which is a single coarse value for the whole Pod, container state progression is tracked independently per container and can cycle repeatedly within the lifetime of a single Pod object through restarts.

The Three States Revisited as a Cycle

Waiting to Running

Every container begins in Waiting, the state it occupies while its image is being pulled or its dependencies (such as a completed init container) are not yet satisfied. Once the runtime successfully starts the container process, state transitions to Running, recording startedAt.

kubectl get pod state-progression-example -o jsonpath='{.status.containerStatuses[0].state}'

Running to Terminated

A Running container transitions to Terminated when its process exits, whether due to normal completion, an unhandled error, or an external kill signal such as an OOM event. The Terminated state block records exitCode, reason, startedAt, and finishedAt.

state:
  terminated:
    exitCode: 1
    reason: Error
    startedAt: "2026-07-18T10:02:11Z"
    finishedAt: "2026-07-18T10:04:47Z"

The Restart Loop

Terminated Back to Waiting

If the Pod's restartPolicy permits it, a Terminated container does not stay terminated; the kubelet moves it back to Waiting with a reason of CrashLoopBackOff if this is a repeated failure, applying an exponential backoff delay before actually attempting the restart, at which point state transitions to Running again.

lastState Preserves History

Because state only reflects the current status, lastState retains a snapshot of the previous terminated state, allowing operators to inspect why the most recent restart occurred even after the container is running again.

lastState:
  terminated:
    exitCode: 137
    reason: OOMKilled
state:
  running:
    startedAt: "2026-07-18T10:10:00Z"
restartCount: 5

restartCount as the Progression Counter

What Increments It

restartCount increments by exactly one each time the container completes a full Terminated-to-Running cycle. It does not increment for the very first start, only for subsequent restarts, making it a direct measure of instability for a given container within its current Pod.

Backoff Growth

The delay between successive restart attempts grows exponentially, capped at a maximum interval, specifically to prevent a persistently crashing container from consuming excessive node resources through rapid restart attempts.

Independent Progression Across Containers in One Pod

No Cross-Container Synchronization

Each container's state machine advances independently. One container in a multi-container Pod can be deep into a CrashLoopBackOff cycle while a sibling container remains stably Running, since the kubelet manages restart decisions per container rather than per Pod.

containerStatuses:
  - name: app
    restartCount: 0
    state:
      running: {}
  - name: sidecar
    restartCount: 8
    state:
      waiting:
        reason: CrashLoopBackOff

State Progression Diagram

This cyclical progression, distinct from the Pod's own linear phase progression, is what makes restartCount and lastState the primary diagnostic fields for understanding container-level instability without needing to inspect Pod-level events.