Cluster Autoscaler – PaaS Compute Options

Cluster Autoscaler – PaaS Compute Options

Using HPA, you will be able to increase the number of replicas of a pod. However, what if you need more computing resources for the pods to run? In other words, what if the capacity of the nodes is not enough to meet the demand? Well, you have cluster autoscaler to adjust the number of nodes based on the requests. Like HPA, the cluster autoscaler checks the API server for any requirement changes every 10 seconds. If there is a requirement change, then the number of nodes is increased or decreased accordingly. AKS clusters with RBAC enabled and running Kubernetes 1.10.x and higher support the cluster autoscaler.

HPA and cluster autoscalers are used to provide optimal scaling. When combined, HPA increases or decreases the number of pods per application demand, and the cluster autoscale will adjust the number of nodes accordingly to run the pods.

Bursting from AKS with ACI

When you are using HPA for accommodating sudden application demand, HPA will increase the replica count. If the number of nodes is not enough to schedule these new pods, the cluster autoscaler will add more nodes. However, it may take a few minutes to bring the new nodes online and schedule the pending pods. Because of the faster startup time offered by Azure Container Instances (ACI), you can create a virtual node quickly. The virtual Kubelet component installed in the AKS cluster can abstract ACI as the node to the cluster. Kubernetes can then schedule pods that run as ACI instances through virtual nodes, not as pods on VM nodes directly in your AKS cluster.

Figure 9.23 shows how ACI acts as an extension to the AKS cluster to run pods.

FIGURE 9.23 Bursting from AKS with ACI

To use the virtual node, your application requires no code change or architectural change. Virtual nodes are deployed to a different subnet in the virtual network in which the AKS cluster is deployed. As they are part of the same virtual network, the communication between AKS and ACI is secured. Also, like AKS cluster, ACI offers a secure and isolated compute resource.

In the next exercise, you will deploy an AKS cluster. You will be using one of the manifest files available in the Azure documentation to create your application in the cluster. Also, you will be using kubectl to interact with the cluster. As this is pre-installed in the cloud shell, you will be using the cloud shell to deploy our application. You can install the kubectl binaries to your local computer by executing az aks install-cli.

EXERCISE 9.4
 Running Applications in an AKS Cluster

1. Open the Azure portal and search for AKS; you will see Kubernetes Services in the search results. Click it to open it.
2. Click Create and select Create Kubernetes Cluster to create the cluster. You will be taken to the Basics tab of the cluster creation page.
3. On the Basics tab, you need to provide the following details.

Project Details

• Subscription: Select an Azure subscription.
• Resource Group: Select or create a resource group to hold the AKS cluster.

Cluster Details

• Preset configuration: The default option is Standard. Preset helps us to select the configuration per our requirements. Other options include dev/test, cost-optimized, batch processing, and hardened access. There are price differences and feature-wise differences between these presets. In our case, we will choose the default one.
• Kubernetes cluster name: Provide a name for the cluster.
• Region: Select the Azure region.
• Availability zones: By default, all three zones will be selected, helping us to deploy our nodes across availability zones. If needed, you can limit the deployment to certain zones.
• Kubernetes version: As you saw earlier, there are multiple versions available. At the time of writing this book, the default value is 1.20.9, and we will proceed with that.