Part V : Working out the "Workloads"
Work... Flashback to grade nine Physics class and the teachers talking about work. In the Physics sense of course: Force multiplied by Displacement...Nevermind! It's a long story.
Point is, after that, my brain automatically related the term "work" within the Physics context. It was not until I started reading up on K8s (Kubernetes) when I could adapt to a newer context. Now, I add another term to the word "work" and my brain tells me it's Kubernetes. The word is "Workload".
That's the post for today. Kubernetes Workloads. Probably something that you'll be using a lot. A lot. Let's get started!
Work... Work... Workloads
Okay, I already told you about pods. They run containers. Have a lifecycle...blah blah blah. I'm gonna skip this one because there's one entire post dedicated to it. And I also talked about controllers a bit in our last post on Kubernetes components.
Now, there's a link between the two. Pods and Controllers.
A Controller is going to manage a set of Pods. But HOW a controller must handle the pods is specified by the workload resources. In other words, a workload resource will manage the functioning of the pods for you using controllers. Confused? Allow me to elaborate.
Why Do you need Workloads?
Usually, governments carry out these redevelopment tasks where they demolish old, dilapidated structures, especially living quarters, and construct new buildings there. In such cases, the people already living there are displaced to another location while the construction progresses and are then reallocated accommodation in the new buildings.
Extend this idea with respect to the cluster. It may happen that the node fails or goes down suddenly. That's like demolishing the older buildings. Now with some effort, you manage to bring the node back up or maybe provision a new node to replace the earlier one (the newer construction).
But wait. What are you going to do about the pods that were running on the failed node? (A node fails, the pods on it fail too). These pods have to run on the new node now. Just like the citizens who were living in the older quarters.
Who's going to do this? Who's going to keep track of which application pods should be created? Who's going to keep track of how many pods of an application must run at a given time? That's right...Workload resources.
Your workload is a way to handle pods on the cluster. Well, a selected set of pods in reality. You can say the workload is an application. Once you specify a workload resource, its job is to create the pods and ensure that a fixed number of pods always keep running.
How do Workloads Work?
Workloads are more of a concept than an actual resource in Kubernetes. You basically take your application and classify it as a particular workload type. It all depends on what your application code is doing.
Now once you say that your application belongs to, say, a workload type 'X', A controller that handles the workload also comes into the picture. And like I told you earlier, the controller is going to maintain the desired state for your application pods and if there's a difference in the current state, it'll always try to take appropriate steps to get to the desired state.
Stateful or Stateless?
A slight deviation from the topic here. But trust me you'll need this piece of information.
Understand the difference between these two terms. Stateful and Stateless. Okay, think you are at your favorite coffee shop ordering your regular "everyday" coffee. Now you can face two situations here.
How do you like your Coffee?....
Situation number one is that you have a new person taking your order every time you visit and you have to repeat your coffee preference.
The other one is that there's always a familiar face behind the counter who remembers how you like your coffee. And well, you don't need to repeat. All you say is "The usual please" and pay!
So your first situation is how a stateless application works. The person taking your order is the "server" and you, the customer, are the "client". In stateless applications, the server does not maintain information about client sessions. Rather, the sessions are maintained at the client-side. (You remember your previous coffee orders but the person behind the counter doesn't!)
The second scenario is similar to stateful applications. In stateful applications, servers persist the client's session details. That's why the coffee shop employee remembers your previous orders. Therefore, usually, there is some sort of persistent storage (like a database) used in stateful applications.
By the way, Stateless applications are all the rage these days. But wait, isn't storing session details beneficial? Well yes. See here's the catch. Stateful applications save session data on the server. That means your server needs to do that extra task of persisting sessions along with serving requests. Stateless applications do maintain session information, but it's on the client-side. So your server is free from all this extra work and can only focus on its sole task.
See those "Accept Cookies" pop-ups on websites? Cookies are a common way stateless applications store session information on the client-side to maintain some form of "state".
Web applications that prvoide REST/GraphQL/gRPC based APIs are in reality stateless applications. And you already know how popular they are!
Decide Your Workload
Let's play a little quiz here. Based on this you'll know what your workload should be.
Deployments
Personally, I have probably used the Deployment workload the most. That's because I develop REST-based applications a lot. So in case you're on the same boat as I am, deployments are going to be your choice of workload too.
To explain it in a crude way, a deployment workload will specify how many pods of a particular application should be running at a time. And if there's a mismatch, a deployment controller will make sure to get it to the desired number by either restarting/creating pods (if the number is lower than specified) or by scaling down pods (if the number is higher than specified)
The same can be done for ReplicaSets.....
ReplicaSets. That's a new term.
You have 3 pods of Application X. You call it Pod Set X . Replicate Pod Set X and you get Pod Set X 2.0. That's a replica set. Take a set of pods, replicate it!
So now you see, in a Deployment, you can even say "I want a set of 3 pods and I want two replicas of this set running" instead of saying "I want 6 pods running"
StatefulSet
StatefulSets are like deployments with OCD. Seriously. See a Deployment will create a given number of pods for you. A StatefulSet will do that too, but it's going to be super particular about the order in which the pods are created. Each pod is going to have a unique identifier. And you cannot mess up the order of these pods. Neither can you just simply replace one pod with another there'll be a safe and ordered way to it!
Daemon
I often call Daemons (not demons) the "Invisible Workers on the Cluster". They're there alright. But they won't bother you at all. Most Daemon processes work in the background continuously and don't require any user intervention. Simple examples are processes that monitor nodes, collect logs or perform storage regular backups.
Jobs & Cronjobs
A simple task that you have to do once. Just once and you are done. Like buying a laptop. You have to pay the amount once and the laptop is yours. That's what a job is. A simple task that executes once and exits.
For example, if you want to run setup scripts at the beginning of a new project. That's a job. If you want to do some heavy-duty computation once and store it for future use. That's a job too.
A slightly modified version of a job is a cronjob. Buying a laptop once is a job. But hey, you gotta pay the internet bills regularly! For most of us, it's a monthly headache! That means the task of paying bills occurs at regular intervals.
That's what a Cronjob is. Take a job, repeat it at fixed intervals. Done! Simple examples can be notifications, reminders, or regular emails. Or even scripts that perform regular health checks or cleanups on the clusters
In Summary
These were a few important workloads that you must know when deploying your applications on Kubernetes. We have a sister series that will tell you how you can create these workloads on your own clusters. Make sure you go through the posts in there too! For this series, we'll talk about more Kubernetes concepts in the upcoming posts! See you then! Ciao!