Pod Conditions [page]deterministic

In Kubernetes, many objects have _conditions_. Conditions are markers for some aspect of the actual state of the thing the object represents. Pods have conditions, and Kubernetes Pod conditions are an important aspect of how controllers (and people doing troubleshooting) can understand the health of a Pod.

A Pod's [phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) provides a high-level summary of where the Pod is in its lifecycle, but a single value cannot capture the full picture. For example, a Pod may be in the `Running` phase but not yet ready to serve traffic. Pod conditions complement the phase by tracking multiple aspects of the Pod's state independently, such as whether it has been scheduled, whether its containers are ready, whether a resize is in progress, or whether the Pod is about to be disrupted due to a [taint](#gloss:taint).

## Structure of a Pod condition

A Pod's status includes an array of [PodConditions](/docs/reference/generated/kubernetes-api//#podcondition-v1-core) that indicate whether the Pod has passed certain checkpoints.

Each element of the PodCondition array has the following fields:

| Field name | Description | |:---------------------|:-----------------------------------------------------------------------------------------------------| | `type` | Name of this Pod condition. | | `status` | Indicates whether that condition is applicable, with possible values `"True"`, `"False"`, or `"Unknown"`. | | `lastProbeTime` | Timestamp of when the Pod condition was last probed. | | `lastTransitionTime` | Timestamp for when the Pod last transitioned from one status to another. | | `reason` | Machine-readable, UpperCamelCase text indicating the reason for the condition's last transition. | | `message` | Human-readable message indicating details about the last status transition. | | `observedGeneration` | The `.metadata.generation` of the Pod at the time the condition was recorded. See [Pod generation](/docs/concepts/workloads/pods/#pod-generation). |

## Built-in Pod conditions {#built-in-pod-conditions}

Kubernetes manages the following Pod conditions:

[Lifecycle conditions](#lifecycle-pod-conditions): set as a Pod progresses through its lifecycle, roughly in this order: `PodScheduled`, `PodReadyToStartContainers`, `Initialized`, `ContainersReady`, `Ready`.

[Other conditions](#other-pod-conditions): set in response to specific operations or events: `DisruptionTarget`, `PodResizePending`, `PodResizeInProgress`.

In addition to the built-in conditions above, you can define custom conditions using [Pod readiness gates](#enhanced-pod-readiness).

## Lifecycle Pod conditions {#lifecycle-pod-conditions}

As a Pod progresses through its lifecycle, the kubelet sets the following conditions roughly in this order:

1. `PodScheduled`: the Pod has been scheduled to a node. 1. `PodReadyToStartContainers`: the Pod sandbox has been successfully created and networking configured. The sandbox and network are set up by the [container runtime](#gloss:container-runtime) and [CNI](#gloss:cni) plugin. 1. `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/) have completed successfully. For a Pod without init containers, this is set to `True` before sandbox creation. 1. `ContainersReady`: all containers in the Pod are ready. A container's readiness is determined by its [readiness probe](/docs/concepts/workloads/pods/probes/#readiness-probe), if configured. 1. `Ready`: the Pod is able to serve requests and should be added to the load balancing pools of all matching [Services](/docs/concepts/services-networking/service/). Pods that are not `Ready` are remov …(trimmed)