Why Kubernetes?
Koo-ber-netes?
What on earth is a Kubernetes? Or, Who is a Kubernetes? Hmm… sounds like a Greek God’s name right? Well, close enough. From the official Kubernetes documentation, Kubernetes can be defined as “an open-source system for automating deployment, scaling, and management of containerized applications”. To be brutally honest, this definition made little sense to me when I started working with Kubernetes with almost no experience. It took me weeks' worth of reading, researching, theoretical training, and practical training to understand one of the most talked-about concepts in the industry. Even as an individual from a technical background, I still found it difficult to grasp the concepts. I want to make Kubernetes easier to understand for my non-technical and technical friends out there who have no prior experience in Cloud. In this article, I’m going to try and break this definition down further using analogies to hopefully shed some light on K8s.
Like all our teachers did in school, let’s start with the history. A few decades ago, people used physical servers — or what we call bare-metal servers — to run their programs or applications. It’s almost like you can use only one laptop for math homework questions and another laptop to write down your answers. Sounds like a tad bit of resource misallocation right? Evidently enough, a higher number of applications mean more physical servers, more physical servers mean higher costs incurred by the organization, higher the costs incurred… well, it isn’t really a good thing in the long run, is it? Now, this might seem generalized for all companies/industries, but with a successful company comes sustainable, scalable solutions and physical servers are not the most viable solution when talking about scalability. Another disadvantage is that physical servers are not that easy to manage, therefore more servers mean we need to spend more time learning different servers’ configurations, which isn’t a really good use of time (no offense to server admins). Later on, advancements took place and we were able to host multiple applications on a single bare-metal server — better, but still not the most efficient. Bringing back the math homework example, you now have the questions + answers up on one laptop but need another laptop for a calculator. Better, indeed, but not quite. This is also called virtualization where two processes are forced to believe that they each have all the server resources to themselves.
People started to realize the challenges with scalability while working with physical servers and started to break their large monolithic applications into smaller microservices. Microservices are loosely coupled applications with a single functionality and which can be deployed independently. A microservice could be something as simple as a payment gateway for an e-commerce portal or an authentication system for a website.
The above is a very fundamental example of how the microservices architecture would look for an online food delivery service. The whole application can be broken down into 4 separate microservices that handle a specific functionality by themselves. Microservices are also usually hooked up with a database to record events and logs. The type of storage can be Persistent or Non-Persistent depending on the use case. With persistent storage, contents of the database are still available after the microservice goes down while with non-persistent storage, the contents are only available when the application is up and running. Due to this reason, persistent storage is called non-volatile whereas non-persistent is called volatile.
In this example, if the number of orders from the end-users spikes up, then the software architecture must adapt itself accordingly as well. To make the scalability of microservices convenient and flexible, we containerize the microservice. A container is nothing but a lightweight package that comprises code, dependencies, and overhead data to run a software program. Essentially, a microservice can be packaged into a container to be able to deploy it multiple times at runtime. The concept of containerization is tremendously helpful in dynamically scaling microservices and is used very often in cloud computing. For example, let’s say it gets super chilly in the city one day and everyone wants to order in instead of stepping out for groceries or food. At this point, the delivery portal’s services must go from handling 1,000 orders to 10,000 orders in real-time to prevent downtime. Since a container is an independent and lightweight package of the service, we can deploy that 9 more times for it to handle the influx of traffic. Here’s a simple demonstration of how these containers will stack up in the system to handle new customers.
Now you must be wondering, “who duplicates these containers?”, or “what happens when it gets warmer and orders go down?”, or “is someone sitting at their desk hitting ctrl-c ctrl-v + delete?” or maybe you’re going “🥴”. Well, the answer to your questions is Kubernetes. Kubernetes is the platform responsible for orchestrating containers within a cluster of various services. Kubernetes abstracts the complicated process of scheduling applications from the developer so that the developer can deploy as many applications without worrying too much about the background processes. Kubernetes also allows the development team to be able to work independently from the operations team thereby boosting productivity at the workplace as well.
The diagram above depicts several (rather hungry) customers placing their food orders to a restaurant’s MasterChef. The MasterChef, then, forwards these orders to his chefs to prepare. Notice how each dish was allocated to each group of chefs based on the number of orders and the complexity of the dish. The groups of chef can prepare the dishes in a neat and organized manner to avoid unnecessary conflicts.
Now, compare each dish to a single service. Starting from the left-most side, let’s assume the customers are client-side servers or a team of developers requesting multiple instances of services. These requests need to be passed onto the MasterChef that is none other than, you guessed it, Kubernetes itself. Kubernetes handles all these inputs and schedules its resources, or chefs, in a way that is most optimal. If the number of orders for pizzas goes from 9 to 15 and hotdogs go from 8 to 4, MasterChef will add 2 chefs from the hotdogs group to the pizza group. In Kubernetes, this is called automating container deployments and scaling of resources. Kubernetes has many other features that help manage these containers as and when end-user requirements change, unknown errors occur in one group, or inputs need to be distributed to avoid pressure on a single group. Now, this is of course a broad overview of Kubernetes and its functionality, but at the end of the day, this analogy pretty much summarizes the need for Kubernetes. There are other alternatives out there that compete with Kubernetes but the fact that it is backed by such a strong open-source community makes it a stalwart in the realm of container orchestration.
I hope this overview was helpful in your journey to learn Cloud Computing. Check back for similar content on Kubernetes, its architecture, use-cases, and actual working examples of deployments.
If you enjoyed reading this article, like, comment, and share it! Feel free to comment below with any questions or reach out to me at apatil6@wisc.edu!
