A Kubernetes StatefulSet has a field called podManagementPolicy that accepts OrderedReady or Parallel. What does each setting change, and when would you choose Parallel?
answer
- policy affects scaling only, not updates
- OrderedReady = one at a time, wait for Ready
- Parallel = all at once, identity unchanged
- rolling update always reverse-ordinal, sequential
- field is immutable after creation
basics
~20 sOrderedReady (the default) creates Pods one at a time in ordinal order, waiting for each to be Running and Ready, and deletes in reverse one at a time. Parallel starts and stops them all at once. Neither changes rolling-update ordering, which stays sequential.
solid answer
~50 s`podManagementPolicy` controls **scale-up and scale-down only**. - **OrderedReady** (default): Pod N is created only after 0..N-1 are Running and Ready; scale-down deletes the highest ordinal first and waits for full termination before the next. Safe for systems with a bootstrap order — seed node first, followers after — and for quorum systems that must shrink gracefully. - **Parallel**: the controller launches or terminates all required Pods simultaneously. Identity, DNS names and per-ordinal storage are unchanged; only the sequencing is dropped. The important caveat: **Parallel does not affect rolling updates.** Template changes still roll one Pod at a time in reverse ordinal order regardless of this setting. Choose Parallel when members are independent or discover each other dynamically, when startup is slow and a large set would otherwise take many minutes to come up, and when you do not want an unhealthy low ordinal to block every other Pod from starting. Keep OrderedReady when bootstrap order is genuinely load-bearing. The field is immutable after creation.
code
yaml · 20 linesapiVersion: apps/v1
kind: StatefulSet
metadata:
name: shard
spec:
serviceName: shard-hs
replicas: 12
podManagementPolicy: Parallel
selector:
matchLabels:
app: shard
template:
metadata:
labels:
app: shard
spec:
terminationGracePeriodSeconds: 60
containers:
- name: shard
image: example/shard:3.1go deeper
Know the default is OrderedReady and that it starts Pods one at a time in order, while Parallel starts them all together.
Add that the setting covers scaling only, that rolling updates stay sequential, and that the field is immutable.
Reason about which real systems need ordered bootstrap versus which deadlock without Parallel, and how grace periods and readiness gating affect scale-down duration.
Frame it as a bootstrap and failure-domain decision for the platform: how large stateful fleets are brought up, how a single bad ordinal is prevented from stalling recovery, and where an operator should own sequencing instead.
## What the field governs `spec.podManagementPolicy` has exactly two values and affects only the *creation and deletion* of Pods when the StatefulSet scales — including the initial scale from zero to `replicas`. **OrderedReady** is the default and the historic behaviour. On scale-up the controller creates `set-0`, then blocks. It will not create `set-1` until `set-0` is Running and Ready, judged by the Pod's readiness probes. Then `set-1`, and so on. On scale-down it works in reverse: the highest ordinal is deleted and must be fully terminated before the next one is touched. This is why a StatefulSet with a broken readiness probe on Pod 0 never gets past one Pod — a very common first encounter with this behaviour. **Parallel** tells the controller to act on all Pods at once. Scaling from 0 to 10 creates ten Pods immediately; scaling from 10 to 3 deletes seven simultaneously. Everything else about the StatefulSet is unchanged: names are still `set-0` through `set-9`, DNS records are still per-ordinal, storage is still bound per ordinal. ## The caveat people get wrong Parallel does **not** parallelise rolling updates. When you change the Pod template, the update strategy — not the management policy — decides sequencing, and `RollingUpdate` always proceeds one Pod at a time in reverse ordinal order, waiting for each to become Ready. So a 30-replica StatefulSet with Parallel management still takes 30 sequential restarts to roll. Newer Kubernetes versions offer a `maxUnavailable` field under `rollingUpdate` to relax that, but it arrived later and behind a feature gate, so do not assume it is available on an arbitrary cluster. This catches people who set Parallel hoping to speed up deployments. It speeds up *scaling*, not *upgrading*. ## When OrderedReady earns its cost Ordered startup is genuinely required when a system has a designated bootstrap member. Classic examples: a database where Pod 0 initialises the cluster and others join it; a system whose replicas clone from a lower-ordinal peer at first start; anything where two members racing to initialise would produce split state. Ordered *shutdown* matters when a quorum member must hand off or drain before the next leaves — removing three of five members at once destroys quorum, while removing them one at a time may let the cluster rebalance. ## When Parallel is the better choice - **Independent members.** Sharded caches, per-shard indexers, or workers that need identity for addressing but do not form a quorum. Nothing is gained by serialising them. - **Peer discovery that needs everyone present.** Some consensus systems form an initial cluster by contacting all configured members; a strict one-at-a-time start with readiness gated on quorum can deadlock. Parallel plus `publishNotReadyAddresses` on the governing headless Service is the standard bootstrap combination. - **Large or slow sets.** Twenty replicas with a 90-second startup take half an hour to come up under OrderedReady. Parallel does it in 90 seconds. - **Availability during partial failure.** Under OrderedReady, if Pod 0 is unschedulable — no capacity, a stuck volume attachment — nothing else starts, so one problem stalls the whole set's recovery. Parallel confines the problem to the affected ordinal. ## Operational details `podManagementPolicy` is **immutable**. It can only be set at creation; changing it requires deleting the StatefulSet (with `--cascade=orphan` if you want to keep the Pods running) and recreating it so the new object adopts them by label selector. In practice teams choose it deliberately at design time. The mutable fields of a StatefulSet are essentially `replicas`, the Pod `template`, `updateStrategy`, `minReadySeconds`, ordinals, and the PVC retention policy — not this one. Also note that `terminationGracePeriodSeconds` interacts with ordered scale-down: with a long grace period, each Pod's shutdown adds serially to the total, so shrinking a large OrderedReady set can take far longer than expected. And regardless of policy, a StatefulSet never force-deletes Pods on an unreachable node by itself — deliberate safety behaviour that stops two Pods sharing an identity and its storage.
- You set podManagementPolicy to Parallel to speed up deployments, but rollouts are still slow. Why?Because the policy only governs scale-up and scale-down. Template changes are handled by `spec.updateStrategy`, and RollingUpdate always replaces Pods one at a time in reverse ordinal order, waiting for each to be Ready. To speed a rollout you need `maxUnavailable` under rollingUpdate where your cluster version supports it, or the OnDelete strategy with your own orchestration.
- Can you switch an existing StatefulSet from OrderedReady to Parallel?No — podManagementPolicy is immutable. You must delete and recreate the StatefulSet, typically with `--cascade=orphan` so the running Pods and their storage survive the recreation, then let the new StatefulSet adopt them by label selector.
saying these in an interview costs you the question
- Believing Parallel makes rolling updates concurrent.
- Thinking Parallel gives up stable ordinal identity or per-ordinal storage.
- Assuming podManagementPolicy can be patched on a live StatefulSet.
- Treating OrderedReady as always safer without noticing it lets one unhealthy Pod block the entire set.
- Forgetting that readiness probes are what gate OrderedReady progression, so a missing or wrong probe stalls scale-up.