Networking Identity Ordinality Other Requirements Stable and long-lived storage, networking, identity, and ordinality are among the col‐ lective needs of clustered stateful applications. Managing stateful applications also carries many other specific requirements that vary case by case. For example, some applications have the notion of a quorum and require a minimum number of instan‐ ces to be always available; some are sensitive to ordinality, and some are fine with parallel Deployments; some tolerate duplicate instances, and some don’t. Planning for all these one-off cases and providing generic mechanisms is an impossible task and that’s why Kubernetes also allows creating CustomResourceDefinitions and  Operators for managing stateful applications. Operators are explained in Chapter 23. As you can see from the preceding requirements, clustered stateful applications depend heavily on every instance having a hold of its long-lived storage and network identity. That is because in a stateful application, every instance is unique and knows its own identity, and the main ingredients of that identity are the long-lived storage and the networking coordinates. To this list, we could also add the identity/name of the instance (some stateful applications require unique persistent names), which in Kubernetes would be the Pod name. A Pod created with ReplicaSet would have a ran‐ dom name and would not preserve that identity across a restart. Similar to the storage requirements, a distributed stateful application requires a stable network identity. In addition to storing application-specific data into the storage space, stateful applications also store configuration details such as hostname and con‐ nection details of their peers. That means every instance should be reachable in a pre‐ dictable address that should not change dynamically as is the case with Pod IP addresses in a ReplicaSet. Here we could address this requirement again through a workaround: create a Service per ReplicaSet and have  replicas=1 . However, manag‐ ing such a setup is manual work, and the application itself cannot rely on a stable hostname because it changes after every restart and is also not aware of the Service name it is accessed from. In addition to a unique and long-lived identity, the instances of clustered stateful applications have a fixed position in the collection of instances. This ordering typi‐ cally impacts the sequence in which the instances are scaled up and down. However, it can also be used for data distribution or access and in-cluster behavior positioning such as locks, singletons, or masters. Problem | 89