What Are the Update Strategies for StatefulSets?

Detailed Answer

Updating stateful applications requires more caution than stateless ones. A bad update to a database cluster can cause data loss or split-brain scenarios. StatefulSets offer two update strategies to give you control over how changes are rolled out.

RollingUpdate (Default)

The RollingUpdate strategy updates Pods one at a time in reverse ordinal order. For a StatefulSet with replicas 0, 1, and 2, the update order is: 2 → 1 → 0.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  replicas: 3
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  serviceName: "redis-headless"
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
        - name: redis
          image: redis:7.2
          ports:
            - containerPort: 6379
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

How it works step by step:

1. Kubernetes terminates redis-2 and waits for it to fully stop
2. A new redis-2 Pod is created with the updated spec
3. Kubernetes waits until redis-2 is Running and Ready
4. Only then does it proceed to redis-1
5. Finally, redis-0 is updated

If any Pod fails to become Ready, the rollout stops. This prevents a bad image from taking down the entire cluster.

Using Partitions for Canary Rollouts

The partition field is a powerful feature unique to StatefulSets. It specifies an ordinal boundary — only Pods with an ordinal greater than or equal to the partition value are updated.

updateStrategy:
  type: RollingUpdate
  rollingUpdate:
    partition: 2

With partition: 2 and replicas: 3, only redis-2 gets the new spec. Pods redis-0 and redis-1 retain the old spec. This lets you:

1. Test the update on a single replica
2. Verify it works correctly
3. Lower the partition to 1 to include redis-1
4. Finally set partition to 0 to complete the rollout

# Start canary — update only Pod 2
kubectl patch statefulset redis -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":2}}}}'

# Update the image
kubectl set image statefulset/redis redis=redis:7.4

# Verify Pod 2 is healthy, then roll to all Pods
kubectl patch statefulset redis -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":0}}}}'

OnDelete Strategy

The OnDelete strategy tells Kubernetes to not automatically update Pods. Instead, you must manually delete each Pod, and the controller recreates it with the new spec.

updateStrategy:
  type: OnDelete

This gives you complete control:

# Update the StatefulSet spec
kubectl set image statefulset/redis redis=redis:7.4

# Pods are still running the old image
kubectl get pods -l app=redis -o jsonpath='{.items[*].spec.containers[0].image}'
# redis:7.2 redis:7.2 redis:7.2

# Manually update one Pod at a time
kubectl delete pod redis-2
# Wait for it to come back healthy
kubectl delete pod redis-1
# Wait for it to come back healthy
kubectl delete pod redis-0

Choosing a Strategy

| Scenario | Recommended Strategy | |---|---| | Standard updates with safety | RollingUpdate (default) | | Canary testing on stateful workloads | RollingUpdate with partition | | Databases requiring manual failover before update | OnDelete | | Highly sensitive production systems | OnDelete | | Operator-managed workloads | Depends on operator implementation |

Key Difference from Deployments

Deployments maintain a revision history and support kubectl rollout undo. StatefulSets do not have this feature. To roll back, you must update the StatefulSet spec to the previous configuration and let the update strategy apply the change.