Anyone who works in IT, in any capacity connected to software will have heard Kubernetes more than once.
While the answer is obvious to anyone in the prog/dev space and many people outside, for others it’s really unclear. People keep trying to explain it to me but it sounds like gibberish. please ?
In: 483
At its core, Kubernetes excels at achieving desired state. Let’s say I always want 3 instances of my web application running for high availability and performance. I tell Kubernetes that and it will always try to have 3 instances running.
I’m skipping a lot of stuff like containers, clusters, and software defined networks but basically that’s what Kubernetes is, an orchestration engine for containers.
The goal was to run applications in small spaces that could be quickly launched, stopped, etc.
People first solved this problem by using Virtual Machines. They have lots and lots of features to give you independence from the OS. Move your app from Windows to Linux to Unix-*? No sweat – VMs make it easy.
Them somebody thought that
1) VMs are still big enough to be cumbersome
2) VMs are big because they have to give OS independence
So they created Dockers, that do assume an OS, but they are far smaller and nimble than VMs.
Then they added Kubernetes to monitor and administer Dockers – kinda like how to use AWS consoles to track all your AWS services and objects and whatever.
Many great answers. I’ll add one with a different spin.
Kubernetes is the Operating System for the cloud, just like Windows/Linux/MacOS is the Operating System for your computer.
A traditional operating system exists to manage resources (how much RAM should your browser get, how much CPU should your game get etc) and that’s the same thing that Kubernetes does for the cloud.
Kubernetes allows multiple computers (nodes) to be thought of as a single, large computer.
It is hard to explain ELI5 because it depends on understanding abstractions that are decidedly not ELI5. The best explanation that I have is that hardware virtualization, so your traditional VMWare, virtualizes the hardware. You install an operating system by faking hardware to it, allowing you to run many independent computers on one piece of hardware.
Containers, the concept underpinning things like Kubernetes, virtualizes the *operating system*. So you install an application as if it is going into a regular environment, but really it is a container that is faking the OS. You can run many different applications on the hardware, each application *thinks* it is getting a fresh OS to install on, but the reality is it is a container. That way container A that has dependency c,d, and e can run on the same hardware that has container B that has dependency f,g,h that would typically interfere with application A. Yes, you can do this with hardware virtualization, but that is a heavier lift. Provided both applications can run on the style of OS as the host, you can load a bunch of containers providing each container a special little OS environment just for them.
The practical application, the fantasy, is that it allows developers to rapidly deploy applications including all of the dependencies directly to the environment without needing to wait for someone like me to prep it for them.
The reality is a little less rosey. Kubernetes is complicated, not a hell of a lot of people are good at it. “Images” tend to grow old and stale and contain a bunch of security holes no one is brave enough to address. There are pros and cons, don’t let anyone tell you that you can fix all of your problems if you just migrate to containers/Kubernetes. It isn’t all pro and no con. The pros might be worth the cons to you, but don’t fall for the hype.
TL;DR; It matters because Kubernetes is where the programs that run the company are running. Getting into all the reasons we want to run our company’s programs on Kubernetes is the part that is very difficult to ELI5 because there are a lot of features that make it useful over alternatives.
I am going to get into one reason for Kubernetes.
Instead of ELI5. I am going with explain like you are not in IT, but know a little bit about the computer your work or play games one. First, for the last 10 years or so, computers and even the phone you are posting to reddit on probably has 4-8 cores for running programs. Some programs can use several of those cores on their own. Some programs can only use one core, but since there are typically many programs running on your computer or phone it is still useful to have extra cores.
One other thing to add, is that it is extra work to develop a program to use multiple cores effectively. And, for many program it just isn’t beneficial.
Enterprise servers, to reduce costs of administration, power efficiency, and space savings, typically start at 32 cores and can have up to 192 cores in a single server. And, that number keeps going up. If we try to run the programs that a big corporation needs on one of those servers directly like we do on our PCs, either we are coordinating with a lot of people to make sure their programs won’t interfere with each other or we are wasting a lot of computing power.
This is where virtual machines come along. A virtual machine looks like a real computer to someone using it, but is actually just some of the computing power of the gigantic server described above split off to look like a separate computer. This is good because now each team who needs to run programs can have a virtual machine and don’t really need to coordinate with each other.
But, each team is still trying to figure out how many virtual machines they need and which programs to run on which virtual machine, and trying to do that efficiently, so they don’t waste money on computing resources.
I am not going too much into containers, read other responses. For purposes of my response, think of containers are a way to package a program for a computer to run.
Kubernetes runs these containers. The magic of Kubernetes is that you give it a container, tell it how much CPU and RAM that container needs (and several other pieces of information) and Kubernetes finds a place to run it on its pool of many virtual machines and/or servers. And, that is why it matters so much… Because that is where everything is running.
There are a lot of features of containers and Kubernetes that explain why we want to use it to run our programs. But, in answering the question “why does it matter so much”, it is because it is where we run our programs.
Kubernetes is software that manages the infrastructure that other software runs on. It’s considered to be an orchestration system, which means it’s a central control authority that governs a collection of others systems. It manages things like networking, resource allocation, updates, etc.
In many respects Kubernetes does analogous jobs to what the operating system of a single machine does, but it’s an operating system for a distributed collection of machines instead of just one.
Kubernetes is like a ship loading dock. Shit is put into containers and placed on a ship where they remain until another container with newer shit replaces it. And there is a guy who knows which shit goes on which boat that yells to everyone else through a big megaphone. If a container with some shit falls into the water, the captain on the ship yells to the guy with the megaphone that he needs a new container with shit on his boat.
The simplest analogy I’ve heard (to be fair you need to already be familiar with the concept of docker images etc) is that’s if you imagine docker containers as ACTUAL shipping containers, then kurbenetes is the SHIP those containers have been loaded onto.
The name kurbenetes itself comes from the ancient greek for helmsman/pilot, so clearly Google had this analogy in mind when they created it.
Applications are bananas. You need to ship them to customers.
When you’re only going to a few places, you can just load up the bananas directly on the ship.
When you have lots of destinations, it helps to put them into standard containers. That’s docker.
When you have to do a lot of loading and unloading because banana demand keeps changing, and you only want to pay for full containers, you employ a dockyard crane to fetch and load containers. That’s kubernetes.
I think people are trying to encompass *everything* that Kubernetes is.
At the basic level, it’s a way to not have to manage your own machines. In the old days* you’d have a bunch of servers and you’d deploy your application to a couple of them.
If something went wrong anywhere in the running of the application (hardware failure, contention issues with other apps on the same server, bug in your code causing the program to crash) it was a manual effort between both sys admin and the app owners to ensure the app was brought back to a healthy state.
Unsurprisingly this doesn’t scale well on its own, so people built tools to manage problems that can occur and automate fixing them.
Kubernetes is one of the more successful attempts at this. The biggest change being that everything is kept in its own “container”, which is a nice little box around applications that make them as unlikely to break anything else on the server as possible. That means sys admins can focus on the infra problems and app owners can focus on the app problems.
* In the tech world, like 3-4 years ago
Latest Answers