StatefulSet Ordered Rollout
Why does a StatefulSet start its Pods strictly one at a time? Under the default podManagementPolicy of OrderedReady, ordinal 0 has to be Running and Ready before ordinal 1 is even created, which is what lets a clustered system elect a primary before any follower appears. Each Pod also keeps a stable name and its own claim across rescheduling, and under that same policy a scale-down reverses the order, highest ordinal first, so ordinal 0 is the last to go.
Play the animation 5 steps, animated, best on a wide screen
StatefulSet Ordered Rollout, step by step
-
The controller starts at ordinal 0 and requests PVC data-web-0 before the Pod. That name joins the template name to the Pod name, so the same ordinal gets that disk back whenever its Pod is replaced. Pod web-0 follows, carrying an identity that sticks to it wherever it is rescheduled, and once it is Running and Ready the ordinal is done.
Play from step 1 -
Ordinal 1 is not created while ordinal 0 is not Running and Ready. The controller reads that status off its watch on the API, and the answer is what opens the gate. This is spec.podManagementPolicy at its default of OrderedReady, where a replica that never turns Running and Ready holds up every ordinal behind it. Parallel lifts the gate, but the field is immutable.
Play from step 2 -
With the gate open the same two calls run for ordinal 1. PVC data-web-1 is requested before Pod web-1, and web-1 mounts a claim of its own rather than sharing the one web-0 holds. Ordinal 1 becoming Running and Ready is what opens the gate in front of ordinal 2, and nothing about web-0 is touched.
Play from step 3 -
Ordinal 2 clears the last gate and Pod web-2 is created with claim data-web-2. All three replicas are Running and Ready, each holding an ordinal, a name and a disk of its own, so they are not interchangeable the way Deployment replicas are. The ordering is the bootstrap order as well, because ordinal 0 was Ready before ordinal 1 existed.
Play from step 4 -
Dropping the spec to 2 replicas reverses the order. The controller removes the highest ordinal first, so web-2 goes and web-0 stays. The claim is not deleted with the Pod, because persistentVolumeClaimRetentionPolicy.whenScaled defaults to Retain, so data-web-2 stays and scaling back up hands ordinal 2 the same disk. A scale-down reaches ordinal 0 only when the set is taken all the way down.
Play from step 5