Easing into Windows Server containers in AKS

When it comes to building distributed applications at scale, containers have become the logical deployment tool. They let you wrap up code at a service level, keeping your application separate from its data. Once deployed, orchestration tools such as Kubernetes manage scaling, monitoring CPU and memory usage, and deploying new container instances as necessary.

At heart it’s a relatively simple way to think about your code. In practice, however, there’s a lot of configuration work to be done: understanding how code is partitioned, defining the correct logical groupings of containers and services, building the links between your container deployment and external storage, and making sure it’s all handled correctly. Much of that is, of course, controlled by Kubernetes, but that means getting deep into its configuration and creating the appropriate YAML configuration files.

Introducing AKS

With all that YAML, running Kubernetes for yourself isn’t particularly easy. There’s a lot to consider when designing pods and rules and setting up higher-level monitoring. You need to define nodes, set up masters, and manage the entirety of your distributed infrastructure. That’s where AKS, the Azure Kubernetes Service, comes in. It’s a way of handing over much of your Kubernetes management to Azure. All you need to do is define your nodes and AKS does the rest. You pay for the compute resources your code uses and you don’t have to worry about running masters, only the agent nodes.

The result is a much lighterweight way to work with Kubernetes. You’re still using vanilla Kubernetes, so tools such as Helm and Terraform work happily with AKS. Microsoft doesn’t fork anything. It takes a standard Kubernetes release and adds a management layer, integrating its role-based access controls with Azure Active Directory and delivering Kubernetes logs to Azure Monitor for access through Azure Log Analytics.

Perhaps surprisingly for a large-scale service on a public cloud, AKS doesn’t significantly lag the public Kubernetes distributions. The current release of AKS already supports Kubernetes v1.14, an important release that finally offers production-level support for Windows nodes and containers. Until now all AKS workloads needed to be Linux-based, using Linux containers. Now Kubernetes supports Windows workloads, thanks to an improved Windows container runtime that’s been developed in conjunction with Microsoft.

Getting started with AKS and Windows Server containers

AKS support for these new features is currently available only as a preview. If you’re building and running microservices on Windows Server VMs in Azure, these new AKS features are likely to be your best route to taking that code and making it horizontally scalable. You now have the option of mixing and matching Windows and Linux containers in the same Kubernetes cluster, using each operating system for what it’s best at.

Standing up an AKS cluster with Windows Server containers doesn’t require any new skills. If you’ve set up a Linux-based cluster, you should find the process very familiar. The Azure CLI contains most of the tools you need, either running locally on your development PC or using the Cloud Shell built into the Azure Portal.

As support for Windows Server containers is in public preview you’ll need to add support for the new features in your Azure CLI by enabling or updating the aks-preview extension. You’ll then need to register the WindowsPreview flags on your subscription, adding them to the Microsoft.ContainerService namespace. With the flags enabled, all new AKS clusters will support Windows Server containers. If you don’t want this on a production account, use it with a development or test subscription to make sure it meets your requirements before adding the features to a production Azure account.

Once you’ve configured support for the AKS preview in your Azure account, you can start to build a cluster for your Windows Server containers. Using the standard AKS create command, define a cluster with either Kubernetes 1.13.5 or 1.14.0 that includes support for Azure networking and monitoring features.

Adding a Windows node pool to an AKS cluster

Azure will create a cluster with an initial Linux node pool, so you’ll have to add another specifically for your Windows Server containers. This can be done using the aks nodepool command, setting the OS type to Windows. This will create a node pool using a Standard D2s v3 virtual machine as a host. You can choose alternative VMs using the node-vm-size parameter, but the default is the minimum recommended size.

With your Windows node pool in place, you can start to add containers. Initially this requires using Kubernetes’ own command line tooling, kubectl. If you’re using Cloud Shell, it’s preinstalled. Otherwise you’ll need to add it to a local Azure CLI, using the AKS install-cli command. You’ll then configure kubectl to work with your account, before getting details of the nodes in your AKS cluster. You should see two: the default Linux node pool and the Windows node pool you added.

Installing your first Windows Server container

Microsoft’s preview documentation includes a sample YAML file for adding a simple ASP.Net app container to a cluster. By selecting a Windows node, it’ll automatically deploy a Windows Server container from the Azure Container Registry into your cluster, setting up CPU and memory limits for Kubernetes-controlled scaling. Once deployed, AKS will assign an external IP to the service load balancer, which you can get from kubectl’s get service command. When you have the IP address, you can quickly test your Windows Server container from any web browser.

The sample service highlights another benefit to Windows Server container support in Kubernetes on Azure, as you can use the Azure Container Registry to manage your container base images. If you’re using a CI/CD pipeline such as Azure DevOps for source control and compiling your code, ACR becomes part of your application packaging process, taking your container images before replicating them to any Azure region where your application is being deployed, speeding up deployment and making it a lot easier to deliver new container instances when AKS stands up additional nodes.

With the sample service up and running, you can use the same process to add your own container images to AKS. Operating Windows Server containers is, as it should be, identical to operating Linux containers. It’s the underlying container OS that’s different, not AKS or Kubernetes, or even Azure’s networking features. That’s a big benefit: You don’t need new skills to work with Windows in AKS, and you can use it to quickly extend your existing applications by mixing and matching Windows and Linux services in your AKS applications.