Kubernetes StatefulSet Status Management

Kubernetes StatefulSet Status Management is the practice of interpreting the specific combination of numeric status fields, replicas, readyReplicas, currentReplicas, updatedReplicas, and collisionCount, that together describe a StatefulSet's precise state, since no single field alone distinguishes between the several distinct conditions a StatefulSet can be in at any given moment.

The Core Status Fields

replicas Versus readyReplicas

status.replicas reports the total number of Pods currently observed for the StatefulSet, while status.readyReplicas reports how many of those are passing their readiness checks; a persistent gap between the two, especially under OrderedReady management, points directly at the blocked-ordinal scenario where a single unready Pod prevents the rest from ever being created.

kubectl get statefulset status-management-example -o jsonpath='{.status.replicas} total, {.status.readyReplicas} ready'

currentReplicas Versus updatedReplicas

status.currentReplicas counts Pods still running the revision identified by status.currentRevision, while status.updatedReplicas counts Pods already running status.updateRevision; together these reveal exactly how far a rolling update has progressed without needing to inspect individual Pod labels directly.

kubectl get statefulset status-management-example -o jsonpath='{.status.currentReplicas} on old, {.status.updatedReplicas} on new'

Interpreting Common Field Combinations

Fully Converged and Healthy

When replicas, readyReplicas, and updatedReplicas are all equal to spec.replicas, and currentRevision equals updateRevision, the StatefulSet has fully converged: every ordinal exists, is ready, and runs the current template.

status:
  replicas: 5
  readyReplicas: 5
  updatedReplicas: 5
  currentRevision: statefulset-abc123
  updateRevision: statefulset-abc123

Mid-Rollout, Healthy Progress

When updatedReplicas is greater than zero but less than replicas, and readyReplicas equals replicas, the StatefulSet is mid-update but every existing Pod, old and new revision alike, is currently healthy, indicating normal, progressing behavior rather than a stall.

Blocked Startup or Update

When readyReplicas is persistently less than replicas (or less than the count expected at the current partition boundary) with no forward movement over an extended observation window, this signals a stuck ordinal requiring the diagnostic descent described in progress-related troubleshooting practice, even though StatefulSet lacks a direct equivalent to Deployment's ProgressDeadlineExceeded condition.

collisionCount as a Rare But Important Signal

Detecting ControllerRevision Naming Collisions

status.collisionCount increments in the rare event the controller's hash-based naming for a new ControllerRevision collides with an existing one, an edge case status management practice monitors for specifically because a non-zero, growing collision count can indicate an underlying issue with the cluster's hash generation rather than being expected behavior.

kubectl get statefulset status-management-example -o jsonpath='{.status.collisionCount}'

Absence of a Deployment-Style Progressing Condition

Why StatefulSet Status Requires More Manual Interpretation

Because StatefulSet does not expose a Progressing condition with explicit reason codes the way Deployment does, status management for StatefulSets relies more heavily on directly comparing the numeric fields above over time, tracking whether updatedReplicas is trending toward replicas or has stalled, rather than reading a single authoritative condition summarizing rollout health.

kubectl get statefulset status-management-example -w

Status Field Interpretation Diagram

Building the habit of reading these fields together, rather than any single one in isolation, is what allows accurate diagnosis of a StatefulSet's actual condition without needing to inspect every individual Pod's status directly for routine health assessment.