I don’t have a computer science background and I often hear people talk about containers and Kubernetes. I frankly have no idea what it is and how it is different from a virtual machine (remote computer). Would like to understand what this is and why it is useful.
In: 1
Not really something I can explain to a 5 year old but, virtual machines create an entire virtual computer including software and hardware such as hard drives, operating systems, keyboards, network cards, sound cards, etc. Thats a lot of stuff to virtualize so it can be pretty slow and intense to have many of them at once.
Containers only virtualize the software they are told to run. It doesn’t virtualize any hardware like hard drives, or network cards. It just uses the actual host hardware. It doesn’t even virtualize an operating system. This means containers can only run the same OS as the host. If you are running a container in a windows system, the containers will also be windows systems. Because of this, containers are a lot faster.
Essentially a host creates a sandbox (the container) and says you can use the tools in my (the host) sandbox to make your sandcastle, but keep your sandcastles out of my sandbox.
Kubernetes is just a program to manage those container sandboxes. Does the sandbox need to be bigger? Does it need more tools? Does it just need more sandboxes? You would accomplish these in Kubernetes. It gives a graphical user interface which is easier than writing long commands in a terminal for every change.
The main difference between a VM and a container is how deep they go with their virtualization. A VM virtualizes everything down to the hardware layer. Everything that runs in a VM is the VM’s own stuff. It brings, loads and executes its own kernel, its own drivers, its own everything. A container on the other hand shares a lot of its lower level processes like the kernel with the operating system that it runs on. It doesn’t deal with hardware itself, it lets its host operating system do that for it. Which makes it much, much lighter than a full on VM.
What containers allow you to do is package entire environments in a convenient, well, package, which is isolated from the rest of the system (except for places you don’t want it to be, of course). Say you wanna host a database server. No need to set up an entirely new VM, install the required software packages, and configure them. You can just fire up a container that comes with all or most of the necessary binaries already installed into it and configured for an easy and fast start. Makes things very convenient. I mean you can also pre-package your own VMs for it, but as mentioned above, VMs are much heavier than containers. You don’t want to be virtualizing an entire system and loading an entire kernel and whatnot just to host a new instance of MySQL, which you don’t have to with a container. That lets you use your hardware resources much more efficiently.
Kubernetes is a system that organizes and coordinates multiple containers to operate a single service. Say you’re running a web application for a company. You have many servers distributed around the globe to optimize your website’s speed and performance for your users. You package the required software for your backend into neat containers, ready to be fired up in a moment’s notice wherever they’re needed. That’s where Kubernetes comes in. You set it up to determine where and when new servers are needed, and to create new instances as necessary. When demand blows up, it automatically starts new servers and integrates them into your network. When demand goes down, it trims down the number of servers to a more reasonable level. It’s like a manager type guy at a grocery store who determines when to open a new register and when to close them, based on how long the lines are.
When looking at a single computer (that is, either a virtual machine or a regular bare metal machine), there are certain things that you think of as “global”, shared across all the whole thing. From a networking standpoint, 192.168.1.5 refers to the IP address on a specific network card which all services can use, only one program can listen to TCP port 80, and no matter what program asks for it “C:hello.txt” refers to the same file on the same hard drive/partition.
Containers use features in Linux to say No to all of the above. There isn’t a single TCP/IP stack but programs can make new ones somewhat freely, in which it is possible for a new program to listen to TCP port 80 because it’s not the same network stack as the original one. Filesystems and disks can be unmounted and moved around because there aren’t programs relying on them because the new disk layout is separate from the original. PIDs are re-numbered starting from 1 again under a different umbrella of processes. And a bunch of other things.
Normally these features are all separate – network, disk, host identification, PIDs, inter-process communication. Chrome uses them for parts of its sandboxing. But if you hit all them at once, you could create something that looks very much like a virtual machine to the untrained user, with their own private files, only their own running programs listed, and able to run any network service without colliding with another user.
Doing this we commonly call a container. It’s a lightweight virtual machine that’s a bit restricted – you can’t load custom drivers because it’s still the same kernel as the host and all other containers, but whatever app you want to install on Linux will largely just work within it.
There are 2 major classifications of a container: operating system containers, and app containers. An operating system will boot mostly normally for a Linux host and have a login screen somewhere even if you need some tool to reach it. Whereas an app container isolates a single application/service within the container leaving little else installed. In the latter example the container software would be required to set up the network settings in the container because there’s nothing installed within it to do so, or even the real system network would be retained and the contained app just uses that instead.
Which leaves us with Kubernetes, which is broadly speaking a management engine for containers in much the same way VMWare ESI is a management engine for virtual machines across clusters of hosts. When you need another container started, it will take care of it. Things like saying, “Oh, the web server is busy, start another copy on one of our container hosts automatically”.
* A container is basically a lightweight virtual machine.
* Kubernetes (also known as k8s) is software for managing containers; you tell it what containers you need running and it starts them up for you. It can do things like checking that they’re still running (and restarting them if they crash), or managing upgrades to a new version of the container by restarting them one by one, etc.
Latest Answers