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
Tough one to simplify, but I’ll give it a shot.
Normally software works directly through the hardware that makes up a computer – processor, RAM, storage, input and output devices (keyboards, mice, monitors, printers, etc.). However, this is normally a big limitation since you can only run one operating system and set of programs compatible with that operating system at a time. If you want to run something else you either need to go use a separate computer, or potentially have a “dual boot” setup where you choose which operating system to run when you start up the computer.
Many years ago someone came up with the idea of virtualization. Virtualization is a program that runs inside of an operating system just like any other program, and contains a lot of instructions that allow the program to permanently borrow some of the hardware of the computer, and you can then install an operating system inside of that software environment. Cue Xzibit – yo dawg, I heard you like operating systems so we installed an operating system within your operating system! You may do this so that you don’t have to have multiple computers running one thing at a time, or have to reboot the computer to switch back and forth, super handy!
Kubernetes is an evolution of virtualization. With traditional virtualization when the virtual PC is running it constantly walls off the hardware it needs to run from the rest of the system. This is particularly annoying in server environments where you may be running multiple virtual machines at the same time on one set of hardware, because some of them may be sitting idle while another is running really intense processes, because the hardware allocated to the idle machines can’t be given over to the one that’s running a lot of stuff. This means you might run into a bottleneck situation where one machine is running a task that’s using all of its allocated resources, and it COULD run faster if it could use other resources, but it’s not allowed to. This means you either have to WAY over-build the server these machines are running on, or have a lot more servers than you would probably like in order to avoid each virtual machine from maxing out its own resources. This is very expensive and very inefficient.
Kubernetes instead of giving each machine it’s own individual set pool of resources uses a common pool. From this common pool it can give each machine exactly the resources that it needs on the fly if other machines aren’t using those resources. Once the process is finished, the resources go back into the pool to be used elsewhere. This makes scalability of virtual machines much easier, particularly in regards to cloud-based software and services because you no longer need lots of physical servers with lots of hardware running to ensure that each virtual computer can run at a reasonable pace. Instead you can run fewer servers, and allocate the resources in that server much more efficiently on an as-needed basis.
Furthermore, you can group these servers together so that in the event that one server does reach its max load, another server can come online automatically and take some of the load off the first server.
Kubernetes is most often used in conjunction with what are called containers. Containers are like a virtual machine, but instead of an entire computer with an operating system and all that, it’s a single program with the dependencies and data files that it needs in order to run. What containers do well is ensuring that no matter what computer you run it on, the program will run exactly the same as on any other machine. If you’ve ever installed a program and watched the install process you’ve probably been prompted to install something like a .net or c++ redistributable package – without these the corresponding program won’t run right or at all, but also they’re annoying to keep track of. A container allows you package these with the program files directly so that you don’t need to worry about whether the end-user’s machine installed these packages. In conjunction with Kubernetes you can make this program widely available over the cloud or internet, and it will run exactly the same for every user every time regardless of what hardware or underlying software is installed for that particular server.
First I have to mention containers… those are sorta like virtual machines, but they don’t fake the hardware of a real server and instead just run local (Linux) apps in a sandbox on the same PC. So a container can’t directly run windows and windows apps, though the apps inside a container could itself run a virtual machine or a windows app launcher which exists as its own app.
Kubernetes’ job is to run on many different servers, take a listing of containers and how they are to be run from the users, and run them on the cluster of servers. It chooses which real server will run jobs, sets up the container, and runs it. It also does things like detect when a job is getting busy and run another copy to take some of the load off the first machine, etc. If a real machine crashes, all the containers that were on it will be restarted to new ones. And all the other things needed to take care of the containers.
If you’ve heard of applications like VMWare ESXi, or OpenStack, or Amazon AWS, these run virtual machines in much the same way. But Kubernetes runs containers instead.
If you can build your applications, jobs, etc as containers, you can just hand it over to kubernetes telling it “I need 20 copies of this running”, and it’ll find 20 servers to run them on. And you can just watch as it works to find homes for all 20 and get them running. And pretty much all apps *can* be run as containers, it’s just a matter of setting it up.
First off, I’m not an expert.
Kubernetes supports “distributed systems,” which for simplicity is a group of computers running many software. The reason this is great is it allows for efficient usage of your computers. If one piece of software gets a lot of traffic (think a website that just got blasted on the front page of reddit) then you simply take resources from other pieces of software. Kubernetes let’s you do this automatically with your software.
A little more details as to why Kubernetes is used so often is because a lot of software is now split up into microservices. This means that parts of your software is isolated from other parts. For example a video game may have microservice for logging in and then another for matchmaking. These are usually put into containers which I won’t get into and then managed by Kubernetes.
TLDR
Software is built in parts and Kubernetes scales those parts for multiple software to meet user demand.
Simply put, Kubernetes automates a lot of the stuff you need to do to keep a website up and running. This includes deploying new changes and restarting servers when something goes wrong. Also adding new servers or taking servers away depending on load.
Digging a little deeper, a modern website usually has a bunch of components behind the scenes. Things like web servers and databases. Kubernetes lets you define the components, how big each component is, and how they talk to each other.
With this, Kubernetes can automatically do things for you like restart servers that are working slowly or throwing a lot of errors. It can increase the size of individual components and deploy updates. Before Kubernetes these were usually done manually or using a mix of different tools and custom scripts. Kubernetes basically combined most of these into a single management system that is more uniform across the industry.
I like to describe kubernetes as a puppet master for containers and related infrastructure. I also like to describe kuberneter as ” the worst container orchestration engine, except for all the others that came before it.” With apologies to churchill
Kubernetes is like the cargo director at a port. When it comes to servers, you can package a server (e.g a web server) into what’s called a Container. Kubernetes in this case knows which containers need to be running, manages workload to bring new containers online (e.g traffic to your web serve increases so you spin up more copies of the container) or down (traffic goes down) and makes sure the Port is running smoothly.
In short, Kubernetes allows system admins to manage server workloads without having to physically add/remove servers. Kubernetes does the turning on and off of new servers as needed.
Basically it let’s you combine multiple computers (their capabilities) into one “cluster” then treat the cluster as a single (more capable) computer.
So instead of running programs A and B on one computer and programs C and D on another computer, you run everything on the “cluster” computer.
Imagine you want to ship stuff overseas… like a lot of stuff. You could get one big boat and throw all the stuff in the hold. This actually works really well for something like oil… no harm in that! But it’s kinda a mess if you want to ship some trinkets, Nike knock-offs, and blankets all at the same time. Or, you can use a bunch of standard shipping containers of that boxy size, each with a focused kind of stuff, and pile those on some boats — that’s the Kubernetes way! Instead of shipping its “running software” but at a ELI5 level that’s almost good enough. It’s important because it drastically reduces the logistics behind doing stuff, which turns out to be really important!
Like most things in the industry, it has simply risen to be the popular way to do a particular thing. Just realize everything Kubernetes does you can achieve yourself through scripting and using other tools. But what it does is simplify a lot of the process of managing deployments. And not deployments in one place but across places meaning physical hardware in data centers and providing access to them. Even using Kubernetes there is a lot of work an individual has to do in different tools such containerizing scripts or provisioning hardware Kubernetes then lets you orchestrate or control all that from one place. Including giving access of different distributed systems to different teams of developers as well as giving them some ability to control what is being ran on those systems ‘easily’. To me Kubernetes is an orchestration tool for managing the DEPLOYMENT of distributed software.
It’s a little self-contained virtual machine that you can set up exactly how you want and ship it around.
Latest Answers