Scaling Up: Patience First
Unlike Deployments, which create and delete Pods in parallel as fast as possible, StatefulSets are methodical and sequential. This is critical for distributed systems that must initialize in a specific order.
Scaling from 0 to 3 replicas:
Create app-0 → Wait for app-0 to be Ready → Create app-1 → Wait for app-1 to be Ready → Create app-2
This ordering matters for databases. In a typical setup, app-0 is the primary. It must be fully initialized and ready before replicas app-1 and app-2 start up and attempt to connect to it for initial data synchronization.
Scaling down from 3 to 1 replica:
Termination happens in reverse ordinal order:
Terminate app-2 → Wait for full shutdown → Terminate app-1 → app-0 remains
This ensures replicas are removed before the primary, preventing a situation where the primary is killed while replicas are still trying to replicate from it.
Rolling Updates
StatefulSets support rolling updates via the updateStrategy field. The default strategy is RollingUpdate, which updates Pods from the highest ordinal down to 0, one at a time, waiting for each Pod to become Ready before proceeding. This means app-2 is updated first, then app-1, then app-0 (the primary) last — minimizing risk.
A key advanced feature is the partition field within RollingUpdate. Setting partition: 2 means only Pods with ordinal index ≥ 2 will be updated when you change the Pod template. Pods app-0 and app-1 keep the old version. This enables canary deployments for stateful workloads: roll out a new database version to one replica first, validate it, then lower the partition to update the rest.