How Windows containers differ from Linux containers
You wouldn’t have guessed it but they differ quite a bit. Yes, you’re still writing a Dockerfile, building it, and running your container but that’s where it stops. Before you get started with Windows containers we highly recommend you read up on the concepts, the limitations, and their capabilities here.
The operating system
Well first of all... It’s a different operating system. But that does mean something. Where we are used to having a wide variety of options for images when it comes to Linux containers. With Windows containers that’s a different story. There is a strong link between the container OS and the Host OS and you are advised to make them match to prevent combability issues. These requirements become even more important when you use process isolation. Microsoft has released these guidelines to determine which image is best for the scenario. Having the correct base image matters.
Where did my Graphical User Interface go?
Yes, it is not really a difference but it’s something worth mentioning if you’re used to running your solution on Windows. When it comes to containers, there is no GUI. Now you might be thinking “Yes Captain Obvious we know” but hold on! In a Linux ecosystem, we are used to working from the command line but from Windows.. Not so much. Yes, we use PowerShell but how many of your applications are you actually installing from the command line? Exactly.
If you were to containerize your Windows Application that means everything needs to be running from the command line and through the Dockerfile. This might sound like a limitation, but the opposite is true. You are going to standardize and script your deployments! Sometimes that means you need to change some things in your installer or get rid of it altogether if it doesn’t support any command-line options and sometimes, you’re already good to go.
Image sizes
I’m not going to state that Windows containers are “slower” because really when it comes to the runtime itself, they don’t have to be. The biggest difference is the container image. Windows images are larger than Linux images. When you run your container the Docker image is downloaded and it takes a bit longer than downloading a Docker image based on Linux. If you take that into account and pick the correct image for your workload it shouldn’t be too much of a problem.
Then there are also recent developments that might take away this difference or minimize it to a point where you no longer care. Take a look at Artifact Streaming. Once supported, in a world of Windows containers, this will be a big win.
I’m using Azure Kubernetes Services, now what?
Good question! Easy and honest answer! Kubernetes supports the use of Windows node pools. That means when you’re installing AKS you can have one or multiple node pools. Those node pools can be Windows. Do note that you always need a Linux node pool as well. The default node pool is also where the services required for the cluster to function are hosted, these are based on Linux.
That means, if you’re going for Windows containers, you’ll have a minimum of two-node pools. Just as with Linux node pools, these are managed by AKS itself and you don’t have to worry about them too much. If you do want to troubleshoot the nodes you can access them through RDP (the node, not the container!). Alternatively we can also SSH into the Windows Node (this will be the best practice going forward).
You don’t need to access the nodes to install or approve Windows updates. On node pools Windows update is disabled. Instead, you can upgrade your Windows node pool just as any other node pool.
Other than that, most features are supported for Windows containers. Things like persistent storage networking (CNI) are there and ready for you to use. If you want to dig into the technicalities of what’s different and what the limitations are please check the official Kubernetes project documentation.
