Please visit thes pages for more details about StatefulSets:
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/
https://kubernetes.io/docs/concepts/security/controlling-access/
https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

StatefulSets allow deploying Pods that require unique names, host names, and volumes.
Once a Pod of StatefulSet is deployed its name, host name, and volumes will last for the life of the StatefulSet.
Unlike a Deployment, a StatefulSet maintains a sticky identity for each of its Pods.
If a Pod get restarted (including failures) or rescheduled (including when it's deployed on a new node), it will still keep the same information (name, host name, volumes).
It the StatefulSet get scaled down (Pod terminated) and then up (new Pod), the new Pod will get back the same state as the old Pod.

To create/deploy a StatefulSet, you need first to create a manifest YAML file. The manifest file describe the StatefulSet and its components (name, Pods, ...). You can use kubectl (or any rest client tool) to post the manifest file to the API server (same behaviour if you use the imperative command to create the StatefulSet via the "kubectl create" command). If applicable, the API server verifies that the request is authenticated, validates it's authorized, and runs the admission controllers on it. The API server verifies the manifest file and, if no issues, it writes a record for that manifest in the cluster store (etcd). The scheduler will then read the record and deploy the Pod of the StatefulSet to a healthy worker(s) node(s) with enough available resources.

A StatefulSet run as a control loop that watches the state of the cluster through the API Server and if it notices that the current state is different from the desired state defined for the StatefulSet, it will tries to get the the current state aligned with the desired state.
For example, if a Pod get Terminated, a new one will be created (with same name and host name and attached to the same volume).

Each Pod of the StatefulSet will get a unique name.
The name is constructed from the StatefulSet's name and the Pod's ordinal: <StatefulSet-Name>-<Pod-Ordinal>
The Pod's ordinal is an integer number that starts from 0.
The first Pod to be created for the StatefulSet will get the ordinal 0, the second Pod 1, the third Pod 2, ...
For example if a StatefulSet has the name "nginx" and defines 3 replicas, then Pods will have the following names: "nginx-0", "nginx-1", "nginx-1".

Each Pod of the StatefulSet will get a unique host name.
The name is constructed from the StatefulSet's name and the Pod's ordinal: <StatefulSet-Name>-<Pod-Ordinal>
The Pod's ordinal is an integer number that starts from 0.
The first Pod to be created for the StatefulSet will get the ordinal 0, the second Pod 1, the third Pod 2, ...
For example if a StatefulSet has the name "nginx" and defines 3 replicas, then Pods will have the following host names: "nginx-0", "nginx-1", "nginx-1".

A Kubernetes Service has a stable IP address/DNS name that are exposed on the network. It has also the of Pods associated to the service and to which it will route requests.

A headless Service is a regular Service without a ClusterIP (the ".spec.clusterIP" set to None).
The headless Service must be listed in the ".spec.serviceName" field of the StaefulSet.
The Pods, that match the StatefulSet's label selector, will have unique DNS host names that allow applications to request directly a Pod.

A DNS SRV record will be created for each Pod that matches the label selectors of the headless Service.
A DNS query, using the name of the headless Service, allows retrieving the list of the Pods associated to the headless Service.

Each Pod of the StatefulSet will get it's own volume created at the same time when the Pod is created.

StatefulSets use Volume Claim Templates to provision dynamically volumes. A Persistent Volume Claim is created for each Pod.

The name is constructed from the Volume Template Claim name, the StatefulSet's name and the Pod's ordinal: <VolumeClaimTemplate-Name>-<StatefulSet-Name>-<Pod-Ordinal> (or: <VolumeClaimTemplate-Name>-<Pod-Name>)
The Pod's ordinal is an integer number that starts from 0.
The first Pod to be created for the StatefulSet will get the ordinal 0, the second Pod 1, the third Pod 2, ...
For example if a StatefulSet has the name "nginx", defines Volume Template Claim with the name "pv-data", and defines 3 replicas, then Pods will have the following host names: "pv-data-nginx-0", "pv-data-nginx-1", "pv-data-nginx-1".

The volumes won't be deleted if you delete the Pods or the StatefulSet.
If you scale down and scale up again the StatefulSet, any existing volumes will be associated to the new Pods based on their names.
Once you are done with a StatefulSet, you can delete the volume manually.

StatefulSets provides two means to control how their Pods are created and deleted.
The .spec.podManagementPolicy field accept two values: OrderedReady (default), Parallel.
The OrderedReady setting allow an ordered creation and deletion of Pods of a StatefulSet.
The Parallel setting allow a parallel creation and deletion of Pods of a StatefulSet (still the Pods preserve their uniqueness and identity guarantees).

Unlike Deployments that delegate the scaling and self healing of Pods to the ReplicaSets controllers (which allow creating Pods in parallel), StatefulSets manage directly the Pods' creation and deletion.

• OrderedReady:
  When deploying a StatefulSet, the Pods will be created in order and each Pod must be running and ready before the next one can be created. If a Pod fails to start, it will be retried again and the next Pods won't be created if the failure is not fixed
  
  The same apply when scaling up the StatefulSet, new Pods will be created in order and each new Pod must be running and ready before the next one can be created.
  
  When deleting a StatefulSet, the Pods will be terminated in a reverse order. The Pod with the highest ordinal will be terminated first and each Pod must be completely shutdown before the next one can be terminated. If a Pod fails to terminate, it will be retried again and the next Pods won't be terminated if the failure is not fixed.
  
  The same apply when scaling down the StatefulSet, Pods with the highest ordinal will be terminated first and each Pod must be completely shutdown before the next one can be terminated.
  
  The .spec.template.spec.terminationGracePeriodSeconds field allows configuring a grace period to ensure that Pods are shut down gracefully, before forcing the shut down in case the Pods was not terminated by then.
  
  
• Parallel:
  This allow StatefulSets to create and terminate pods in parallel.
  This settings does not apply when rolling updates.
  

When performing rolling updates, the Pods will be updated in a reverse order. The Pod with the highest ordinal will be updated first and each Pod must be running and ready before the next one can be updated. If a Pod fails to get updated, it will be retried again and the next Pods won't be updated if the failure is not fixed.

To delete a StatefulSet:
$ kubectl delete statefulset sfs1
When deleting the StatefulSet, all Pods will be terminated in parallel.

If you need that the Pods get deleted in order, then you need first to scale down the StatefulSet to 0 replicas and then delete it.

Scale down the StatefulSet to 0 replicas:
$ kubectl scale statefulset sfs1 --replicas=0
Check that the StatefulSet has no replicas before deleting the StatefulSet:
$ kubectl get statefulset sfs1 NAME READY sfs1 0/0

Let's define a simple StatefulSet to deploy nginx "hello-nginx-statefulset":
$ vi hello-nginx-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: nginx # must be a valid DNS name. it will be used to create the name of the Pods: nginx-0, nginx-1, ... spec: selector: matchLabels: app: nginx # needs to match .spec.template.metadata.labels serviceName: "nginx" # needs to match the name of the headless Service replicas: 2 # by default is 1. Will create two pods: nginx-0, nginx-1 template: metadata: labels: app: nginx # needs to match .spec.selector.matchLabels spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: nginx:latest ports: - name: nginx containerPort: 80 volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www # will be used to name the PVCs of the pods: www-nginx-0, www-nginx-1, ... spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "my-storage-class-name" # needs to match the storage class name resources: requests: storage: 1Gi
If you are using Kubernetes on Docker Desktop, you will need to adjust the volumeClaimTemplates section as following:
volumeClaimTemplates: - metadata: name: www spec: accessModes: ["ReadWriteOnce"] storageClassName: "hostpath" # needs to match the storage class name resources: requests: storage: 1Gi selector: matchLabels: type: local
You also need to create explicitly a Persistent Volume (hostPath) for each Pod replica:
$ vi hello-nginx-statefulset-pv.yaml kind: PersistentVolume apiVersion: v1 metadata: name: nginx-pv-1 labels: type: local spec: accessModes: ["ReadWriteOnce"] storageClassName: hostpath capacity: storage: 1Gi hostPath: path: "/mnt/mydata/nginx-pv-data1" --- kind: PersistentVolume apiVersion: v1 metadata: name: nginx-pv-2 labels: type: local spec: accessModes: ["ReadWriteOnce"] storageClassName: hostpath capacity: storage: 1Gi hostPath: path: "/mnt/mydata/nginx-pv-data1"
Let's create the headless Service:
$ vi hello-nginx-headless-service.yaml apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - name: nginx port: 80 clusterIP: None # indicates a headless Service selector: app: nginx
Let's create first the Persistent Volumes (again this is needed only for Kubernetes on Docker Desktop):
$ kubectl apply -f hello-nginx-statefulset-pv.yaml persistentvolume/nginx-pv-1 created persistentvolume/nginx-pv-2 created
View the Persistent Volumes (the STATUS is Available):
$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE nginx-pv-1 1Gi RWO Retain Available hostpath 17s nginx-pv-2 10Gi RWO Retain Available hostpath 17s
Let's create the StatefulSet:
$ kubectl apply -f hello-nginx-statefulset.yaml statefulset.apps/nginx created
Check the Pods creation:
$ kubectl get pods --watch NAME READY STATUS RESTARTS AGE nginx-0 0/1 ContainerCreating 0 2s nginx-0 1/1 Running 0 19s nginx-1 0/1 Pending 0 0s nginx-1 0/1 Pending 0 0s nginx-1 0/1 Pending 0 3s nginx-1 0/1 ContainerCreating 0 3s nginx-1 1/1 Running 0 5s
Check the Persistent Volume Claims:
$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE www-nginx-0 Bound nginx-pv-1 1Gi RWO hostpath 79s www-nginx-1 Bound nginx-pv-2 10Gi RWO hostpath 60s
Check again the Persistent Volumes (the STATUS should be Bound now):
$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE nginx-pv-1 1Gi RWO Retain Bound default/www-nginx-0 hostpath 4m5s nginx-pv-2 10Gi RWO Retain Bound default/www-nginx-1 hostpath 4m5s
Let's create the headless Service:
$ kubectl apply -f hello-nginx-headless-service.yaml service/nginx created
Check the headless Service:
$ kubectl get service nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP None <none> 80/TCP 5m6s

Please see more details about Kubernetes DNS Service (and dnsutils utility) in this page:
Kubernetes Cluster

Please see more details about Kubernetes Services in this page:
Services (services|svc)

Let's check the headless Service:
$ kubectl exec -i -t dnsutils -- nslookup nginx.default.svc.cluster.local Server: 0.96.0.10 Address: 10.96.0.10#53 Name: nginx.default.svc.cluster.local Address: 10.1.0.150 Name: nginx.default.svc.cluster.local Address: 10.1.0.151
The previous provided the IP addresses of the Pods of the StatefullSet.
Let's resolve the fully qualified DNS names of the Pods:
$ kubectl exec -i -t dnsutils -- host 10.1.0.150 150.0.1.10.in-addr.arpa domain name pointer nginx-0.nginx.default.svc.cluster.local.
$ kubectl exec -i -t dnsutils -- host 10.1.0.151 151.0.1.10.in-addr.arpa domain name pointer nginx-1.nginx.default.svc.cluster.local.
Kubernetes constructs DNS sub-domains as follow: <POD-NAME>.<HEADLESS-SERVICE-NAME>.<NAMESPACE>.svc.cluster.local

The pods of the StatefulSet, as shown above, have the following fully qualified DNS names:
nginx-0.nginx.default.svc.cluster.local
nginx-1.nginx.default.svc.cluster.local