Kubernetes StatefulSet Update Control

Kubernetes StatefulSet Update Control is the mechanism through which a StatefulSet applies Pod template changes to already-running, ordinally-identified Pods, governed by spec.updateStrategy and offering a degree of manual, partition-based control not present in the fully automatic rollout model used by Deployments. Because StatefulSet Pods carry persistent identity and storage, update control here is deliberately more conservative and more granular than Deployment rollout control.

RollingUpdate Strategy

Reverse Ordinal Order

The default RollingUpdate strategy replaces Pods strictly in descending ordinal order, highest ordinal first, waiting for each replaced Pod to become Ready before proceeding to the next lower ordinal. This ordering is fixed and not configurable, unlike a Deployment's more flexible surge-based approach.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: update-control-example
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      partition: 0

No Surge, No Parallelism by Default

Unlike a Deployment, a StatefulSet's rolling update does not create extra Pods above the desired count during the transition; each ordinal is updated strictly one at a time, in place, trading update speed for the stronger identity and storage guarantees a StatefulSet provides.

Partitioned Updates

Restricting the Update Window

The partition field defines a threshold ordinal: only Pods with an ordinal greater than or equal to partition are updated when the template changes; Pods below that threshold are left on their prior template version indefinitely, even though the desired template has changed.

spec:
  replicas: 5
  updateStrategy:
    rollingUpdate:
      partition: 3

With this configuration, only web-3 and web-4 are updated; web-0 through web-2 remain on the previous template until the partition value is lowered.

Canary Validation Pattern

Setting a high partition value and updating only the topmost ordinal is a common technique for validating a new version against a single stateful replica before committing to updating the rest, since the partition can simply be lowered incrementally once the canary proves healthy.

kubectl patch statefulset update-control-example -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":0}}}}'

OnDelete Strategy

Fully Manual Replacement

The OnDelete strategy disables automatic propagation of template changes entirely; the controller only creates a Pod using the new template when that specific ordinal's existing Pod is deleted manually, giving an operator complete, Pod-by-Pod control over exactly when each replica transitions.

spec:
  updateStrategy:
    type: OnDelete

kubectl delete pod update-control-example-2

Interaction With Storage During Updates

Volumes Reattach, Not Recreate

Because volumeClaimTemplates bind storage to the ordinal rather than to the specific Pod object, an update-triggered replacement reattaches the existing PersistentVolumeClaim to the new Pod instance automatically, meaning application data survives the update without any explicit migration step.

spec:
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]

Update Control Diagram

This combination of strict ordering, partitioning, and manual override options gives operators the ability to update stateful workloads at exactly the pace and granularity their data-consistency requirements demand, a level of control a Deployment's rollout strategy does not attempt to offer.