Kubernetes Status Conditions

Read Kubernetes conditions like a pro

Kubernetes objects report their health through an array of status.conditions. Each condition has a type, a status of True, False or Unknown, plus a reason and message. This reference explains the everyday conditions across Pods, Nodes, Deployments, PVCs and Jobs, what each status means, and how to remediate it.

How it works

A condition is a standardised latch describing one aspect of an object’s state. The triad of values matters: True and False are deliberate assertions (for example PodScheduled=True means a node was assigned), while Unknown means the controller could not determine the answer — frequently because the component that reports it went silent.

Conditions also chain. A pod progresses through PodScheduled, then Initialized (init containers done), then ContainersReady, and finally Ready. A failure earlier in that chain blocks the later ones, so always read the first False condition rather than the last. View them with:

kubectl get pod my-pod -o jsonpath='{.status.conditions}'
kubectl describe pod my-pod

The reason and message fields shown by describe are where the actionable detail lives — Unschedulable, ProgressDeadlineExceeded, CrashLoopBackOff and so on.

Tips and examples

• Sort cluster events to see condition transitions in time order:

kubectl get events --sort-by=.lastTimestamp

• For nodes, Ready=Unknown almost always points at the kubelet or node networking rather than the workloads.
• For deployments, watch both Available (enough ready replicas) and Progressing (rollout moving) — a healthy rollout ends with both True.
• Treat node pressure conditions as capacity signals: tune requests/limits, enable autoscaling, or add nodes before the kubelet starts evicting pods.