What Are StatefulSet Pod Management Policies?

Detailed Answer

The podManagementPolicy field controls how a StatefulSet creates, scales, and deletes its Pods. It determines whether operations happen sequentially or in parallel.

OrderedReady (Default)

With OrderedReady, Pods are managed strictly in order:

• Creation: Pod-0 → Pod-1 → Pod-2 (each must be Ready before the next starts)
• Deletion: Pod-2 → Pod-1 → Pod-0 (each must be fully terminated before the next is stopped)
• Scaling up: New Pods are added in ascending order
• Scaling down: Pods are removed in descending order

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: zookeeper
spec:
  serviceName: "zk-headless"
  replicas: 3
  podManagementPolicy: OrderedReady
  selector:
    matchLabels:
      app: zookeeper
  template:
    metadata:
      labels:
        app: zookeeper
    spec:
      containers:
        - name: zookeeper
          image: zookeeper:3.9
          ports:
            - containerPort: 2181
              name: client
            - containerPort: 2888
              name: server
            - containerPort: 3888
              name: leader-election
          env:
            - name: ZOO_MY_ID
              valueFrom:
                fieldRef:
                  fieldPath: metadata.labels['apps.kubernetes.io/pod-index']
          resources:
            requests:
              cpu: "250m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"

ZooKeeper is a perfect example of why OrderedReady matters — the first node must initialize the ensemble before others can join.

Parallel

With Parallel, all Pods are created or deleted simultaneously, without waiting for each to reach a Ready state:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: worker
spec:
  serviceName: "worker-headless"
  replicas: 10
  podManagementPolicy: Parallel
  selector:
    matchLabels:
      app: worker
  template:
    metadata:
      labels:
        app: worker
    spec:
      containers:
        - name: worker
          image: myapp/worker:v1.5
          volumeMounts:
            - name: scratch
              mountPath: /data
          resources:
            requests:
              cpu: "500m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "512Mi"
  volumeClaimTemplates:
    - metadata:
        name: scratch
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 50Gi

In this example, 10 worker Pods are created simultaneously. Each gets its own persistent volume for scratch space, but they don't depend on each other during startup.

Behavior Comparison

| Operation | OrderedReady | Parallel | |---|---|---| | Initial creation | Sequential (0 → N) | All at once | | Scale up | Sequential, new Pods only | All new Pods at once | | Scale down | Reverse sequential | All excess Pods at once | | Delete StatefulSet | Reverse sequential | All at once | | Pod failure | Blocks subsequent operations | No blocking | | Update strategy | Unaffected | Unaffected |

When to Use Parallel

Choose Parallel when your application:

• Does not have initialization dependencies between Pods
• Needs to start quickly (launching 10+ Pods sequentially is slow)
• Uses StatefulSet purely for stable identity and per-Pod storage
• Can handle peers joining in any order

Common use cases:

• Independent ML training workers with per-Pod GPUs and storage
• Batch processing Pods that need persistent scratch space
• Cache instances that independently warm up

When to Use OrderedReady

Choose OrderedReady (default) when your application:

• Has a primary/secondary architecture (databases)
• Requires leader election during startup (ZooKeeper, etcd)
• Has a bootstrap sequence where Pod-0 initializes the cluster
• Needs graceful removal of secondaries before the primary

Important: Immutability

The podManagementPolicy field is immutable after creation. If you need to change it:

# You must delete and recreate the StatefulSet
# Use --cascade=orphan to preserve running Pods
kubectl delete statefulset worker --cascade=orphan

# Recreate with the new policy
kubectl apply -f worker-statefulset-parallel.yaml

Using --cascade=orphan deletes the StatefulSet object without deleting its Pods. The new StatefulSet adopts the orphaned Pods, minimizing downtime.