Windows Server Containers vs. Hyper-V Containers
Windows Server containers provide user-mode isolation for applications in different
container instances. All the container instances on the same container host share
common host operating system instances and a common kernel. In a trusted
environment such as within a private cloud, or when the applications being deployed
are from a well-managed and audited library, user-mode-only isolation may meet the
required levels of security. In a public cloud, the environment utilized by different
tenants sharing a common kernel may not be desirable, as each application may not
be trusted, and a tenant running a container on the same container host could
possibly try to use the shared kernel to attack other containers.
Another challenge of regular containers is the dependency on the container host OS
version, which is specified as part of the dependency chain from the application,
through its binary and library containers, and through to the host OS specified in
those dependent libraries. If the OS changes on the container host, it may break the
containers running on it.
To address these concerns, Windows Server 2016 has an additional type of container:
Hyper-V containers. As the name suggests, a Hyper-V container leverages the Hyper-V
role of Windows Server 2016 to automatically create and manage (and eventually
delete) a virtual machine into which the containerized application is instantiated,
along with the other containers upon which it depends and its own base OS image.
This approach gives the Hyper-V container standard user-mode isolation but also
kernel-mode isolation. This is shown in Figure 10.2, where both types of containers
are running on a single container host.
Figure 10.2 Windows Server containers vs. Hyper-V containers
The virtual machine created for a Hyper-V container is automatically managed and is
not visible in standard Hyper-V management tools, such as Hyper-V Manager.
However, if the list of processes for a container host is examined, a VM worker