An overview of what Kubernetes is and why it exists
Even though I’ve been working at a company that uses Kubernetes, I’ve never got the spark or the need to go deep in understanding the technology. I knew the basics and a couple of kubectl (a tool that allows you to run commands against your Kubernetes cluster) commands that allowed me to perform my daily duties as an engineer, but when it comes to the nitty-gritty of it, I was pretty much clueless. Lately, I’ve had some time to dig into the technology and in this article, I want to summarize what I’ve learned. I hope you find it useful.
A little bit of history…
Before jumping into what Kubernetes is, I want to explain a little bit of history that hopefully will clarify why did we even need this technology.
Back in the day, companies that wanted to expose their applications to the Internet, would buy physical machines to host their applications. That physical machine would have the hardware and an operating system, and on top of it, the applications would run. Pretty simple, right? This is how our laptops work. Well… There is an issue with this approach. What would happen if one of the apps running in that server ends up taking 90% of the machine resources? You are forced to buy another machine just for that app. As you can see, this doesn’t scale nicely…
The solution that folks came up with was virtual machines. As its name suggests, a virtual machine is a virtual environment that simulates a physical machine. What this means is that in a single physical machine, you can have multiple (guest) operating systems working on top of the operating system that was installed in the physical machine, independently managing their own (virtual) hardware. This is pretty cool because now we can put that app that was taking 90% of the physical resources, and make it run in a virtual machine, so it takes 90% of those virtual resources, without affecting the other potential virtual machines.
One of the drawbacks of Virtual Machines (VMs) is that they can take up a lot of system resources. Each VM runs its own operating system, and also a virtual copy of all the hardware that the operating system needs to run. This quickly adds up to a lot of RAM and CPU cycles. This could be overkill for some applications.
There was another virtualization technique, called containerization, that even though it had been with us for decades, in 2013 with the introduction of Docker, exploded in popularity as a way to overcome the VMs limitations. The containerization technology consists of two main things: the containers and the container engine. A container is a way to wrap up an application so that the application doesn’t need to care about which physical machine it is being run. Instead of virtualizing the hardware, containers virtualize at the operating system (Kernel) level and live on top of a container engine. The engine is responsible to receive requests from the containers and communicate with the underlying OS. By not having to virtualize the hardware, this approach is much more lightweight than the VMs one, plus since there is just one operating system running in the server, the maintenance of that OS is also reduced (vs a VM that should maintain the OS of each instance).
Finally, all this containerization is really cool, but as the systems increased in complexity, it became harder to manage them. And this is where Kubernetes came to the rescue. Kubernetes is a framework that helps us orchestrate containerized applications by controlling resource allocation, traffic management, and many other tasks that would take DevOps a lot of time and energy to do so. Below, you will find a short summary of the components that, in my opinion, are more relevant to get a high-level overview of what Kubernetes is.
A brief Kubernetes summary
I like seeing Kubernetes as a set of components that live inside a box. That box is the famously known Kubernetes cluster. A cluster is composed by a set of Masters and a set of Nodes. The set of masters also known as the cluster control plane can be seen as the brains of the cluster, and is responsible of allowing the outside world to communicate with the cluster, ensuring that the desired state (which apps should be running, how many replicas, etc…) and the observed state match, and assigning work to the nodes.
We said that nodes are the ones that get assigned work, and what this means is that they are the ones that will execute our containerized applications. They are also responsible to report back to the cluster control plane and make sure that our applications can communicate with the outside world.
When I mentioned that the nodes will execute the containerized application, I was not technically correct. Nodes execute Pods, which represents a single instance of a running process in the cluster that runs one or more of the containerized applications. A straightforward way to think about a Pod is to see it as a worker. Is where your application lives and does its work.
Pods are managed through Deployments. A Deployment allows you to define a set of identical Pods through a declarative manifest and it will ensure that the observed state matches what you want. It will also make it easy for you to rollback to previous versions of your Pods (by moving to a previous Deployment).
One shouldn’t rely on a specific Pod living forever. Deployments can destroy and create Pods to match the desired state. So, even though a Pod gets assigned an IP and another Pod could technically communicate with that Pod through that IP, we shouldn’t rely on that. In other words, if we have an app running in a Pod and we want it to talk to an app running in another Pod, we shouldn’t rely on that IP address. Why? Because perhaps that target Pod has already been killed and replaced with another Pod, with another IP address.
Kubernetes solves the complexity of communication in a world of impermanent Pods by creating an abstraction, called Service, that represents a set of (the same type) of Pods. Cluster components (and the outside world) don’t communicate to Pods, they communicate to services (which has a static DNS label/name), which act as a load balancer to send the requests to a specific Pod. So, imagine that I’m a Pod running a React app, and I need to talk to my Node.js back-end, which lives in another Pod. My request would be done to the Service that is wrapping those back-end pods, and the Service would just choose one of the Pods to handle my front-end request.
Alright, that’s enough for now. I’ve talked about what are, in my opinion, the most important Kubernetes components to understand how it all fits together. If you are a visual person, here is a diagram that I made and I hope you find it useful.
👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.
Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬
