10.13 Kubernetes StatefulSet Update Control

Kubernetes StatefulSet Update Control is the set of configuration options governing how a StatefulSet applies changes to its Pod template across its already-running, ordinal-identified Pods, balancing the need to eventually converge every replica onto an updated configuration against the ordering and staging requirements unique to stateful workloads.

updateStrategy Field

RollingUpdate as the Default Strategy

The RollingUpdate strategy, the default for StatefulSets, automatically updates Pods to match the current Pod template, proceeding in strict reverse ordinal order, meaning the highest-numbered Pod is deleted and recreated first, followed by progressively lower ordinals until every replica reflects the updated template.

OnDelete Strategy

The OnDelete strategy disables automatic propagation entirely; under this strategy, the StatefulSet controller only updates a Pod to the current template when that specific Pod is manually deleted, giving an operator complete manual control over exactly when and in what order each ordinal is updated.

Reverse Ordinal Update Ordering

Highest Ordinal First

Consistent with the StatefulSet's broader ordering discipline, updates under RollingUpdate proceed from the highest ordinal downward, meaning web-2 is updated before web-1, which is updated before web-0, preserving the same directional consistency applied to scale-down operations.

Waiting for Readiness Before Proceeding

The controller waits for each updated Pod to become running and ready before proceeding to update the next lower ordinal, ensuring that an update is not permitted to cascade through the entire StatefulSet if an early update introduces a problem that prevents the updated Pod from becoming healthy.

Partitioned Rollouts

The partition Field

Setting updateStrategy.rollingUpdate.partition to a specific ordinal value restricts automatic updates to only those Pods with an ordinal greater than or equal to that value, leaving all lower-ordinal Pods on their previous template configuration untouched by the rolling update process.

Staged Rollout and Canary Patterns

This partitioning mechanism enables a staged rollout pattern, where an operator can update only the highest few ordinals first, observe their behavior under the new configuration, and then progressively lower the partition value to extend the update to additional ordinals once confidence in the change has been established.

Maximum Unavailable Pods During Update

maxUnavailable for Rolling Updates

The maxUnavailable field, available under the rolling update strategy configuration, allows more than one Pod to be unavailable simultaneously during an update, relaxing the otherwise strictly sequential one-at-a-time update behavior to permit limited parallelism when faster rollout completion is prioritized over maximum caution.

Interaction With Ordinal Ordering

Even when maxUnavailable permits multiple simultaneous updates, the controller still respects ordinal ordering preferences, generally updating from the highest ordinals downward while allowing the specified number of Pods to be in an unavailable, mid-update state at any given time.

Handling Update Failures

Blocked Progression on Unhealthy Pods

If an updated Pod fails to become ready, the rolling update process halts at that ordinal, refusing to proceed to update lower ordinals until the issue is resolved, preventing a single problematic update from being applied cluster-wide before its impact is understood.

Manual Intervention Requirements

Because the controller does not automatically roll back a failed StatefulSet update the way a Deployment can revert to a previous revision through its own built-in rollback mechanism, resolving a stalled StatefulSet rollout typically requires manual intervention, such as correcting the template and allowing the rollout to resume, or manually restoring a previous configuration.