Kubernetes is a heck of a tech. Quite unique in its own way.
If you ask me, what is it exactly that Kubernetes is doing, I’m going to say: basically, it is creating a virtual reality for your app. Like its own little Matrix, where your app is sitting as mister Anderson in a cubicle (that’s before he became The One), and interacting with other apps over the internal network. And it doesn’t know that somewhere there, outside the imaginary world, there are servers, cloud providers, infrastructure that can go up and down, someone can add servers to create more “cubicles”, and whatnot.
That is what you want. You want your app to sit in one place you put it to, do one thing that it’s supposed to do, and know nothing about anything else. Because when it goes otherwise, you start hitting some classical walls:
Now, this certainly goes beyond just the usage of Kubernetes, and rather is about the architecture choices in general. Kubernetes forces you to use the architecture which would be as microservice’y as possible, that is, split your app in parts or services, each of which is doing its own job, and interacting with the other services. Yep, “cubicles”.
Why is this important? Well, imagine that you have a million dollars, and you put it in a bank account. But all of a sudden, tomorrow this bank crashes, and you cannot get your money back. If instead you put your money in several bank accounts (better in different countries), you could significantly minimize this risk. It’s the same with software components. If you have it all in one place, when one thing is broken, it’s your entire project that might be broken.
Instead, if something is going wrong in one microservice, you know exactly what to fix, without touching the other parts. If you need functionality added, it’s a subset of places that need to be updated, without a risk to get other things broken, and with less chance of a downtime.
Not only do you protect yourself on that level, but you also end up better safeguarded from hardware outages too. Kubernetes is designed to span over a cluster, i.e., a set of equipment joined together. If, say, you have 4 servers available for your app, and one of those servers goes down, a lot of the times Kubernetes will be able to reschedule all the components that are running on the problematic server to other servers. That with little to no downtime, and almost invisible to your app.
To give a more technical explanation of how Kubernetes handles such situations, we need to introduce a couple of core terminology items: nodes and pods. Nodes are basically servers - either items of physical equipment, or virtual machines allocated by a cloud provider. And pods are what the official documentation describes as "smallest deployable units" - in most cases they will have one of the microservices that your overall project comprises.
Kubernetes automatically handles the failure based on its scheduling and resource management features. It continuously checks the status of nodes and pods. If a node fails, the Kube Controller Manager, a component of the Kubernetes' Control Plane, detects this failure. If the node remains unresponsive, the Node Controller will start the eviction process for all the pods on the node. Next, Kubernetes scheduler will try to reschedule the evicted pods onto other nodes in the cluster. Finally, Kubernetes will create new pods to replace the ones that were on the failed node, trying to maintain the desired number of pods, depending on the configuration of higher-level Kubernetes structures, such as ReplicaSet, Deployment, and others.
You can see this flow on the diagram, which assumes you have 3 nodes, and one Master node:
This automatic handling of node failure is one of the reasons Kubernetes is so popular for managing containerized applications.
Like I said above, Kubernetes is a "virtual reality", which can be built on top of any “real world”: any cloud provider, or an on-premise architecture. Now what if you built some software which runs on AWS, but you have a customer whose privacy requirements don’t allow for hosting anything not on-premise - i.e., not on their own servers, which are located in their server room, or a datacenter of choice? Or, what if they say they don’t want to use Amazon and want Google instead, so you need to have everything hosted on GCP? With Kubernetes, you can simply re-create your cluster with the same internal architecture in another environment.
This is the area where Kubernetes, when properly used, can really play to its best.
Think for a second of the long-awaited, yet scary moment when you grow from 100 customers to 1000, 10000, or 100000… This growth is so desired, but the harsh reality is, it can also kill many of the projects, or at least make them realize the importance of the right tech choices in a hard way.
There may be so many tech things that need to be addressed when your project grows 100x or more, and they are quite unique case to case, but also may have a lot in common. For example, you have a SaaS that may need more compute resources to keep providing the same service level, only to more customers. And what exact resource are you bottlenecked by? Is it your database, your processor, or your network availability?
Kubernetes of course will not address these issues magically. But it will unlock the possibilities to scale smoothly, and with much less of a need to worry what next. If for example you’re going to need to add another server to the picture (which is a common scenario), Kubernetes will help you out a lot practically out of the box. Continuing with our metaphor, once the new hardware is connected, it will simply “extend” the boundaries of the virtual reality world to the new location, and your app components will seamlessly “enter” it. In other words, you give Kubernetes the space, and it knows how to use it the most efficiently for your benefit.
On top of all, Kubernetes can also bring some security benefits. Even without going any further, they proceed from simply better isolation of each component, and lack of the access of one component to the other.
But really, it’s much more than that. It’s the mechanisms that allow to define very fine-grained access to resources, it’s flexibility when setting up the network to strictly limit the communication and limit possible attack surface, it’s logging and monitoring, it’s proper mechanism of management of secrets (for example, logins and passwords and other keys), and much more.
At HighloadMe, we help you explore solutions for your project's architecture needs, with subsequent architecture planning, design, and development lead. Book a consultation with us today to discuss what’s best for your newly starting, or already existing and growing project.
