Figure 11-1. A distributed stateful application on Kubernetes Identity Identity  is the meta building block all other StatefulSet guarantees are built upon. Based on StatefulSet’s name, we can get predictable a Pod name and identity. We then use that identity to name PVCs, reach out to specific Pods through headless Services, and more. You can predict the identity of every Pod before creating it and use that knowledge in the application itself if needed. By definition, a distributed stateful application consists of multiple instances that are unique and nonswappable. In addition to their uniqueness, instances may also be related to each other based on their instantiation order/position, and this is where the ordinality  requirement comes in. From a StatefulSet point of view, the only place where ordinality comes into play is during scaling. Pods have names that have an ordinal suffix (starting from 0), and that Pod creation order also defines the order in which Pods are scaled up and scaled down (in reverse order, from  n  – 1 to 0). If we create a ReplicaSet with multiple replicas, Pods are scheduled and started together without waiting for the first one to start successfully (running and ready sta‐ tus as described in Chapter 4,  Health Probe ). The order in which Pods are starting and are ready is not guaranteed. It is the same when we scale down a ReplicaSet (either by Ordinality 94  |  Chapter 11: Stateful Service