Prepare intervention for a stalled Kubernetes StatefulSet rollout

Ordered readiness can protect sequencing while also preventing automatic progress past a bad revision.

Source facts

Kubernetes StatefulSets use stable Pod identities and support ordered rollout behavior. With the default OrderedReady management policy, a rolling update can enter a broken state requiring manual intervention. The documentation explains that reverting a bad Pod template may also require deleting Pods already attempted with that configuration before the rollout can proceed normally.

Source: Kubernetes documentation — StatefulSets.

Applicability

Review recovery from a StatefulSet rolling update that stops at a Pod which never becomes Running and Ready.

DSE recommendation

DSE recommends writing the recovery sequence before updating a stateful service. Identify the ordinal being changed, the data-compatibility boundary, the accepted predecessor configuration, and the application health signal that allows the next step. A readiness failure should trigger investigation rather than pressure to bypass ordered safety controls. Keep a clear distinction between replacing a Pod and destroying a claim. Have the service owner review any rollback that could encounter data written by the newer application version.

Verification

On a disposable StatefulSet, observe an intentionally unready revision and the effect of reverting the template. Follow the documented recovery sequence, inspect Pod revisions and readiness, and verify application data through its supported checks. Record the exact intervention required for the installed configuration. Retain the bad and reverted template revisions and the affected ordinal list. Require explicit approval for each intervention in the exercise, and keep persistent-data disposition outside a Pod-replacement instruction.

Official reference

Kubernetes documentation — StatefulSets. Reviewed October 20, 2026.