Understanding Azure Kubernetes Services Autoscaler

What is the Azure Kubernetes Services Autoscaler?

Azure Kubernetes Service Autoscaler (AKSA) is a feature of Azure Kubernetes Service (AKS) that automatically scales, or changes, the number of nodes in a Kubernetes cluster based on the resource usage of the pods in the cluster. It monitors, or watches, the resource usage of the pods and adjusts the number of nodes in the cluster to ensure that the pods have enough resources to run. This helps to ensure that your team does not have to manually intervene when there are changes in workloads.

How does it work?

The AKSA automatically changes the number of nodes in an AKS cluster based on how many resources the pods are using. It uses a Kubernetes controller to watch for changes in resource usage and then adjusts the number of nodes up or down as needed. The AKSA uses an algorithm to decide when to scale the number of nodes. The algorithm takes into account the current resource usage, as well as the desired resource usage that is specified in each pod’s settings. If the pods are using more resources than desired, then additional nodes will be added to provide the extra resources that are needed.

When the resource usage of the pods falls below the desired resource usage, the AKSA will remove nodes from the cluster to reduce the number of resources being used.

The AKSA can also be configured to use custom metrics, this way the system can be scaled based on other criteria than just CPU and Memory usage.

It is important to note that AKSA is not a replacement for monitoring and alerting, it should be used as an additional tool to help ensure that the cluster has the resources it needs to run the pods.

When should you use the AKSA?

When the workload running on an AKS cluster is anticipated to fluctuate dynamically and manual scaling would be challenging or impracticable, the AKSA should be employed. For example, you might use the AKSA in the following situations:

• When operating web apps or systems based on microservices that undergo fluctuating levels of traffic
• Executing batch processes or other workloads with foreseeable but unpredictable resource demands.
• While utilizing programs or services that are part of a pipeline for continuous integration or delivery.

In these circumstances, the AKSA can assist in making sure that the cluster has the resources required to run the pods, even as the demand varies. This could increase accessibility and

It’s also important to note that AKSA can work together with other Azure services to provide a more holistic solution, for example, AKSA can scale the AKS cluster based on the custom metric that comes from Azure Monitor, or it can scale the underlying VMs based on Azure Monitor metric.

Limitation of AKSA

There are a few restrictions with the Azure Kubernetes Service Autoscaler (AKSA) to be aware of.

• Scaling based on pod resource usage can be delayed by the time it takes for the Kubernetes controller to detect changes in resource usage and to adjust the number of nodes in the cluster.
• The AKSA only scales the number of nodes in the AKS cluster, it does not scale the number of pods running on the nodes. If you need to scale the number of pods, you will need to use Kubernetes’ built-in horizontal pod Autoscaler or a third-party solution.
• AKSA can only scale based on the CPU and Memory usage of the nodes. If you need to scale based on other resource usages, such as network or disk I/O, you will need to use a third-party solution or custom metric.
• AKSA will only scale the number of nodes in the AKS cluster up to the maximum number that you configure. So, if the cluster reaches the maximum number of nodes and still needs more resources, AKSA will not be able to scale further.
• The AKSA may not be the best solution for all types of workloads. For example, if your workload is relatively stable and does not experience significant changes in resource usage, manual scaling may be more appropriate.

In conclusion, AKSA can be an excellent tool for ensuring that the AKS cluster has the resources required to run the pods, but it’s important to be aware of its limitations and to use it in conjunction with other monitoring and scaling tools as necessary.

How to get started with AKSA?

There are two ways you can configure AKSA:

1. When creating the AKS cluster. For example, here we are using CLI to create the cluster. We need to use the flag –enable-cluster-autoscaler

• az aks create \
• --resource-group myResourceGroup \
• --name myAKSCluster \
• --node-count 1 \
• --enable-cluster-autoscaler \
• --min-count 1 \
• --max-count 3 \
• --cluster-autoscaler-profile scan-interval=30s

2. Or you can update the Autoscaler cluster profile by CLI

• az aks update \
• --resource-group myResourceGroup \
• --name myAKSCluster \
• --cluster-autoscaler-profile Similarly, you can disable the auto scaler profile:
• az aks update \
• --resource-group myResourceGroup \
• --name myAKSCluster \
• --disable-cluster-autoscaler

and the same way we can use --enable-cluster-autoscaler, --min-count, and --max-count parameters. to enable it again.

• az aks update \
• --resource-group myResourceGroup \
• --name myAKSCluster \
• --enable-cluster-autoscaler
• --min-count  1 \
• --max-count 3 \

Conclusion

Azure Kubernetes Service Autoscaler (AKSA) is a powerful tool that can help ensure that your AKS cluster has the resources it needs to run your pods. By automatically scaling the number of nodes in the cluster based on CPU and memory usage, the AKSA can help prevent resource contention and ensure that your pods have the resources they need to run. However, it’s important to be aware of the limitations of the AKSA, such as its delay in scaling based on pod resource usage and its inability to scale the number of pods. To get started with the AKSA, you’ll need to create an AKS cluster, enable the AKSA, set the minimum and the maximum number of nodes, and configure the AKSA to use custom metrics. It is important to monitor the AKSA and the AKS cluster to test the AKSA with realistic loads before deploying it to production.