Distributed stateful applications require features such as persistent identity, networking, storage, and ordinality. The Stateful Service pattern describes the StatefulSet primitive that provides these building blocks with strong guarantees ideal for the management of stateful applications.
So far we have seen many Kubernetes primitives for creating distributed applications: containers with health checks and resource limits, Pods with multiple containers, dynamic cluster-wide placements, batch jobs, scheduled jobs, singletons, and more. The common characteristic among all these primitives is the fact that they treat the managed application as a stateless application composed of identical, swappable, and replaceable containers and comply with The Twelve-Factor App principles.
While it is a significant boost to have a platform taking care of the placement, resiliency, and scaling of stateless applications, there is still a large part of the workload to consider: stateful applications in which every instance is unique and has long-lived characteristics.
In the real world, behind every highly scalable stateless service is a stateful service typically in the shape of some data store. In the early days of Kubernetes when it lacked support for stateful workloads, the solution was placing stateless applications on Kubernetes to get the benefits of the cloud-native model, and keeping stateful components outside the cluster, either on a public cloud ...