Reading Time: 6 minutes
Follow by Email

On April 28th, 2020 Microsoft announced the general availability of Windows Server Container support on Azure Kubernetes Service (AKS). This has gotten me extremely excited. As you may know, if you have been following me, I have been running Windows containers in a production environment for over a year now. They have been running on a Custom Virtual Machine Scale Set (VMSS) with scaling being done via a logic app. Finally, I can now move away from that solution and use AKS and have all my containers running in the same place.

Below, I will share with you the steps you can use to create an AKS cluster with windows node pools using the Azure CLI.


When using creating an AKS cluster with support for windows node pools you always have to create a Linux node pool first, this basically becomes the system node pool, but you can still use it to schedule Linux containers. So, if you are just wanting to use Windows containers then make this first node pool as small as you can, but you will always need at least 2 nodes for reliability.

For the Windows node pool you will also have the following limitations:

  • The AKS cluster can have a maximum of 10 node pools.
  • Each node pool can have a maximum of 100 nodes
  • The windows Server node pool name has a limit of 6 characters.

Now we have that out of the way let’s look at creating the cluster.

But first we need a resource group

In your terminal or the Azure Cloud Shell use the following to create a resource group. If you already have one, then you can skip this step.

Now that’s out of the way, lets create the cluster

Windows Server containers only support a cluster that uses a network policy that uses Azure CNI (advanced) network plugin. The below command will create the AKS cluster with the correct network plugin and will also create the network resources for you.

After a few minutes you should have your new AKS cluster with the 2 Linux nodes needed for the first node pool.

Time to add the Windows Server node pool

For this we are going to use the az aks nodepool add command.

The command above will create a Windows Server node pool called win with a node count of 1. It will use the default node size of standard_D2s_v3 which is the minimum recommended size for windows server container nodes. It will also add a taint to the node pool and any new nodes added to this node pool. When a taint is applied to a node it means only pods with a toleration that matches can be scheduled on it. So only pods that can run on windows server will be scheduled on this node pool. This means you only have to edit your Windows container yaml files and not everything.

Testing time

So, now let’s make sure everything is set up correctly and we can connect to the cluster.

For this we are going to use kubectl, if you do not have it installed you can use the following command:

Next use the az aks get-credentials command to configure kubectl to connect to your cluster.

Now use the following command to view all your nodes.

You will see 2 Linux nodes and one Window node. The window one will start aks and then the name we have it above, win, in this case.

Time to deploy a test application

Below you will find a Kubernetes manifest file that will deploy a test ASP.NET application to your cluster and more specifically your Windows Server node pool.

Copy the above code and save it as sample.yaml.

You will notice under the spec section (line 14) we have added in the toleration to match the taint we set on the node pool.

Without this being added then the container would not start and would be sat in pending state.

You may have also noticed the node selector line. Without the taint this would allow you to specify which OS type the node has to be to allow it to run on. Unfortunately, a lot of the system containers and publicly available Linux containers do not have this line added, so I find it easier to add the taint and toleration to ensure I do not get any containers stuck in pending state.

To deploy the sample application, use the following command after navigating to the folder where you saved the yaml file.

After about 10 minutes the pod will have been pulled and started. You can check the status by using the following:

To see the application is up and running you can use the following command to get the external IP address of the service.

Now in your web browser navigate to the external IP.

Clean up time

Once you have finished with your testing use the following to delete everything.

This will delete the resource group and the cluster, but it will not delete the Azure Active Directory service principal that got created. See on how to remove it.

All in All

I am excited about windows containers. With the work Microsoft are doing to get the image size down I believe we will see more windows containers in the wild. There is still work to be done in my opinion but this is an amazing start. I would love to see a way for all existing Linux containers to not try and schedule on a windows node without using tolerations or node selectors, maybe one day this might happen or, node selector will become a requirement of all manifest files.

Just remember the above is only for testing and not production use!

I hope you found this article helpful and if you have any questions please reach out.

Follow by Email

Pixel Robots.

I’m Richard Hooper aka Pixel Robots. I started this blog in 2016 for a couple reasons. The first reason was basically just a place for me to store my step by step guides, troubleshooting guides and just plain ideas about being a sysadmin. The second reason was to share what I have learned and found out with other people like me. Hopefully, you can find something useful on the site.


Jarred · April 13, 2021 at 3:32 am

It looks like you’ve misspelled the word “Enginer” on your website. I thought you would like to know :). Silly mistakes can ruin your site’s credibility. I’ve used a tool called in the past to keep mistakes off of my website.


Jarred · November 1, 2021 at 6:47 am

I think you misspelled the word “Enginer” on your website. If you want to keep errors off of your site we’ve successfully used a tool like in the past for our websites. A nice customer pointed out our mistakes so I’m just paying it forward :).

Azure Insights: Kubernetes Service; Custom handlers; Multi-Factor Authentication; Resource Groups ERP for Hong Kong SME · May 25, 2020 at 6:00 pm

[…] Hooper, writing on Pixel Robots, examined Microsoft’s announcement of Windows Server Container support for Kubernetes […]

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *