CHAPTER 11 Stateful Service Problem 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, resil‐ iency, 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 or on-premises hardware, managed with the traditional noncloud-native mechanisms. Considering that every enterprise has a multitude of stateful workloads (legacy and modern), the lack of sup‐ port for stateful workloads was a significant limitation in Kubernetes, which was known as a universal cloud-native platform. Distributed stateful applications require features such as persistent identity, network‐ ing, 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. 87