Windows Server 2019 – Windows Server containers versus Hyper-V containers

How to install Ubuntu Server 19.10

When spinning up your containers, it is important to know that there are two categories of containers that you can run in Windows Server 2019. All aspects of application containers that we have been talking about so far apply to either Windows Server containers or to Hyper-V containers. Like Windows Server Containers, Hyper-V Containers can run the same code or images inside of them, while keeping their strong isolation guarantees to make sure the important stuff stays separated. The decision between using Windows Server Containers or Hyper-V Containers will likely boil down to what level of security you need your containers to maintain. Let’s discuss the differences between the two so that you can better understand the choice you are facing.

Windows Server Containers

In the same way that Linux containers share the host operating system kernel files, Windows Server Containers make use of this sharing in order to make the containers efficient. What this means, however, is that while namespace, filesystem, and network isolation is in place to keep the containers separated from each other, there is some potential for vulnerability between the different Windows Server Containers running on a host server. For example, if you were to log into the host operating system on your container server, you would be able to see the running processes of each container. The container is not able to see the host or other containers, and is still isolated from the host in various ways, but knowing that the host is able to view the processes within the container shows us that some interaction does exist with this level of sharing. Windows Server Containers are going to be most useful in circumstances where your container host server and the containers themselves are within the same trust boundary. In most cases, this means that Windows Server Containers are going to be most useful for servers that are company-owned, and only run containers that are owned and trusted by the company. If you trust both your host server and your containers, and are okay with those entities trusting each other, deploying regular Windows Server Containers is the most efficient use of your hardware resources.

Hyper-V Containers

If you’re looking for an increased amount of isolation and stronger boundaries, that is where you will foray into Hyper-V Containers. Hyper-V Containers are more like a super-optimized version of a virtual machine. While kernel resources are still shared by Hyper-V Containers, so they are still much more performant than full virtual machines, each Hyper-V Container gets its own dedicated Windows shell within which a single container can run. This means you have isolation between Hyper-V Containers that is more on par with isolation between VMs, and yet are still able to spin up new containers at will and very quickly because the container infrastructure is still in place underneath. Hyper-V Containers are going to be more useful in multi-tenant infrastructures, where you want to make sure no code or activity is able to be leaked between the container and host, or between two different containers that might be owned by different entities. Earlier, we discussed how the host operating system can see into the processes running within a Windows Server Container, but this is not the case with Hyper-V Containers. The host operating system is completely unaware of, and unable to tap into, those services that are running within the Hyper-V Containers themselves. These processes are now invisible.

The availability of Hyper-V Containers means that even if you have an application that must be strongly isolated, you no longer need to dedicate a full Hyper-V VM to this application. You can now spin up a Hyper-V Container, run the application in that container, and have full isolation for the application, while continuing to share resources and provide a better, more scalable experience for that application.

Comments are closed.