When to use Kubernetes StatefulSet? & It’s Limitations

What are StatefulSets?

StatefulSets manage stateful apps in Kubernetes. StatefulSets deliver guarantees for distributed systems, databases (like MySQL, PostgreSQL, and MongoDB), and key-value stores that generate and store important data. Stateless services frequently deploy. StatefulSet Pods have a “sticky identity” that survives failures, restarts, and rescheduling, unlike stateless Pods, which are interchangeable and fleeting.

The Foundations of State

An application that depends on preserving configurations or data over time is referred to as stateful. The filesystem in a pure container context is ephemeral; all local modifications are lost if a container collapses or a Pod is erased. StatefulSets make sure that every Pod replica keeps three essential characteristics a persistent hostname, a solid network identity, and persistent storage bindings so that these applications can run on Kubernetes.

You can also read What are the Deployment Strategies in Kubernetes?

Key Differences from Deployments

Naming is huge distinction between StatefulSets and Deployments. Pods have random hashes (web-95d4d5bcd-75zn6) to demonstrate interchangeability. However, StatefulSets allocate persistent names using zero-based index ordinals. The Pods of a StatefulSet mongo with three replicas are always mongo-0, mongo-1, and mongo-2.

If mongo-1 fails or the node hosting it dies, the StatefulSet controller creates a new Pod. Importantly, regardless of which cluster node it is planned on, this replacement will have the exact same name (mongo-1). For clustered systems, where members need to be aware of one other’s identities in order to establish quorum or replication, this predictability is essential.

Using StatefulSets

Applications that need one or more of the following benefits from StatefulSets:

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

Stable in the aforementioned context refers to persistence throughout Pod (re)scheduling. An application should be deployed using a workload object that offers a collection of stateless copies if it doesn’t require any stable IDs or ordered deployment, deletion, or scaling.ReplicaSet or Deployment might be more appropriate for your stateless requirements.

You can also read What is Kubernetes Cloud Controller Manager?

Limitations

• A PersistentVolume Provisioner must pre-provision Pod storage or provide it by storage class.
• When a StatefulSet is removed or scaled down, its volumes are not deleted. The purpose of this is to guarantee data security, which is typically more beneficial than an automatic removal of all associated StatefulSet resources.
• At the moment, StatefulSets need a Headless Service to be in charge of the Pods’ network identity. You are in charge of developing this service.
• There are no promises offered by StatefulSets about the termination of pods upon deletion. It is possible to scale the StatefulSet down to 0 before deletion in order to accomplish an orderly and elegant termination of the pods within the StatefulSet.
• Using Rolling Updates with the default Pod Management Policy (OrderedReady) may result in a malfunction that needs to be fixed by hand.

How to create a StatefulSet in Kubernetes

Create a Nginx StatefulSet Application

Step 1. Create a StatefulSet file. you can do that by entering the following command:

touch example-statefulset.yaml

Step 2. Open this file in a code-editor and write the following code into it:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: govindhtech-example-statefulset
  annotations:
    description: "This is an example statefulset"
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "govindhtech-example-service"
  replicas: 3 # remember this, we will have 3 identical pods running
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
      volumes:
      - name: www
        persistentVolumeClaim:
          claimName: myclaim

Step 3. Now we have to create a service file and a PersistentVolumeClaim file.

touch example-service.yaml

touch example-persistentVolumeClaim.yaml

Create a Service for the StatefulSet Application

Step 4. Enter the following code into the service file:

apiVersion: v1
kind: Service
metadata:
  name: govindhtech-example-service
  annotations:
    description: "this is an example service"
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx

Create a PersistentVolumeClaim for Application

Step 5. Enter the following code into the PersistentVolumeClaim file:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 8Gi # This means we are requesting for 8 GB of storage

Now lets apply these changes.

Step 6. Create the PersistentVolumeClaim

Now apply the PersistentVolumeClaim to the cluster:

kubectl apply -f example-persistentVolumeClaim.yaml

This will create the myclaim PVC required by the StatefulSet pods.

Note: Kubernetes does not automatically apply resource YAML files. Each resource such as StatefulSet, Service, and PersistentVolumeClaim must be explicitly created using kubectl apply or kubectl create.

Step 7. Enter the following command in your terminal to create the govindhtech-example-statefulset:

 kubectl create -f example-statefulset.yaml

This will create our govindhetch-example-statefulset;

Searching our StatefulSets in our terminal by the command

 kubectl get statefulsets

We will find our govindhtech-example-statefulset in the list.

Step 8. Enter the following command in your terminal to create the govindhtech-example-service.

kubectl apply -f example-service.yaml

This will create a service with the name “govindhtech-example-service.”

Step 9. Let’s check our pods and services, for getting the list of pods enter the following command in your terminal:

kubectl get pods

You will get the list of the three govindhtech pods that we create through defining three replicas in the example-stateful-set.yaml file.

for checking the list of services, enter the following command in your terminal:

kubectl get services

This will give you similar output:

Step 10. Now let’s scale up our pods and check if it works! for scaling up the pods to 6 pods, enter the following command:

kubectl scale statefulset gfg-example-statefulset --replicas=6

This will create 3 more pods and number of pods are now 6, to get list of pods enter the following command:

kubectl get pods

Step 11. Now let’s scale down pods to 3, for that enter the same command, just change the number of replicas back to 3:

kubectl scale statefulset govindhtech-example-statefulset --replicas=3

Checking the list of pods by

kubectl get pods

you will see only 3 pods running:

You can also read What is a Kubernetes Controller Manager?

Some more Operations On StatefulSets

Adding a StatefulSet: To add a StatefulSet to your Kubernetes cluster, use the command kubectl create -f [StatefulSet file name], replacing [StatefulSet file name] with the name of your StatefulSet manifest file.

kubectl create -f [StatefulSet file name]

Scale Up / Down
Adjust the number of replicas in the StatefulSet to meet workload requirements. Pods are created or removed in order.

kubectl scale statefulset <name> --replicas=5

Edit
Update the StatefulSet configuration (e.g., image version, environment variables).

kubectl edit statefulset <name>

Delete
Remove the StatefulSet without deleting the associated PersistentVolumeClaims (PVCs), ensuring data remains intact.

kubectl delete statefulset <name>

Rolling Updates
Update Pods in sequence (one at a time) to minimize downtime while ensuring application consistency.

kubectl rollout status statefulset <name>
kubectl rollout undo statefulset <name>

Stateful Applications Working

• To prevent data inconsistency in stateful systems like MySQL, many pods cannot read and write data at the same time.
• While other pods are marked as slave pods and are only permitted to read data, one pod is designated as the master pod and is in charge of writing and modifying data.
• To guarantee data independence and isolation, each pod has a copy of the data storage.
• Using synchronization, slave pods update their data storage when the master pod changes data to ensure data consistency.
• Stateful applications require continual synchronization to maintain data consistency between pods.

Revision History and Rollbacks

ControllerRevisions is used by StatefulSets to monitor past configuration modifications. An incremental revision number and a snapshot of the template are stored in a new revision that is generated whenever a Pod template is modified. This enables administrators to monitor versioning throughout the cluster and rollback to earlier settings.

You can also read Kind: A Practical Guide to Local Kubernetes Clusters