Kubernetes Pod Status Model

Kubernetes Pod Status Model is the structured, API-visible representation of a Pod's lifecycle and health, exposed through the status subresource of the Pod object. It aggregates a coarse-grained phase, a set of detailed conditions, per-container status entries, and networking and scheduling metadata into a single view that clients such as kubectl, controllers, and monitoring systems consume to determine what a Pod is currently doing and whether it is functioning correctly.

Pod Phase

The Five Phase Values

status.phase is a coarse summary that can take one of five values: Pending, Running, Succeeded, Failed, or Unknown. It is intentionally low-resolution and does not by itself indicate readiness to serve traffic.

• Pending: the Pod has been accepted by the cluster but one or more containers are not yet running.
• Running: the Pod has been bound to a node and at least one container is running.
• Succeeded: all containers terminated successfully and will not be restarted.
• Failed: all containers terminated, and at least one exited with failure.
• Unknown: the Pod's state cannot be obtained, typically due to a communication failure with the node.

kubectl get pod pod-status-example -o jsonpath='{.status.phase}'

Pod Conditions

Condition Types

status.conditions is an array of typed, timestamped booleans that provide finer-grained detail than phase alone. The standard condition types are:

• PodScheduled: the Pod has been assigned to a node.
• Initialized: all init containers have completed successfully.
• ContainersReady: all containers in the Pod report ready.
• Ready: the Pod is able to serve requests and should be added to matching Service endpoints.

status:
  conditions:
    - type: PodScheduled
      status: "True"
      lastTransitionTime: "2026-07-18T08:55:00Z"
    - type: Initialized
      status: "True"
      lastTransitionTime: "2026-07-18T08:55:04Z"
    - type: ContainersReady
      status: "False"
      reason: ContainersNotReady
      message: "containers with unready status: [app]"
    - type: Ready
      status: "False"

Condition Transition Metadata

Each condition entry carries status (True, False, or Unknown), lastTransitionTime recording when the condition last changed, and optionally reason and message fields that give a machine-readable code and human-readable explanation for the current value.

Networking Fields

podIP and podIPs

Once a Pod is scheduled and its network sandbox is created, status.podIP and the multi-value status.podIPs record the address or addresses assigned by the cluster's CNI plugin, supporting both single-stack and dual-stack (IPv4/IPv6) clusters.

hostIP

status.hostIP records the IP address of the node the Pod is running on, which is distinct from the Pod's own IP and is used for host-networking scenarios and node-level diagnostics.

Quality of Service and Start Time

qosClass

status.qosClass reports the Quality of Service class computed from the Pod's resource requests and limits at admission time, one of Guaranteed, Burstable, or BestEffort. This value is immutable for the life of the Pod object.

startTime

status.startTime records the timestamp at which the kubelet first acknowledged the Pod, serving as the reference point for calculating Pod age and for correlating with container-level startedAt timestamps.

Status Aggregation Flow

Controllers such as ReplicaSets and Deployments, along with the endpoint controller that populates Service backends, read this composite status model rather than inspecting individual containers directly, making it the canonical interface through which the rest of the cluster understands a Pod's health.