name : http volumeMounts : -  name : logs mountPath : /logs volumeClaimTemplates : -  metadata : name : logs spec : accessModes : [ "ReadWriteOnce" ] resources : requests : storage : 10Mi Name of the StatefulSet is used as prefix for the generated node names References the mandatory Service defined in Example 11-2 Two Pod members in the StatefulSet named  ng-0  and  ng-1 Template for creating a PVC for each Pod (similar to the Pod’s template) Rather than going through the definition in Example 11-1 line by line, we explore the overall behavior and the guarantees provided by this StatefulSet definition. While it is not always necessary, the majority of stateful applications store state and thus require per-instance-based dedicated persistent storage. The way to request and associate persistent storage with a Pod in Kubernetes is through PVs and PVCs. To create PVCs the same way it creates Pods, StatefulSet uses a  volumeClaimTemplates element. This extra property is one of the main differences between a StatefulSet and a ReplicaSet, which has a  persistentVolumeClaim  element. Rather than referring to a predefined PVC, StatefulSets create PVCs by using  volume ClaimTemplates  on the fly during Pod creation. This mechanism allows every Pod to get its own dedicated PVC during initial creation as well as during scaling up by changing the  replicas  count of the StatefulSets. As you probably realize, we said PVCs are created and associated with the Pods, but we didn’t say anything about PVs. That is because StatefulSets do not manage PVs in any way. The storage for the Pods must be provisioned in advance by an admin, or provisioned on-demand by a PV provisioner based on the requested storage class and ready for consumption by the stateful Pods. Note the asymmetric behavior here: scaling up a StatefulSet (increasing the  replicas count) creates new Pods and associated PVCs. Moreover, scaling down deletes the Pods, but it does not delete any PVCs (nor PVs), which means the PVs cannot be Storage Solution  |  91