What **is** Kubernetes?

I was challenged on Twitter to write an article about Kubernetes. Here we go...

Glossary:

Bandwidth: The capacity. How much data can be transferred.
Can also be a word used to describe free time by techy people "how much bandwidth do you have today?"
Load balancer: Something that...balances the load... of traffic to a site. Makes sure that data and traffic to the site are distributed evenly.

You're going to want to read my short What *is * Docker? article if you don't know what Docker is before we hit the road here. I know there are usually no prerequisites to my articles, but this is an exception!

There's a theme here...

Kubernetes is the Greek word for a helmsman or someone that steers a ship.

Hold that thought.

The scenario

Imagine you (and Randall, from the Docker article) have a site up and running with a Docker container. It's doing pretty darn well. You are getting a lot of visitors to your site, and business is great.
Sometimes, you get too many visitors to the site and it crashes...

Not good

Your site is starting to crash a lot - too many people are visiting and the server is just getting overstretched. It can't handle it.

What do we do?!

You set up another container on another server. That way, you've got twice the amount of bandwidth to play with, and in theory, you should be able to have twice the amount of visitors.
You also set up a load balancer to make sure that visitors are evenly distributed between your servers to ensure that there are no more problems.
Easy, problem solved, right?

Wrong

Your business is incredible, you go viral and suddenly you have a ridiculous number of visitors to your site. Everything is great!

Hold on...these servers can't handle it...
You set up another 20+ servers (just to be sure this time), which all need Docker containers and some extra load balancers to help manage the bandwidth distribution.

Note: This process is called Horizontal Scaling

This all takes a lot of work, and don't even think about making any update to your website...
This is putting a lot of pressure on you, and you are considering hiring another engineer...$$$$$$$$$$$

Or...

Imagine if you could automate this server/container duplication process...

Well, my friends, I have some news for you

Kubernetes

Ok, so, let's imagine that you knew about Kubernetes right at the beginning. You start to use it when you have just one or 2 servers running with Docker.

In Kubernetes, your Docker image (the server with the container and everything that you need to run your website) is called a pod
Kubernetes comprises of the 'master' (its official name) and 'worker nodes'.
The worker nodes do all the heavy lifting in terms of storing, transferring and receiving data around the sites and between the servers.

So, the premise of Kubernetes is like this:

1. You decide how many 'worker nodes' you want (typically the same number of servers that you have)
2. You give the 'Kubernetes master' (this is the official name) a list of the number of pods (servers) that you need in the form of a .yaml file. This is called the manifest.
3. The Kubernetes master takes a look at the manifest that you have given it and assigns the pods out to the worker nodes. Pods are assigned to the worker nodes depending on how much work they are already doing. Pretty clever, right?

You can control the number of pods through the command line and have direct access to information about your pods and worker nodes, such as their name, IP address and other info. You can also update the .yaml file through the command line with cubectl edit deployment and then your .yaml file name. Imagine it as handing a supervisor in charge of a workforce an updated task list. It is their job to make sure that work is distributed evenly and that no one worker node is over or underworked.
The master node monitors the amount of work that each worker node is doing - if anything looks like it is going to crash or become unstable, it will re-distribute the work. Smart, right?

Yes, but that's not all...!

So these pods that are created, and the images that are inside them, all have their own IP addresses. Great, they are all accessible to the outside world and each version of your site can be reached by the public, and by you, if you want to edit anything.
Wait...how can they be exposed if they are in a pod?

I'm glad you asked that. This is another powerful feature of Kubernetes.
For the outside world to be able to view your site, you need to expose the pods to the network. If you tell it to, Kubernetes will spin up something called a Service which will act as a load balancer to make sure that none of the pods are getting too much traffic (crash zone!)

The thing that makes it different to a usual load balancer is that Kubernetes will balance the load by pod ID, rather than just balancing across every server. This means that you can control everything with a lot more precision.

Doesn't sound that special...?

It also creates a load balancer in your cloud provider. This means that you update your website in one place.

Save yourself a lot of time. Orchestrate your containers!

Save even more time - managed kubernetes options - good to know...

While researching for this article, I found out how tricky and in-depth it is to set up. Luckily, there are managed options that do it all for you - Azure's AKS and Amazon's EKS.
If you need to get started with Kubernetes fast, say you've built the next Amazon using Docker containers and you need to future-proof
fast, then I recommend using them while you look into Kubernetes. It is very CLI-heavy and looks like it would take some time!

_So that was Kubernetes. So, now we know what it ** is **!