stateful-workloads

Stateful Workloads

Kubernetes and most modern orchestration platforms were designed around the assumption that any instance can be killed and replaced without consequence. That assumption is exactly wrong for stateful systems — a database pod is not interchangeable with a fresh one, because the data lives on that one pod's storage and nowhere else until you've deliberately made it otherwise.

Running state on infrastructure built for stateless workloads works, but only if you actively undo the platform's default assumptions: give the workload stable identity, give it storage that outlives the pod, and give it a recovery story that does not depend on the pod ever coming back the way it left.

The platform will happily reschedule, evict, and recreate your stateful pod exactly like a stateless one — unless you've told it not to, in writing, ahead of time.

1. Use StatefulSets for identity, not for magic

A StatefulSet gives each pod a stable name, stable network identity, and a stable claim on its own volume across restarts — that is the entire value it adds over a Deployment. It does not make the workload stateful-aware, backed up, or replicated on its own.

• Use ordinal, stable pod names and DNS when the stateful system needs to know which member is which — cluster formation, primary election, and shard assignment all depend on identity that a Deployment's interchangeable pods cannot provide.
• Do not expect a StatefulSet to handle replication, quorum, or failover logic — that is the stateful application's own responsibility, or an operator's (see operators-and-crds) built specifically for that system.
• Scale StatefulSets deliberately, not automatically — adding or removing a stateful member usually requires a rebalance or resync that autoscaling logic knows nothing about.

Done when: each stateful pod has a stable identity the application actually depends on, not just a default StatefulSet used out of habit for something that could be a Deployment.