Kubernetes has been the tool of choice for devops in the IT industry, since 2014, without ANY competitor.
But what does it do, exactly?
Well, by the end of this article, you will fully understand:
- When it’s useful and how much it can improve your projects’ turnaround time.
- How to tackle it and what aspects to consider when implementing it.
- Whether it’s too much of an overhead for your project and if you’re better off without using it.
So let’s start with the most important question — Why do we even need Kubernetes?
So Why Do We Need Kubernetes?
The Purpose of Kubernetes
A modern web application ecosystem (usually for big complex projects) makes use of multiple containers. (We’ll get into what a container is later in this article, don’t worry!)
The containers need to be herded and managed so they do the right things at the right time.
The name Kubernetes originates from Greek, meaning ‘helmsman’ or ‘pilot’.
And that is exactly what Kubernetes does!
It orchestrates everything that happens with those containers at the right moment.
Think of it this way:
Kubernetes is the conductor of an orchestra. And each instrumental player is a separate container.
When the trumpeteers end their part of the song, it’s time for the violins to start theirs. When the violins get to a certain part of the song, the conductor signals the percussionist to switch to a different drum part.
Kubernetes runs the show!
All the containers start and end processes when Kubernetes signals them to do so.
From simple things like changing storage information — to more complex processes like server load balancing.
The ‘orchestra’ is the collection of containers that work together in a predefined order.
And Kubernetes tells them what that order is.
Let’s dive into what a container is exactly…:
What is a container anyway?
A container is a ‘place’ in which your web app is located (with all its’ files and folders). The container is what starts up and keeps your app running in the first place.
Now, you may be asking ‘isn’t the computer the place where my apps’ files are being kept and which keeps my app running?’
Yes, that is correct — on the physical level.
Now let’s get deeper down the iceberg.
On top of the physical computer (the hardware) you have the software level.
Firstly, you have your operating system — your macOS or Linux or Windows.
…and here is where things get interesting.
The schema above is the same one found on the official Kubernetes documentation.
Running apps on servers — a.k.a. deploying them — has evolved in the last decades. Nowadays you can run more apps while using less computing power.
This evolution of software deployment has three stages:
Traditional Deployment
The basic way of running an app on a computer: you have your computer, on which you have an operating system installed (macOS, etc.).
From there you just have to start an app just like you start Excel, Word, a video game, etc.
And you have your app running!
Multiple apps at the same time, even — or the same app running multiple times.
It’s quite straightforward.
Virtualised Deployment
So, why did this new way of deploying apps come to be?
There are a couple of reasons:
- The need of running multiple instances of the app at the same time
- The same deployment process for each remote developer (to reduce unexpected errors)
- Multiple instances of databases or other complementary apps we need in our project
And this is where virtual machines come into play.
The problem is that they carry a huge overhead — an operating system for each deployment.
If only we could strip the extra operating system layers from our diagram…
And this is where we finally introduce containers.
Container Deployment
In this configuration, you’ve got rid of the Hypervisor (the app that runs operating systems) and replaced it with a Container Runtime (docker, containerd, etc.)
The container runtime creates containers, which are isolated environments for your apps, code, and anything else your app needs (databases, etc.)
The containers make use of your base operating system and of your computer’s RAM and disk memory on a need-to-use basis — so it reduces wasted resources, unlike virtual machines.
Now, by using isolated environments, we have a predictable and repeatable deployment process that doesn’t make heavy use of hardware resources.
Containers are powerful and lightweight. They can even be created in the cloud and provide a two-way screen via your web browser.
Want to test operating systems at a whim?
Visit www.distrosea.com.
From there, it’s as easy as choosing the operating system you want on your container and clicking start.
How It Works
Kubernetes is actually composed of multiple parts. These parts are called nodes. A node may be either a virtual or a physical machine. And together they form a cluster.
The Kubernetes cluster is formed of:
- A master node
- Multiple worker nodes
The master node is a server which manages the worker nodes.
You, as a developer, can connect to it via an user interface, a web api or a command line interface and configure the kubernetes cluster via the master node.
The worker nodes are the ones that hold the containers of your apps.
Now that you know what containers are, and how they are managed by Kubernetes, let’s explore an example of a real world use case.
Real-Life Example
Imagine you are building an app that recognises different species of flowers.
You built a prototype on your own computer. But now, it’s time to make it available to the public.
Using Kubernetes will give you all the control you need to keep your app performing well which in turn will keep your clients satisfied.
If too many users access the app, therefore the traffic will slow down the container.
In this case, Kubernetes will detect this and automatically create a new container and distribute the traffic to the new one as well.
Problem avoided!
You may want to use multiple storage systems, such as AWS, local storage, etc. Kubernetes enables you to change that on the fly, depending on your apps’ design.
Maybe, you update your database of flower species continuously, or you provide an app update each week.
Kubernetes will schedule the creation of new containers (for the updated app), redirect traffic to them and shut down the outdated containers.
If you know how much CPU and memory (RAM) each container needs, you can easily specify that within Kubernetes and it will take care of it for all subsequent containers.
If a container fails, because of traffic overload for example or an error, Kubernetes will replace them with new containers — this way you prevent unexpected downtime.
Passwords, SSH keys and other sensitive data can be stored within Kubernetes so that it isn’t exposed in the container itself, keeping it safe from hackers.
By using the features of Kubernetes, your flower species detector app will run smoothly and serve users as efficiently as you configure it!
The Pitfalls of Using Kubernetes
It Has A Steep Learning Curve
You need to spend time building a good understanding of how it works and how to configure it properly. This takes time and if you have just started building your app you could make better use of spending that time on building the app itself.
Requires Planning Ahead Of Time
An app that runs on a containerised architecture needs to be structured in a specific way. This entails extra time on planning out the app and it’s devops components (we’ll see a simplified example later in this article)
For a small project this time could be better used on building the app itself.
You Might Not Use Most Of Its Features
A lot of features will end up unused, including security measures, computer resources, cloud storage, etc.
And spending time and money on training, app restructuring, updates and maintenance would not be a priority in many cases. Most projects that do not require the advanced features of scaling on multiple containers would work as well on a traditional deployment approach — the one we presented earlier in the article.
Do You Really Need It?
Is Kubernetes a mandatory tool to use nowadays for web developers?
It depends on the size of the project.
If you are working with a complex piece of software that spans across a large environment and requires container automatisation, then Kubernetes will probably be very helpful.
This is what a streamlined pipeline of building apps using containers would typically look like:
It’s important to note that this workflow is optimised for big projects involving multiple developers.
If you are focused more on building the app itself and especially if you are creating prototypes, you should probably not spend too much time on designing such a complex workflow and web architecture.
You might be better off using the bare minimum and focus on building the app itself.
What Now?
If you got to the end of this article, well done!
We had to dive into some technical aspects in the complex realm of web architecture in order to understand the role of Kubernetes. It wasn’t an easy feat, but now you know what Kubernetes does.
Now that you know where and why it is used, you should be able to know if you really need it or not.
If you’re not sure, you probably don’t.
So try not to spend too much time on things that will not impact the end result too much.
Good luck on building your web app!
