Okay welcome back. In this lesson I'm going to review each of the different options available for scaling an AKS cluster either manually or automatically.

Scaling can be performed at different layers, either at the pod level or at the node level. There's even a virtual node option which I'll review as well. Any or all of these options will help to ensure that your AKS cluster deployed workloads have continued predictable performance regardless of the current demand profile.

AKS supports both manual and auto scaling. Manual scaling can be performed either at the node level, or at the pod level by simply increasing or decreasing the respective count property. For example, the following Azure CLI command is used to scale an existing nodepool up to 10 nodes.

In the next example, the kubectl command is used to manually scale up the webapp deployment to have 10 pods.

Auto scaling can be performed within an AKS cluster automatically by two different scalers. The cluster autoscaler can be configured to automatically add or remove worker node vm's to and from the cluster. New nodes are added when the cluster autoscaler detects that new pods cannot be scheduled anywhere within the existing nodepool due to resource exhaustion. The cluster autoscaler works together with VM Scale Sets to manage and maintain the overall set of nodes within the cluster. VM Scale Sets are also used to manage multiple cluster node pools, so that workloads with specific resource requirements are hosted on the right infrastructure.

The following command demonstrates how to create an AKS cluster with the cluster autoscaler enabled by specifying the "enable cluster autoscaler" parameter together with the min and max values for node count.

The horizontal pod autoscaler scales out additional pods across an existing node pool when the resource demand, whether it be for CPU, memory, or something else, for a replicaset or deployment exceeds a specific threshold. The replicaset or deployment needs to be configured with resource limits which the horizontal pod autoscaler uses to determine whether more pods need to be scheduled. The horizontal pod autoscaler queries the Metrics API continually every 30 seconds by default to determine if a pod scaling event is required.

Using and configuring the horizontal pod autoscaler is very simple and quick. To use it, you first need to set your required resource limits for the container. For example in the following webapp Deployment, the enclosed webapp container makes a request for at least 200m of CPU, 'm' short for milliecores. A maximum limit of 500m of CPU is also set.

To do so, we simply run the "kubectl autoscale deployment" command. The following command is configured to maintain a pool of pods, no fewer than 10, and no more than 100 for the "webapp" deployment so that the average CPU utilization across all of them remains at approximately 50%. AKS also provides a hybrid scaling option called VIrtual Nodes. With this enabled, AKS can perform rapid burst scaling, launching new pods into the Azure Container Service within seconds.

This approach is much faster than the Kubernetes cluster autoscaler, which incurs the penalty of the extra time taken to spin up a new worker node vm instance. It's important to note that Virtual Nodes are only supported on AKS clusters that have been created and enabled with advanced networking. The other interesting aspect of using virtual nodes for pod hosting, is that it changes the way you are billed. Pods hosted on virtual nodes are billed only per second of execution time making virtual nodes perfect for hosting short-lived pods.

Okay that completes this lesson. In this lesson, I reviewed the various scaling options available in Kubernetes and AKS. Kubernetes provides the cluster autoscaler and the horizontal pod autoscaler. AKS expands on these features by providing VM Scale Sets for node scaling, and Virtual Nodes.

Go ahead and close this lesson and I'll see you shortly in the next one.