Tables compress state into a word: Running, 1/1, Available. Behind each word is a list of conditions, and the list carries the reason.

The shape

kubectl get deploy market-api -o jsonpath='{.status.conditions}'

- type: Available
  status: "False"
  reason: MinimumReplicasUnavailable
  message: Deployment does not have minimum availability.
  lastTransitionTime: "2026-10-19T09:00:12Z"
- type: Progressing
  status: "True"
  reason: ReplicaSetUpdated
  message: ReplicaSet "market-api-7b6c4d5f9" is progressing.

Every condition has a type, a status of True, False or Unknown, a reason in CamelCase meant for machines, a message meant for you, and the time it last changed.

Where they appear

A Pending Pod has PodScheduled=False with reason Unschedulable and the full scheduler message. A Pod that is Running but not Ready has Ready=False with reason ContainersNotReady. A Deployment whose rollout is stuck has Progressing=False with reason ProgressDeadlineExceeded.

Reading one

kubectl get pod market-api-7b6c-x2k4p -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="Ready")].status}{"\n"}{end}'
kubectl describe deploy market-api | grep -A4 Conditions

The filter from the JSONPath lesson picks one condition out of the list. describe prints them as a table for Deployments and Nodes.

Waiting on one

kubectl wait --for=condition=Available deploy/market-api --timeout=60s
kubectl wait --for=condition=Ready pod -l app=market-api --timeout=30s

kubectl wait blocks until the condition is True or the timeout passes, with exit code 1 on timeout. It is how a script knows a rollout finished before it runs the next step.