Containers and VMs are similar in their goals: to isolate an application and its dependencies into a self-contained unit that can run anywhere. Moreover, containers and VMs remove the need for physical hardware, allowing for more efficient use of computing resources, both in terms of energy consumption and cost effectiveness.

A VM is essentially an emulation of a real computer that executes programs like a real computer. VMs run on top of a physical machine using a “hypervisor”. A hypervisor, in turn, runs on either a host machine or on “bare-metal”.

A hypervisor is a piece of software, firmware, or hardware that VMs run on top of. The hypervisors themselves run on physical computers, referred to as the “host machine”. The host machine provides the VMs with resources, including RAM and CPU. These resources are divided between VMs and can be distributed as you see fit. So if one VM is running a more resource heavy application, you might allocate more resources to that one than the other VMs running on the same host machine. The VM that is running on the host machine (again, using a hypervisor) is also often called a “guest machine.” This guest machine contains both the application and whatever it needs to run that application (e.g. system binaries and libraries). It also carries an entire virtualized hardware stack of its own, including virtualized network adapters, storage, and CPU which means it also has its own full-fledged guest operating system.

• From the inside, the guest machine behaves as its own unit with its own dedicated resources.
• From the outside, we know that it’s a VM sharing resources provided by the host machine.

Unlike a VM which provides hardware virtualization, a container provides operating-system-level virtualization by abstracting the “user space”. You’ll see what I mean as we unpack the term container.

For all intent and purposes, containers look like a VM. For example, they have private space for processing, can execute commands as root, have a private network interface and IP address, allow custom routes and iptable rules, can mount file systems, and etc.

The one big difference between containers and VMs is that containers *share* the host system’s kernel with other containers.

This diagram shows you that containers package up just the user space, and not the kernel or virtual hardware like a VM does. Each container gets its own isolated user space to allow multiple containers to run on a single host machine. We can see that all the operating system level architecture is being shared across containers. The only parts that are created from scratch are the bins and libs. This is what makes containers so lightweight.

Docker is a flexible container storage platform that takes usability into account, which should be expected for a consumer-focused product. While you can access and learn Docker for free with the community version, you can also purchase Enterprise subscriptions that come with their own perks.

Kubernetes is an open source container storage program built by teams at Google and bases its container-worldview on how Google develops within their walls in Mountain View. While it provides a useful, scalable, and powerful tool, Kubernetes also gets a lot of clout because it’s an intricate and sometimes overly-complicated system. If you want an example of the power of Kubernetes, look no further than last year’s launch of the Pokemon Go app. While there were troubles, that app is a prime example of the ability of Kubernetes (and containers) to scale rapidly.