Kubernetes Condition Observation

Kubernetes Condition Observation is the focused practice of reading and interpreting the standardized conditions array pattern used throughout the Kubernetes API — on Node, Pod, Deployment, and countless custom resources — each entry describing one specific, named aspect of a resource's health independently from the others, forming a structured alternative to inferring health from a single overall status field.

The Standard Condition Shape

Common Fields Across Resource Types

Regardless of which resource type it appears on, a condition entry typically includes type (a specific named aspect, such as Ready or MemoryPressure), status (True, False, or Unknown), lastTransitionTime (when the condition's status last changed), reason (a short, machine-readable code), and message (a human-readable explanation).

conditions:
- type: Ready
  status: "False"
  lastTransitionTime: "2024-01-15T10:15:00Z"
  reason: KubeletNotReady
  message: "container runtime is down"

Why Status Uses Three Values, Not Two

Unknown exists alongside True and False specifically to represent cases where the controller responsible for the condition cannot currently determine its actual state (a node the control plane has lost contact with, for instance), distinguishing "confirmed healthy," "confirmed unhealthy," and "cannot currently tell" as three genuinely different situations.

Node Conditions

Common Node Condition Types

A Node object reports conditions including Ready (overall kubelet health), MemoryPressure, DiskPressure, PIDPressure, and NetworkUnavailable, each independently indicating a specific resource or connectivity concern that could affect scheduling decisions or workload stability on that node.

kubectl describe node worker-3 | grep -A 10 Conditions

Using Node Conditions for Scheduling Decisions

The scheduler and node controller react to specific node conditions — tainting a node experiencing DiskPressure to discourage new pod scheduling, for instance — meaning condition observation is not purely diagnostic but directly informs cluster behavior in real time.

Pod Conditions

Common Pod Condition Types

A Pod reports PodScheduled, Initialized, ContainersReady, and Ready, roughly in the order they transition to True during a pod's lifecycle, giving a structured way to determine precisely which stage of startup a pod is stuck at rather than only knowing it is not yet Running.

kubectl get pod api-service-7d4f9 -o jsonpath='{.status.conditions}'

Diagnosing Stuck Pods via Conditions

A pod with PodScheduled: True but Initialized: False indicates an init container is failing or still running, while Initialized: True but ContainersReady: False points to the main containers themselves failing to start or pass readiness — condition observation narrows the diagnostic search space considerably compared to only knowing the pod's overall phase.

Custom Resource Conditions

Following the Established Pattern

Well-designed custom resources adopt the same conditions structure for their own status reporting, giving operators and automation a familiar, predictable way to check a custom resource's health without needing resource-specific knowledge of an entirely bespoke status format.

apiVersion: apps.example.com/v1
kind: DatabaseCluster
status:
  conditions:
  - type: Available
    status: "True"
    reason: AllReplicasHealthy
  - type: BackupCurrent
    status: "False"
    reason: BackupOverdue
    message: "last successful backup was 26 hours ago"

Designing Conditions for New Resource Types

When building an operator or custom controller, choosing condition types that map to independently meaningful aspects of health (rather than a single monolithic Healthy condition) gives consumers the same granularity of insight that built-in resources provide, and following naming conventions consistent with existing Kubernetes conditions improves interoperability with generic tooling that already knows how to interpret the standard shape.

Practical Observation Techniques

Filtering for Specific Conditions

kubectl get supports JSONPath filtering to extract a specific condition's status directly, useful for scripting health checks against a particular aspect of a resource rather than parsing the full status output.

kubectl get node worker-3 -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

Watching for Condition Transitions Over Time

Because lastTransitionTime only updates when a condition's status actually changes (not merely when its message is refreshed), tracking this field over time reveals genuine state changes distinct from routine status refreshes, which is useful both for alerting on flapping conditions and for reconstructing a timeline during incident review.