5 tips for IIS on containers: #4 Solving for Horizontal Scale

Posted by

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Fourth up in this blog series!  Solving for Horizontal Scale with IIS and Containers.   Make sure to check out the other topics in the blog on SSL certificate lifecycle management, IIS app pools and websites and Hardcoded configurations


Azure Kubernetes Service

Since each node on Azure Kubernetes Service (AKS) is a virtual machine on a Virtual Machine Scale Set (VMSS), AKS can easily add new nodes in case additional resources are needed to meet the demand.  Your website might have increased or decreased demand depending on the use case so AKS can be a valuable tool

Architecture in Azure with AKSArchitecture in Azure with AKS


Keep in mind that Kubernetes can scale pods up and down based on metrics and AKS can scale nodes up and down based on resource utilization and pods not being able to be scheduled.  Here I will show how AKS can scale nodes up and down according to pod scheduling


Node Pools

Below is an image of the Azure Portal showing my Contoso Cluster on AKS.  If you go to Node Pools under Settings.  We will see the Windows pool I have running in AKS.




Here you can see I only have a Windows node pool names wspool and 1 node ready



Scale Node Pools

However, if I go to the Scale Node Pool option you can see the Autoscale option is already in place and the way I set this up is to have 1 minimum node and a maximum of 10 nodes.  If more nodes are needed to support the pods I have in my environment, AKS will automatically scale up or if the load goes down it will scale down the number of nodes as well.



We can test this setup without placing actual load on the environment.  Here I can use my deployment yaml file and change replicas (on line 5) from 1 to 6.



apiVersion: apps/v1
kind: Deployment
  name: iis-app-routing
  replicas: 1
      app: iis-app-routing
        app: iis-app-routing
        "kubernetes.io/os": windows
      - name: iis-app-routing
        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
            cpu: 1
            memory: 800M
            cpu: .5
            memory: 400M
        - containerPort: 80
apiVersion: v1
kind: Service
  name: iis-app-routing
  type: ClusterIP
  - port: 80
    app: iis-app-routing




The way the environment is setup is only one node will be able to run one pod, none of the nodes can run multiple so if there is more demand or in this case an ask for 6 replicas it will be necessary to deploy more nodes.


In the Azure portal I’m going to open Azure Cloud shell and upload my deployment file (where I changed to 6 replicas) and here I use the "kubectl apply" command adding file name and my namespace of "hello-web-app-routing". 



kubectl apply -f deployment.yaml -n hello-web-pp-routing



After running it, you can see it shows configured so it applied the new deployment file with no issue.



Now let's take a look at that pods that are running in this namespace with the "kubectl get pod" command



As you can see, I have 1 pod running that was previously running on this host and the other pods have a status of pending. What is happening right now is that in the backend, the AKS cluster is actually being scaled up to support more pods and since no single node can run more than 1 pod, I’m going to need 6 nodes deployed.


If we select the node pool and open the details, I only have 1 node ready but the node count is already up to 6 nodes.  This process will take a few minutes until you see all 6 deployed



Second screenshot showing status of 6 nodes running after the deployment completed




Going back to our Azure cloud shell we can run a "kubectl get pod" to see the status on our nodes

Actual command here:




kubectl get pod -n hello-web-app-routing





​The output:



As you can see some nodes are still in a pending state, while others are in a ContainerCreating State.  Eventually they will all be in a running state.  You can watch the status updates by adding the watch flag to the command like so




kubectl get pod -n hello-web-app-routing -w




​Eventually you can see that all the nodes are in a running state



Now since this is set to auto-deploy, AKS will scale up or down based on demand without human intervention.  So, if you happen to run a sale at a retail store online and you know the demand is going to be higher, AKS can scale up during peak hours and scale back down when the extra nodes are no longer necessary.  This can save time and money.


Thanks for reading and keep an eye out on the last post in this series. If you have any questions or feedback please comment below


Amy Colyer


Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.