So I decide to build my own Kubernetes (replica set feature) for fun over weekend.

We all know internet users are increasing really really fast and application needs to run on multiple servers so that they can provide seamless experience to these users without any issue. In technical terms we call this paradigm as “ distributed systems".( We can detail out more on this definition but I feel we understood the basic gist — why we need to move away from one app server to multiple or like microservice architecture)

If one is designing any app today, he/she needs to embrace failure and have a mindset that some servers can potentially go down and system needs to be designed in such a way that these failures won’t affect output.

Back in my school days, when teacher used to be busy with other important tasks, she/he used to inform class monitor to take care of class and make sure everything is in place. It felt like class monitor used to orchestrate us and tell us what should we focus on and used to handle our queries .

You all must be wondering why Sumit is telling us about his school days? Haha! no worries. Like I mentioned earlier, to meet the demand, any application today is deployed on multiple servers. Just like we had class monitor back in my school days to take care of us. In current internet situation — we need an application level monitor to orchestrate between multiple servers, coordinate between servers, make a note which server is up and running etc.

Before we move to core of the article — above analogy was just presented for simplification of the concept and to bring all my wonderful readers from different backgrounds to the common ground.

I keep saying multiple servers ( but what I actually mean is multiple containers). Imagine server as house and container as room. Normally, if only one person is going to stay — he/she might opt for a room, rather than renting entire house. Landlord can invite other guests and properly utilise the house. Hence a server can have multiple different applications in the form of containers. And software which orchestrates multiple containers is known as Kubernetes( again this definition can be detailed out more but we understood the basic gist).

There is one feature in Kubernetes called replica set which suggests that no matter what happens at any given time, application X should be present in 3(this can be any threshold value) servers/no of containers ( actually term is called pod). This is an interesting feature as it speaks about combating failure. To give an relatable example, imagine we have store which is open for 24*7, we inform customers that no matter what time of the day you come, there always will be 2–3 staff members to solve your queries. This feature exercises orchestration capabilities of the Kubernetes.

Let’s visualise system design/architecture of this feature and solve it according to my understanding

Architecture

Components

• Redis DB to store how many copies of applications are running etc.
• Whenever new app is started, record must be updated in redis db and hence there is a API for it.
• Same goes with when application stops.
• Background process/job which listens to server/container/pod stopping events .

We always ask user to specify the threshold — like how many copies of applications should be running at any given point of time. Once new app starts, its count is incremented in redis db through API. Whenever app stops, its count is decremented in redis db through API, at same time event is published specifying the count of copies of applications currently running. Background listener captures this event and see if count is greater than threshold or not, if not then it automatically starts a new copy of application and threshold is achieved.

Below is the demo from my local machine. I specified that at any given point, 3 copies of applications should be running. In this demo, you will see the moment I closed the app and count went below 3, new app is immediately launched by background listener.

DEMO

CODE LINK
API — is written in rust
Background Listener — is written in rust
Application — is written in dotnet core
Redis as backend storage.

This feature is extremely critical for high availability of applications. Hope you guys enjoyed reading this one and if you liked it, please like the article and share with your friends.

~ Happy Coding ☺️