A container image is a lightweight, standalone, executable package that also encapsulates everything that is needed to run it. This would include code, the runtime, system tools, system libraries, and settings.

This definition comes from the website of Docker, which of course is a market-leading container firm. Consider a number of containers running on top of the same OS kernel. Each one of these containers will then, effectively, have its own little environment and executable files, as well as the entire runtime set up. Each one of these containers can be created by using a software such as Docker. Docker can be thought of as a kind of CD tool that takes in your code and outputs a container that can be carried around and run in its own little sandbox. Containers differ from VMs in some important ways, but the basic idea is fairly similar. Individual containers are often in the Docker file format.

In the case of containers, right below our individual containers lies Docker, which, as we know, is an open platform that allows folks to build and run distributed applications in the form of containers. The crucial bit though, is that Docker runs on top of the host OS, which means that each individual container does not abstract the OS. In contrast, in the case of VMs, we can see that each VM has its applications, libraries, and a guest OS. Beneath each of the VMs lies the VM monitor, or hypervisor as it is known. This is a piece of software that should be created by a company such as VMware for instance, which ensures that one or more VMs are able to run on the host machine and interact with the hardware and the other infrastructure:

In effect, containers add one further level of indirection to your code. This makes them different from VMs because we virtualize the OS. For instance, in the previous block diagram, Docker was acting as a proxy between the container and the OS.

In a VM, on the other hand, every VM has its own OS that talks to the hypervisor and that hypervisor VM monitor is, in effect, virtualizing or abstracting the hardware. Now it's pretty clear that a VM needs to lug around its OS within it, which makes it a little less portable and a little bigger in size and slower to boot. In general, a virtual machine is definitely more heavyweight than a Docker container, because a VM contains the whole OS (including kernel) while the containers only contain an abstraction of the OS (while using shared kernel). For those of you who are not familiar with containers in general.

Hence, VMs tend to be an order or several orders of magnitude bigger than containers and they are also slower to deploy and get started with. Here is a quick comparison between the two–GCE and GKE.

GCE instances are VMs, like those on the right. GKE clusters host containers, like those on the left. This is an important distinction: