Kubernetes Statefulsets

Kubernetes Statefulsets

Hello Every One in this blog I will try to explain what is statefulset and how it differs from normal deployment.

In case we need to store the state of the request which means for example wheather to check user was authenticted or not?

If the pod receives the request , verifies credentials and user logged in to use app but if we have many such replicas using load balancer another request may be forwarded to some other replica and this replica is unaware of this user.

If one request depends on the previous one then these apps are known as stateful. So the status of the user is better to store in database. Then data base is stateful and frontend app is stateless.

image

Problems Statefulset Solves:

1. Seperate PV

To achieve high availability we need replicas . If we deploy stateful apps like data base as a deployment then each replica uses same Persistent Volumes then there is inconsistency in Reads and writes.

image

There is other Kubernetes object called Statefulset if we deploy such apps as statefulset then each replica use different PV.

image

2. Ordered Pods

We have to allow only one data base to write (Master Data Base) and all other replicas to read (Slaves). Kubernetes start replicas of statefulset orderly which means first master pod and then slave pods will be created one by one but not like Deployment Randomly. Because there should be sync in between pods. Pods copy data from previous pods. If we delete/ scale down last pod will be deleted.

image

3. Sticky Identity

Pod copies data from the previous pod, to identify the previous pod it uses its name so that should not change even after restarting. As each replica gets its own own PV even after restarting pod is attached to same PVC.

image

Headless Services

To interact with Pod we need services which load balances and send request to any pod , but in stateful apps we have to select only one pod and write to that pod and rest all pods copies data from it. So for this purpose headless services are used. Headless Services also does load balancing but using these we can select any specific pod. By Declaring ClusterIp as None we can create headless service.

By mentioning name of the pod in front of service name we can receive response from specific pod.

curl mongopod-1.mongosvc

Assuming mongosvc is a head less service and connected to mongopod-1

Let us Create 3 replicas of Mongo Db Statefulset and connect with Mongo Compass. Creating Statefulsets are similar to creating deployments. We have to mention service name.

image

.

image

Now this headless service is connected to those 3 replicas of mongodb pods.

After connecting to mongosvc through mongo compass as mentioned in volumes chapter.

It is randomly connected to any mongo pod If we write to any pod using mongo compass after refresh service connects to other pod and it is not aware of the data stored in other pods as because though it is statefulset there is no replication of data among pods. To retain the data we have to use persistent volumes.

But unlike deployments we need individual volumes for each pod, statefulsets take care of this by simply using volumeclaimtemplates in statefulset definition under pod level.

image

Now using Storage Class or manually creating persistent volume with necessary configuration persistent volumes are attached.

If we scale the statefulset number of pvs and pvc will increase while we scale down those will not be removed.

Thats all about Statefulset in kubernetes . Thanks for reading my blog have a great day.