✦ For everyone, free.

Practical knowledge for real and everyday life

Home

10.11 Kubernetes StatefulSet Controller

The Kubernetes StatefulSet Controller manages stateful applications by ensuring persistent storage and ordered deployment of pods in a predictable and scalable way.

Kubernetes StatefulSet Controller is the workload controller designed to manage stateful applications requiring stable, unique network identities and persistent storage that survives Pod replacement, distinguishing itself from ReplicaSets and Deployments by preserving ordinal-based Pod identity and enforcing strict, ordered creation and deletion semantics across its managed Pods.


Stable Pod Identity

Ordinal-Based Naming

Each Pod managed by a StatefulSet receives a name derived from the StatefulSet's own name combined with a numeric ordinal, starting at zero, such that a StatefulSet named web produces Pods named web-0, web-1, and so on, with this naming convention preserved consistently even as individual Pods are replaced over time.

Stable Network Identity

Combined with a headless Service, each StatefulSet Pod receives a stable, predictable DNS hostname derived from its ordinal name, allowing other components in the cluster to address a specific Pod instance directly and reliably, rather than relying on a load-balanced virtual IP that could route to any interchangeable replica.


Ordered Pod Management

Sequential Creation

When scaling up, the StatefulSet controller creates Pods one at a time in strict ordinal order, waiting for each Pod to become running and ready before proceeding to create the next, ensuring that Pod web-1 is never created before web-0 has successfully started.

Sequential Termination

When scaling down, Pods are terminated in strict reverse ordinal order, meaning the highest-numbered Pod is removed first, preserving a predictable, ordered reduction that mirrors the ordered creation process rather than removing Pods in an arbitrary or parallel fashion.


Persistent Storage Association

Per-Ordinal PersistentVolumeClaims

Through volumeClaimTemplates, a StatefulSet automatically generates a distinct PersistentVolumeClaim for each Pod ordinal, ensuring that each Pod instance has its own dedicated persistent volume rather than sharing storage with its sibling Pods.

Volume Retention Across Pod Replacement

When a StatefulSet Pod is replaced, whether due to failure or deliberate deletion, its associated PersistentVolumeClaim is retained and reattached to the newly created replacement Pod carrying the same ordinal, preserving access to previously written data despite the Pod object itself being entirely new.


Update Strategies

RollingUpdate With Ordinal Ordering

The default RollingUpdate strategy updates Pods in reverse ordinal order, tearing down and recreating the highest-numbered Pod first and proceeding downward, ensuring updates respect the same ordering discipline applied to scaling operations.

Partitioned Rollouts

The partition field allows a rolling update to be constrained so that only Pods with an ordinal greater than or equal to the partition value are updated, leaving lower-ordinal Pods untouched, a mechanism commonly used to stage or canary a change across a subset of replicas before committing to a full rollout.


PodManagementPolicy

OrderedReady as the Default

Under the default OrderedReady policy, the strict sequential creation and termination behavior described above is enforced, prioritizing predictability and safety for applications sensitive to ordering, such as those forming a cluster with leader election dependent on startup sequence.

Parallel Policy for Independent Replicas

The Parallel policy relaxes this constraint, allowing the controller to create or delete multiple Pods simultaneously without waiting for each to individually reach a ready or terminated state, appropriate for stateful applications whose replicas do not depend on strict startup ordering relative to one another.


Headless Service Requirement

Enabling Direct Pod Addressability

StatefulSets are typically paired with a headless Service, one configured without a cluster IP, which allows DNS queries against the Service name to resolve directly to the individual Pod IP addresses of its members, a prerequisite for the stable per-Pod network identity that distinguishes StatefulSet-managed workloads from stateless alternatives.