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 \
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:
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/v1kind: Deploymentmetadata:name:iislabels:app:iisspec:replicas:2template:metadata:name:iislabels:app:iisspec:nodeSelector:“Workload”:windowscontainers:– name:iisimage:mcr.microsoft.com/windows/servercore/iisports:– containerPort:80selector:matchLabels:app: iis—apiVersion: v1kind: Servicemetadata:name: iisspec:type: LoadBalancerports:– protocol:TCPport: 80selector:app: iis
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
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.