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.
Latest Answers