The status field of a Kubernetes API object reports the last observed state of what that object represents. Most objects have both a spec, which describes the desired state, and a status, which lets you check what has actually been observed. A new Pod manifest can omit status; it appears when you create the object and read it back from the API. section 4.1.2 section 4.2.1 section 5.2.1
Controllers read an object’s spec, work to bring the cluster toward that desired state, and report the observed state in status. When you request an object from the API, you receive the whole object, including its status—not just the status field. section 4.1.2 section 4.4
Inspect a node’s status
Run `kubectl get node kind-control-plane -o yaml` and find `status:`. A Node’s status can include addresses, resource capacity, conditions, cached container images, and operating-system information. To focus on conditions, run `kubectl get node <name> -o json | jq .status.conditions`. section 4.2.1 section 4.2.3
Read conditions when a node behaves unexpectedly:
- `Ready` indicates whether it can accept new pods. `MemoryPressure`, `DiskPressure`, and `PIDPressure` indicate resource problems. section 4.2.3
- Each condition has a type and a `True`, `False`, or `Unknown` status; a reason, message, and timestamps can add context. section 4.2.3
Status fields vary by object kind. A Pod’s status includes its phase, conditions, and individual container states, which help you understand its life cycle. Not every object has a status section: Event objects, for example, have neither spec nor status. section 6.1 section 4.3.2
