Kubernetes: A Brief History

By Andrew Murray

Recently, I presented an overview on Kubernetes: what it is and why it got willed into existence in the first place. This is the first step in a series of deep-dive Kubernetes presentations he has planned. If you’re exploring Kubernetes as an option-or you love it and want to learn more-let’s start with understanding “why.”

But first, so we’re all on the same page …

What is Kubernetes?

The quick version? Kubernetes is a Container Management Platform used to run applications, leveraging platform-as-code patterns and normalizing Cloud Resources.

Let’s break that down.

First it’s a Container Management Platform, which means it manages bundled applications that have all their dependencies. When we talk about Docker images or Docker containers, they’re just applications that are all smashed together but self-contained.

The platform that manages these containers makes sure that the container is healthy, that it’s online, and it’s connected to the right resources.

Platform-as-code defines compute environments, like servers or just computers that are running applications as code. When you define something as code, you are taking away the need to manually configure settings and variables-or set up resources within these computers. Instead, you can provide a file or configuration written out just like you would program an application. Then, when you give it to the computer or server, it automatically does all those tasks for you.

This refers to resources given by providers like Google, Amazon, Microsoft for their clouds. But it can also include private systems. The main indicator of a cloud resource, or just a cloud, is that the servers or computers that make up the cloud are divisible and usable by multiple users on-demand and without exposure to each other.

The best way to understand why Kubernetes exists is to think about what we actually had to do before it existed-the problems that we’ve faced with getting applications hosted that led to Kubernetes being as dominant as it is.

The Dark Ages of Traditional Deployment

This is what the Internet 1.0 age had to contend with, leading up to virtualization. The whole process of traditional deployment was rather involved:

1. When creating an application, a developer or system admin. would have to prepare a computer/environment to contain all the dependencies that an application needs to run, making sure all the dependencies are there, make sure that the ports are open, so traffic from outside of the computer can come in and talk to it.
2. Operating systems, other installed programs, system permissions and other differences between operating systems like different amounts of hard drive space, RAM, CPU speeds, etc. made this a very difficult and varying task; which makes it hard to automate and easier to cause errors.
3. For production systems, there’s really no good indicator that the computer that you’re deploying into production would actually be able to support the application, since there could be key differences between the computer on which you tested your app and the production server.
4. When these applications run, they share a pool of resources on the system that are finite and have no protection from an application over-utilizing these resources. In fact, these applications could actually steal resources from each other. If you have a web server that was poorly written and it is a memory hog, it’s not letting go of those memory resources, it could eventually steal those resources from the database or from the API, and then you’d have these cascading failures that would be difficult to diagnose.

For obvious reasons, this wasn’t sustainable.

Age of Virtualization

So a new era dawned: Virtualization. Suddenly, you could “virtualize” a single computer to allow multiple people to share its resources without allowing for communication between each other (increases security). However, you could also define an allowance of resources at a high level to help prevent an application from hogging resources.

There’s a term I like to use called VMs, Virtual Machines. When we talk about virtual machines, this is the concept of virtualization. It’s defining the computer resources as code. You can have multiple operating systems running. They can’t talk to each other, but they’re using the same bare metal, the same computer, which allows you to make specifications at a high level. For example, you may say, “This VM can get one full core and one gig of RAM. This one can get two cores and two gigs of RAM. This one has very little CPU core use and a little RAM use but gets access to the hard drive to store data persistently.” This allows for a lot more packing of applications onto servers without adding security risk or resource-stealing risk.

But even in this age, applications inside the same virtual machine could steal resources from each other, because they’re operating from a set pool. And, when standing up these VMs, you can provide them as code but you’d still have to prepare them like other machines. It’s easier because are more uniform, but it’s still a tedious process to make sure all the dependencies are there.

So innovation continued and we entered…

The Age of Containerization

At the very beginning of the web 2.0, applications became more complex, which made VMs less sustainable. We needed something that could be controlled at the application level.

This is where we see The Age of Containerization come in.

Docker is the really famous container. It’s the one that dominated the space. And what Docker does-or what containers do-is allow you to create the application to have the same resources across compute environments, because everything an application needs is baked into the container as code.

And since containers are deployed within the same OS, you gain better utilization of resources because you now can pack more applications into a VM without worrying about resource hogging.

No matter where you run your application, it’s going to have the exact same environment on any machine, which really standardizes the way that you can stand up an application. When you test on your local computer, it is just as good as the production environment, because the production environment and the local computer will get the same container, and everything is self-contained within that container.

With containerization, there are tools now that make it easy to run containers within virtual machines, but to actually communicate all these things into the outside world, and to share secrets, was still as cumbersome as setting up the computer in the age of traditional deployment.

This is where orchestration comes in.

The Age of Orchestration & Container Management (and Kubernetes)

Now we’ve reached the age of Kubernetes-the age in which you can specify how multiple containers can exist together, communicate between each other, and communicate to the outside world. They’re synonymous with each other. We’ve gotten to the point that every application can run within different environments in the same way.

In fact, Kubernetes allows you to specify a platform made out of multiple containers as code and manage it completely. It has health checks built in to make sure that the application you want to run is running or has started up correctly. It allows a very simple procedure to deploy these applications, make changes, or rescind your previous command to roll out and automatically roll back with one command. It even provides resources outside of what containers control.

What this gives all developers is something a bit more approachable and more control over how applications are run within “production” environments.

Simply put, through continual problem-solving, we got to the point where we needed Kubernetes to extend the simplicity of running a complex application to an additional degree from where Docker Containers left us.

Now that Kubernetes is here, however, it’s time to move beyond the why and start exploring how this powerful tool works and who can best leverage it. So stay tuned as we publish additional pieces in our tutorial series. And if you have questions along the way, don’t hesitate to reach out anytime to hello@metarouter.io. We’d be happy to connect directly!

Header photo by Sebastian Herrmann on Unsplash

Originally published at https://blog.metarouter.io.