Kubernetes - what and why?

Hi there! It's been a while since my last blog post, where I covered the Certified Kubernetes administrator certification and my approach to getting certified. To continue on in the same manner, this post will cover what the Kubernetes is and why we (not always) need it.

What it is

Recently, I've watched the Kubernetes documentary, a two-part story (first and second part) about how Kubernetes was created, when and how it all started, and how it came to it becoming one of the building blocks of many applications and services we use in daily lives. I'm mentioning this because I really liked Kelsey Hightower's explanation of what Kubernetes is through the post office analogy, which I quote in full below.

Yeah, so if you take some real world examples around us… Let’s say, the holidays are coming up and you want to ship something to a loved one as a present. So let’s invent the post office. And the post office says: ‘we can ship things, but we don’t want you to bring loose things to us. We don’t want loose books and jewelry and money. No no. You need to put in a box.’ So if we extend this analogy, let’s put an envelope. Now there’s going to be a cost for me to move this from one place to another, and depending on how far it is and how much it weighs, I’m gonna give you a price and you can think about that like your stamp. Now, whatever you put inside of it is up to you. So the container can support any programming language. Ruby, Python, Java, Golang, it doesn’t matter. To make Kubernetes efficient as the post office, we need to ask you to put it in the box. Now, the key is you now have to describe where it needs to go. We need to put an address on it. Where does it run, who’s it destined for and how long would you like to take, or are willing to wait for it to get there? And so, if you think about it, the post office abstracts all that away from you. You show up with your envelope and your stamp and the address, and they’ll tell you, ‘well, this will get there in two or three days’. Planes can break down. Cars can break down, but no one at the post office calls you when any of those things happen. They make a promise to you, right? They promise that this letter will get there in two days. How they do it is not a concern. So Kubernetes is built on this thing we call ‘promise theory’. Even though you have lots of machines in your Kubernetes cluster, any of them can break at any time, but Kubernetes’ job is to make sure that application is always running, just like the post office’s job is to make sure that letter keeps moving until it gets to its destination. Kubernetes does that for infrastructure.

Let's dig deeper into this quote. First - the envelope. Your application needs to be in an envelope. That envelope in this context is a container. So you need to put your application within a container. Next up - the box. The box mentioned here, for the sake of simplicity, is the Pod. And what is a Pod? The pod is the smallest unit that you can deploy within Kubernetes. The important thing here to note is that the Pod can contain one or more containers. So it is a box for containers. The address of the envelope/box is actually the definition of the application itself - should it have some port opened, and persistence, should it be in one or several instances (replicas), etc. The cars and planes are the actual infrastructure behind it.

So in short, if you are a person developing some application, Kubernetes is there to help you concentrate more on the application itself, and not the actual infrastructure where the application is running. And if you are a person responsible for making that application operational and available to users, Kubernetes is there to make your life easier with various mechanisms like scaling up the application automatically in case the usage increases, automatically provision load balancer, etc. There are many options, which can be good, sometimes.

Why we (not always) need it

Okay, so we covered the "what" from the title, now we need to answer why do we need it? We already have the abstraction from the infrastructure which are VMs, various scaling mechanisms in the cloud such as auto-scaling groups in AWS, and other things, what is the point behind it?

From my point of view, and forgive me if it is a narrow one, but I'm trying to be as objective as I can, it makes our life easier when deploying applications - we can run our applications wherever we want – on-premise Kubernetes cluster or cloud provided Kubernetes clusters, and not worry about the underlying infrastructure, as long as we stick to the Kubernetes application definitions (for example pods). However, there is also another side of that coin that may not make it as easy as the previous side - the learning curve is a bit on a steeper side, it is a hyped technology that everybody wants in their setup, but it is not, and I cannot stress this enough - it is not always applicable. Also, there is a layer of complexity introduced which sometimes cannot be so good, or your application is more of a monolithic instead of a microservice-based application, so the migration to Kubernetes would not be as sensible.

There are always pros and cons for each setup, be it one running on Kubernetes or not. If the pros outweigh the cons in the evaluation process of Kubernetes, go for it. If on the other hand cons outweigh the pros, well, you might not like it, but your setup will not be as fit for Kubernetes as you might think. This will result in a lot of headaches and workarounds in the process of developing an application or migrating to Kubernetes, so I wouldn't recommend it.

In some of the next blog posts, I will dive deeper into what are some of the architectures you can easily run on Kubernetes, others that you will have trouble with, and how to evaluate if the application can be deployed or migrated to Kubernetes.

Now, to summarize the current story - even though the technology is hyped, new, and flashy, it doesn't mean that it is good for your use case. This applies to all of them, not just Kubernetes. A good evaluation process and understanding the technology are key.