✦ For everyone, free.

Practical knowledge for real and everyday life

Home

10.22 Kubernetes Workload Status Conditions

Kubernetes Workload Status Conditions track workload health and state, showing readiness and lifecycle status in the cluster.

Kubernetes Workload Status Conditions is the standardized reporting pattern used across Deployments, Jobs, and other workload controllers to expose specific, named aspects of their current health and progress through a conditions array in their status, providing a consistent, machine-readable way to observe controller-level state beyond simple aggregate counts.


Structure of a Condition Entry

Common Fields Across Workload Types

Every workload condition entry, regardless of which controller type reports it, follows a common structure including a type identifying which specific aspect of state it describes, a status of True, False, or Unknown, along with lastTransitionTime, reason, and message fields providing timing and explanatory context.

Independence Between Multiple Conditions

Because each condition type is tracked and updated independently, a single workload object can simultaneously report multiple conditions in different states, such as a Deployment reporting Progressing as true while Available remains false during an early stage of a rollout before enough new Pods have become ready.


Deployment-Specific Conditions

Progressing

The Progressing condition indicates whether a Deployment's rollout is actively making forward progress, whether that progress consists of new Pods becoming available or old Pods being successfully scaled down, and transitions to false with a failure reason if no progress is observed within the configured progressDeadlineSeconds.

Available

The Available condition indicates whether the Deployment currently has at least the minimum required number of Pods that are both ready and have satisfied any configured minReadySeconds duration, representing a snapshot of current serving capacity independent of whether a rollout is still in progress.

ReplicaFailure

The ReplicaFailure condition surfaces persistent failures in creating the Pods needed to satisfy the Deployment's desired replica count, such as those caused by exceeded resource quotas or repeated admission control rejections, distinguishing a structural inability to create Pods from an ordinary in-progress rollout.


Job-Specific Conditions

Complete

The Complete condition indicates that a Job has successfully satisfied its completion criteria, whether measured through a fixed completion count or the completion of all necessary work under a work queue pattern, and represents a permanent terminal success state.

Failed

The Failed condition indicates that a Job has exhausted its retry budget, exceeded its active deadline, or triggered an immediate-fail rule under its pod failure policy, representing a permanent terminal failure state from which the Job will not recover without external intervention.

Suspended

The Suspended condition reflects whether a Job has been paused through its suspend field, distinguishing a deliberately halted Job, which retains its accumulated progress and can be resumed later, from one that is failed or still actively working toward completion.


Practical Use of Conditions in Automation

Programmatic Health Checks

Because conditions follow a consistent, typed structure, automation systems and monitoring tools can reliably check for specific condition types and statuses across many workload objects using the same logic, rather than needing to parse and interpret free-form status text unique to each controller type.

Distinguishing Transient From Persistent States

By examining lastTransitionTime alongside the current condition status, an operator or automated system can distinguish a condition that has just changed, and may resolve shortly, from one that has remained in a problematic state for an extended period, informing whether alerting or intervention is warranted.


Conditions as a Layer Above Simpler Status Fields

Complementing Rather Than Replacing Aggregate Counts

Conditions do not replace simpler status fields such as replica counts or succeeded and failed Pod counts; rather, they provide an additional, more semantically rich layer of interpretation on top of those raw counts, translating numeric state into named, directly actionable signals about the workload's overall health and progress.