How StatefulSets is useful than other Controller in K8s

Table of contents

Reading Time: 3 minutes

A StatefulSet is a controller that helps you deploy and scale groups of K8s pods.When pods are deployed in order that they have a persistent storage volume and unique stable network identifier to restart and reschedules the pod .

StatefulSet

StatefulSets comes with k8s v1.9 .

Manages the deployment and scaling of a set of pods and provides guarantees about the ordering and uniqueness of the pod . Firstly let us know what are the Stateful application . A Stateful application that store data to keep track of its state . Some Stateful application are MySQL , MongoDB , Cassandra etc.

StatefulSet create the pod with a unique naming conventions like if you create a StatefulSet with name Count . It will create a pod with name count-0 and for multiple replicas of a StatefulSets their name like Count-0 , Count -1 , Count -2 etc . The pod count-0 called Master and other pods count-1 , count-2 called Slave .

In StatefulSet every replica will have its own state and each pod will be creating its own PVC (Persistent Volume Claim ) so if we create statefulset with 3 replica it will create 3 pod and 3 PVC .

StatefulSets are valuable for applications that require :

Stable and unique network identifiers.
Stable ,persistent storage .
Ordered , graceful deployment and scaling .
Ordered , automated rolling updates .

Some example of reasons you had use a StatefulSet :

A Redis pod that has access to a volume, but you want it to maintain access to the same volume even if it is redeployed or restarted .
A Cassandra cluster and have each node maintain access to its data .
A webapp that needs to communicate with its replicas using known predefined network identifiers .

In the above diagram there are 3 StatefulSet and each pod has its own Persistent Volume .

How to create a StatefulSet :

StatefulSets currently require a Headless Service to be responsible for the network identity of the Pods.

Headless Service Manifest file :

apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: stateful-blog
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx

StatefulSet Manifest file :

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: count
  namespace: stateful-blog
spec:
  serviceName: "nginx"
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

In StatefulSet when Pods are being deployed they are created sequentially it means pods count-1 ,count-2 Pod is not launched untill the count-0 Pod is running .

The StatefulSet controller created three PersistentVolumeClaims that are bound to three PersistentVolumes.

Delete the Resource:

kubectl delete sts count -n stateful-blog
kubectl delete svc nginx  -n stateful-blog

Compare with Deployment and StatefulSet :

Deployments are usually used for stateless applications while StatefulSet are used for stateful applications.
When we create a deployment it will create a ReplicaSet which will further create the pod . If you create deployment with name Count ,it will create count-<replica-set-id>-<pod-id> . If you create Statefulset it doesn’t create ReplicaSet it creates the Pod with a unique naming convention as we shown in above example .