Mixed Workload with Azure AKS

HalYaman Backups, Microsoft
Sometimes you are required to deliver services that combine the different workloads of two different kernels. Does this strategy of service delivery require two different Kubernetes clusters? Can you run the different workloads on the same Kubernetes cluster? Recently, I came across a requirement where the client wanted to deliver a service that combined several different Kubernetes pods. The service I was asked to help them deliver is based on a Microsoft IIS server and a Linux Mysql database. To deliver a solution based on this requirement forced me to learn more about building a cluster that combined two different kernels; in this case, Windows and Linux. In this blog post, I will take you through the steps I took to build an Azure AKS with two different “Pools” to accommodate the above scenario. So, let’s get started:

The Good News

Kubernetes version 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster. This great feature enables organisations with investments in Windows-based applications and Linux-based applications to run on the same cluster. This leads to reducing the cost and operational complexity of running and managing both worlds, Windows and Linux.

Azure AKS Makes it Easy

As a Microsoft MVP and Azure focused Architect, I like to keep my work focused on Microsoft technologies; there are many reasons why, but I won’t bother you with that here.  Kubernetes/AKS is part of the reason why I like to focus on Microsoft technologies. To run both Microsoft and Linux on the same AKS cluster, you must create your AKS cluster with two different pools. One pool is based on Linux nodes; the second pool is based on Windows; It uses Windows 2019 as you can see in the screenshot below.   During the AKS provisioning, you can create node pools as required; but, if you are required to create a Windows node pool, you must remember the following points:
  • AKS cluster networking must be Azure CNI network
  • Windows Node pool name has a maximum of 6 characters
  • Windows maximum Node pool is limited to 10 pools, with a maximum of 100 Nodes on each
  • Taint, Labels and Tags must be set during the Node pool creation

Creating Node Pools

Note: Before you run the following example, make sure that you are running Azure CLI version 2.2.0 or later. To check your current version of the Azure CLI, use the following command: az –version

Assuming you have the right AKS cluster configuration and wish to add Windows Node Pools, you can run the following Azure CLI command:
az aks nodepool add \ –resource-group myAks \ –cluster-name myAKSClus \ –os-type Windows \ –name blgwin \ –node-vm-size Standard_B2s \ –kubernetes-version 1.20.9 \ –node-count 2 \ –labels Workload=windows \ –no-wait
After you have run the that command above, you can now see the newly created pool under “Node pools”: It is important to pay attention to the value in the table heading –labels when we create the Node pool. This label helps to assign the “Deployment” to the right Node pool. That is, when a Windows workload must be deployed, this deployment will target the nodes pool with this label. This is accomplished by using of the following command contained in the YAML file:
spec: nodeSelector: “Workload”: windows

Deploy Your workload

At this stage, you are ready to create your YAML file and deploy your workload targeting the new Node pool. The following YAML file will deploy an IIS server and target the deployment to the new created Node pool = Windows:
ApiVersion: apps/v1
kind: Deployment
metadata:
  name:iis
  labels:
      app:iis
spec:
   replicas:2
   template:
      metadata:
            name:iis
            labels:
                app:iis
      spec:
          nodeSelector:
               “Workload”:windows
           containers:
               – name:iis
                 image:mcr.microsoft.com/windows/servercore/iis
                 ports:
                     – containerPort:80
selector:
    matchLabels:
         app: iis
—
apiVersion: v1
kind: Service
metadata:
      name: iis
spec:
    type: LoadBalancer
    ports:
       – protocol:TCP
          port: 80
     selector:
         app: iis
On the code shown above, you will see the “NodeSelector” value. This value instructs the deployment to deploy the workload on a specific Node pool. The node pool value is the value configured during the creation of the pool; it is important to use it on all your deployment YAML files.
To better manage your workload deployments, it is recommended that you use Kubernetes node tainting. I will keep that for a future blog post.

Delete Node Pools

To delete, and to clean up the Node pools, run the following command:
az aks nodepool delete –resource-group myAks –cluster-name myAKSClus –name blgwin

Summary

Combining both Windows and Linux workload kernels on the same cluster can reduce your operational cost in the long run. Managing two types of workloads on the same cluster can be a little tricky; but, with Kubernetes Labels, Node Taint, and tagging, you can simplify the deployment process and reduce your overheads.

Leave a comment