See these 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, hostnames, and volumes.

Once a Pod of a StatefulSet is deployed, its name, hostname, and volumes will last for the lifetime 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, hostname, volumes).

If the StatefulSet get scaled down (Pods terminated) and then scaled up (new Pods), the new Pods will get back the same state as the old Pods.

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 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 node with enough available resources.

The same behaviour, described above, applies if you use the imperative command ("kubectl create") to create the StatefulSet.

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 current state aligned with the desired state. For example, if a Pod get terminated, a new one will be created (with same name and hostname 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 the Pods will have the following names: "nginx-0", "nginx-1", "nginx-1".

Each Pod of the StatefulSet will get a unique hostname.

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 the Pods will have the following hostnames: "nginx-0", "nginx-1", "nginx-1".

A Kubernetes Service has a stable IP address/DNS name that are exposed on the network. It maintains the list of Pods associated with it 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 hostnames 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 its 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" and defines Volume Template Claim with the name "pv-data", and defines 3 replicas, then the Pods will have the following hostnames:
"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 allows an ordered creation and deletion of the Pods of a StatefulSet.
The Parallel setting allows a parallel creation and deletion of the 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 terminated 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 terminated before the next one can be terminated.
  
  The "spec.template.spec.terminationGracePeriodSeconds" field allows configuring a grace period to ensure that Pods are terminated gracefully, before forcing the termination 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.

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
If you are using Kubernetes on Docker Desktop, you also need to define a Persistent Volume (hostPath) for each Pod replica.
For more details, see Volumes.
$ vi hello-nginx-statefulset-pv.yaml kind: PersistentVolume apiVersion: v1 metadata: name: www-nginx-0 labels: type: local spec: accessModes: ["ReadWriteOnce"] storageClassName: hostpath capacity: storage: 1Gi hostPath: path: "/mnt/mydata/nginx-pv-data" --- kind: PersistentVolume apiVersion: v1 metadata: name: www-nginx-1 labels: type: local spec: accessModes: ["ReadWriteOnce"] storageClassName: hostpath capacity: storage: 1Gi hostPath: path: "/mnt/mydata/nginx-pv-data"
Let's define 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 the Persistent Volumes (again this is needed only for Kubernetes on Docker Desktop):
$ kubectl apply -f hello-nginx-statefulset-pv.yaml persistentvolume/www-nginx-0 created persistentvolume/www-nginx-1 created
View the Persistent Volumes (the STATUS is Available):
$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE www-nginx-0 1Gi RWO Retain Available hostpath 17s www-nginx-1 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 www-nginx-0 1Gi RWO hostpath 79s www-nginx-1 Bound www-nginx-1 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 www-nginx-0 1Gi RWO Retain Bound default/www-nginx-0 hostpath 4m5s www-nginx-1 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

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

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: 10.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

To delete a StatefulSet using its manifest file:
$ kubectl delete -f hello-nginx-statefulset.yaml statefulset.apps "nginx" deleted
To delete a StatefulSet using its name:
$ 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