Understanding deployments and StatefulSet: Kubernetes for beginners

In this post, we will go through how replicas are managed/deployed and how the databases are handled while replicating.

Photo by engin akyurt on Unsplash

This article is continuation of understanding the kubernetes components and we will specially explain the lifecycle of node/pod/replica in case of downtime and how its managed by kubernetes.

We understood components and user is now able to access the application my-app.com through browser.

Now if my application pod dies or crashes, it would leads to a downtime where user will unable to reach the application. Refer state below.

This is the advantages of distributed system and container approach that, instead of relaying on single machine, or node per say, we are replicating everything to multiple servers. Refer state below

So new pods, will also be connected to the same service. We can recall that service is like static endpoint for the pods, and here in this case, service will also act as load balancer.

So service can decide to transfer the traffic/request to the pods which is less busy.

Deployments

To launch new replica of pods, we will not launch new pods, but we will define blueprint for the pods and we will just define how many replica we need.

This mechanism to define replica is called deployments. Its another important components of kubernetes.

blueprint for my-app pods will be called deployments.

So in practise, we will not be working with pods directly but deployments. Its another level of abstraction for pods to manage, replicate, scale and interact.

Result

So if one of the pod of application dies, service will still forward request to another running pod and application will keep responding and user. And user will be able to use the application. Refer the state below.

Now we may be wondering what about database pods?

If one of the database pods dies, it should forward to another replica of database right? Here is the catch.

Database can’t be replicated using Deployment.

Why database can’t be replicated using deployment in kubernetes?

Reason for that is, because database is having something called, state or data. That means all the running pods will be accessing the same shared database.

StatefulSet

Replicating database pods have complexity that which of the pods is writing and where, and which pod is reading and maintaining consistency is real challenges.

This needs mechanism which can control the reading/writing/seek of database while replicating/replacing the database pods, and this is offerd by another kubernetes components called statefulSet.

Statefulset is specially ment for stateful pods which may contain application like elasticSearch, mongoDB, mysql and so on, and these should be created using stetefulset not deployment.

StatefulSet will be responsible for, replicating the pods, scaling them up, scaling them down and so on, making sure database read/write is synchronised properly

However, deploying database application using even StatefulSet are complex and tedious task.

So its best practise to host database service/app entirely somewhere else, out of kubernetes cluster.

So now our entire setup is more robust,

Meaning that even if any pod dies or entire node is rebooted, our application will still be served by replica node.

Did you learn something new? enjoyed learning basics of kubernetes? Don’t forget to share this article via X or linkedIn and follow me for upcoming and new informative articles on it.