• +000 0000 000
  • [email protected]
    • Contact Us

    1. Home
    Sep 4, 2024
    Deploying AKS 2 – Creating and Configuring Containers
    1. Next, we have the Authentication tab; here, you will note we can modify the setting for the Authentication method type to either Service principal or System-assigned managed identity. This will be used by AKS for managing the infrastructure related to the service. For this exercise, we will leave this at its default setting. Then, you have the Role-based access control (RBAC) option. By default, this is set to Enabled; this is the best option to manage the service as it allows fine-grained access control over the resource; leave this as Enabled. You will also have the choice to enable AKS-managed Azure Active Directory. Checking this will enable you to manage permissions for users on the service based on their group membership within Azure AD. Note that once this function has been enabled, it can’t be disabled again, so leave this unchecked for this exercise. Finally, you have the option of the Encryption type value you want. For this exercise, leave it as the default setting. Click Next: Networking >. The process is illustrated in the following screenshot:

    Figure 11.47 – Creating a Kubernetes cluster: Authentication tab

    1. For the Networking section, we will leave most of the settings as their default configuration. Note that for Network configurations we have two options here, one for Kubenet and another for Azure CNI. kubenet is a new VNet for the cluster whereby Pods are allocated an IP address and containers have network address translation (NAT) connections over the shared Pod IP. Azure Container Networking Interface (Azure CNI) enables Pods to be directly connected to a VNet. In association, this allows containers to have an IP mapped to them directly, removing the need for NAT connection. Next, we have the DNS name prefix field, which will form the first part of your FQDN for the service. You will then notice Traffic routing options available to us for the service—we will discuss this more in one of the next exercises, as well as the Security options available to us. Select Calico under Network policy. Click Next: Integrations >. The process is illustrated in the following screenshot:

    Figure 11.48 – Creating a Kubernetes cluster: Networking tab

    1. On the Integrations tab, you will note the option to select a container registry. We will select the registry that we previously deployed. You will also note you have the option to deploy a new registry directly from this creation dialog. Next, we have the option to deploy container monitoring into the solution on creation. We will leave the default setting here, but monitoring will not be covered under the scope of this chapter. Finally, you have the option of applying Azure Policy directly to the solution; this is recommended where you want to enhance and standardize your deployments. This solution enables you to deliver consistently and control your deployments on AKS more effectively. Click Review + create, then click Create. The process is illustrated in the following screenshot:

    Figure 11.49 – Creating a Kubernetes cluster: deployment

    You have just successfully deployed your first Kubernetes cluster; you now know how to deploy and manage containers at scale and in a standardized way. Next, we will look at how we configure storage for Kubernetes and make persistent storage available to our solution.

    More Details
    Sep 3, 2024
    Deploying AKS – Creating and Configuring Containers

    Deploying AKS

    Thisexercise is to help you gain familiarity with AKS. We will deploy our first AKS instance, and then with the corresponding exercises, we will explore the different management components for this. Proceed as follows:

    1. Sign in to the Azure portal at https://portal.azure.com.
    2. Open the resource group you will be using for this exercise, click Overview on the left menu, then clickCreate.
    3. On the left Category menu, select Containers, then click Create under Kubernetes Service, as illustrated in the following screenshot:

    Figure 11.43 – Creating an Azure Kubernetes service

    1. Select your Resource group type, enter your Kubernetes cluster name value, select your Region type, and then leave all the other settings on their default configuration and click Next: Node pools >. The process is illustrated in the following screenshot:

    Figure 11.44 – Creating a Kubernetes cluster

    1. Scroll down the page, and note that we can change the Node size value. Changing this option allows you to choose a size very similar to what you saw in the previous chapter with VMs. Next, you can select how you would like to manage scaling; this can be either Manual or Autoscale. Manual means that you would like to modify the scale count yourself whenever you would like to change the count of nodes for your pool, whereas Autoscale will allow you to scale automatically based on a scaling rule. For this option, you select a range being the minimum number of nodes you want and the maximum you would like to scale it up to. As you can see, there is a lot of room for scaling with this service. Click Next: Node pools >. The process is illustrated in the following screenshot:

    Figure 11.45 – Primary node pool sizing

    1. On the Node pools tab, you will note the ability to add additional pools that can also be configured to scale in the same fashion as the Primary node pool type we configured in the previous step. You also have the Enable virtual nodes option, which enables you to scale your containers beyond your VM specified in the previous steps, and scale to use ACI as additional nodes when AKS needs to scale out. The final option available is Enable virtual machine scale sets. You will note that it is already checked for our deployment, the reason being that it’s required to support the Availability zones configuration we have from Step 4. Scale sets enable us to have a scaling VM supporting the container service; this allows better scaling of resources when it’s required since a single VM will be limited in the number of containers it can host. This also enables dynamic scaling (no downtime) due to horizontal scaling ability. Having to change the size vertically (such as more or fewer resources—essentially, the stock-keeping unit (SKU)) would result in losing access to the resource temporarily while it’s resized and restarted. This is a more static type of scaling. Next, click Next: Authentication >. The process is illustrated in the following screenshot:

    Figure 11.46 – Creating a Kubernetes cluster: Node pools tab

    More Details
    Jun 4, 2024
    Configuring storage for AKS – Creating and Configuring Containers

    Configuring storage for AKS

    AKS enables different storage options available for containers; you can leverage either local (non-persistent) storage or shared storage (persistent storage) for your containers through AKS. For persistent storage options, you can leverage Azure Managed Disks, which is primarily focused on premium storage solutions, such as for fast input/output (I/O) operations, as we discussed in Chapter 6, Understanding and Managing Storage. Azure File Shares is another option available and the default storage mechanism for enabling persistent storage on containers. This is typically cheaper to deploy and provides decent levels of performance for most workloads. For better performance, premium file shares can be used. Azure File Shares is also great for sharing data between containers and other services, whereas a managed disk will be restricted to a single Pod but is easier to deploy.

    The following diagram illustrates the different storage options available:

    Figure 11.50 – Kubernetes: Storage layers

    In this exercise, we will configure shared storage using Azure File Shares in your AKS cluster. Proceed as follows:

    1. Sign in to the Azure portal at https://portal.azure.com.
    2. Create a storage account and a file share named fileshare01. Once created, note the primary storage account key.
    3. Launch Azure Cloud Shell and run the following commands. Replace the resource group name with your name and the AKS cluster name for the Name field:

    Az login

    Install-AzAksKubectl

    Import-AzAksCredential -ResourceGroupName AZ104-Chapter11 -Name myfirstakscluster

    1. Modify the following script with your storage account name and storage account key, then paste it into Cloud Shell and press Enter:

    kubectl create secret generic azure-secret –from-literal =azurestorageaccountname=storageaccountname –from-litera l=azurestorageaccountkey=storageaccountkey

    1. Navigate to the AKS cluster you created in the previous section. Click on Storage on the left menu, then ensure you are on thePersistent volume claims tab, and click Add, as illustrated in the following screenshot:

    Figure 11.51 – Adding a persistent volume claim

    1. Click Add with YAML, as illustrated in the following screenshot:

    Figure 11.52 – Add with YAML

    1. Paste or type the following YAML document into the window:

    apiVersion: v1

    kind: PersistentVolume

    metadata:

    name: azurefile

    spec:

    capacity:

    storage: 5Gi

    accessModes:

    • ReadWriteMany azureFile:

    secretName: azure-secret

    shareName: fileshare01

    readOnly: false mountOptions:

    • dir_mode=0777
    • file_mode=0777
    • uid=1000
    • gid=1000
    • mfsymlinks
    • nobrl

    Then, click Add, as illustrated in the following screenshot. Thiswill create your persistent volume:

    Figure 11.53 – Adding a persistent volume using YAML

    1. Now, to create a persistent volume claim, click Add again, and paste the following YAML. Click Add:

    apiVersion: v1

    kind: PersistentVolumeClaim

    metadata:

    name: azurefile

    spec:

    accessModes:

    • ReadWriteMany storageClassName: “” resources:

    requests: storage: 5Gi

    1. You now have a persistent volume claim. Click on the Persistent volume claims tab, as illustrated in the following screenshot:

    Figure 11.54 – Persistent volume claims tab

    1. Note your persistent volumes by clicking on the Persistent volumes tab, as illustrated in the following screenshot:

    Figure 11.55 – Persistent volumes tab

    You have successfully added persistent storage to your AKS cluster. You now know the tasks involved to achieve this goal. In the next section, we will explore AKS scaling.

    More Details
    Apr 6, 2024
    Configuring scaling for AKS – Creating and Configuring Containers

    Configuring scaling for AKS

    You will note that from our previous exercises, there was no option to automatically scale and resize containers. The only way to change this was to redeploy our container instances and groups. With Kubernetes, this dynamic changes as you can change the scale settings before and after your deployment, and they can be configured to scale manually or automatically. For this exercise, we will run through changing the auto-scale settings of our AKS cluster. Proceed as follows:

    1. Sign in to the Azure portal at https://portal.azure.com.
    2. Navigate to the AKS cluster you created in the previous section. On the left menu, select the Node pools option and click on your deployed agentpool node pool, as illustrated in the following screenshot:

    Figure 11.56 – Configuring a Kubernetes cluster: Node pools

    1. Selecting either the Overview or Configuration pane will present you with the option to change your pool scale settings. Click Scale node pool, as illustrated in the following screenshot:

    Figure 11.57 – Configuring a Kubernetes cluster: Overview

    1. To change the automatic scale option, set the Scale method type to Autoscale, enter a value for your Min and Max node count, then click Apply. The process is illustrated in the following screenshot:

    Figure 11.58 – Configuring a Kubernetes cluster: Scale node pool

    1. For the manual scale option, set the Scale method type to Manual, enter a Node count value (this will be the number of nodes you want to run), and click Apply. The process is illustrated in the following screenshot:

    Figure 11.59 – Configuring a Kubernetes cluster: Scale node pool (continued)

    1. After applying the settings, you will notice your agent pool goes into an Updating state, as illustrated in the following screenshot:

    Figure 11.60 – Configuring a Kubernetes cluster: Updating

    You now know how to scale your agent pools within AKS and can feel confident about managing this aspect. If you would like to change the VM size for the agent pool, you will need to redeploy the pool. In the next section, we will look at managing network configurations on your AKS cluster.

    More Details
    Mar 10, 2024
    Configuring network connections for AKS – Creating and Configuring Containers

    Configuring network connections for AKS

    We have covered AKS cluster deployment in one of the previous exercises. In this section, we will elaborate on some networking configurations to give you a better understanding of the options available to you.

    Network configuration

    The first component in your network configuration is the different types of networks that are available for you to deploy.

    kubenet

    This is the most basicnetworking service for AKS. With kubenet, an IP address is allocated from an Azure VNet to the nodes for a Pod. The Pods receive an IP address from an internal network that is deployed in a logically different address space from the VNet. Connections to these Pods are then performed through NAT connections that allow Pods to communicate to resources on the Azure VNet. This approach reduces the number of IP addresses required for your solution but disables the ability to directly connect to your containers.

    Azure CNI

    This is a moreadvanced implementation networking service for AKS. Azure CNI enables Pods to be directly connected to an Azure VNet, and therefore every Pod is allocated an IP address on the VNet. Without careful planning, you may exhaust your IP allocation on the subnet you are connecting to.

    Regardless of the solution you choose, external traffic is still conducted over a NAT connection to nodes within AKS from a public IP interface.

    Traffic routing

    Traffic routing comprisesthe load balancing and application routing configurations available to your AKS cluster.

    Load balancer

    The AKS cluster can be deployed using both a standard SKU and a basic SKU. A standard SKU enforces traffic securely, restrictstraffic by default, andrequires explicit allow rules to enable traffic flow. The default option Standardis and is the recommended choice unless there is a specific reason for Basic, such as your organization only allowing private IP access. Basic can only be deployed using the Azure command-line interface (CLI), PowerShell, or an ARM template.

    Enabling HTTP application routing

    Please note before enabling this feature that it is currently not designed or ready for production environments and is something I would advise being cautious about enabling until Microsoft’s documentation reflects that this is ready for production use.

    The solution deploys two components, one being an External-DNS controller component, which creates DNS host A records for the cluster DNS zone, and the second resource being an ingress controller component, which is responsible for routing ingress traffic to application endpoints.

    More Details
    Feb 5, 2024
    Security – Creating and Configuring Containers

    Security

    When configuring your network for AKS, you should consider the security components that also impact your design and management decisions. There are several items to consider (which we discuss in the following sections) that can improve the security of your containers.

    Enabling a private cluster

    For enhanced security, you can enable a private cluster. This ensures that trafficbetween your application programming interface (API) server and node pools is conducted over private network paths only. When configured, the control plane (API server) is run within the AKS-managed Azure subscription while your AKS cluster runs in your own subscription. This separation is key. Communication will thenoccur over a private endpoint (private link) from your AKS cluster to the private link service for the AKS VNet.

    Setting authorized IP ranges

    These are ranges that you will limit to accessing your AKS cluster. This can be specified as a single IP, as a list of IP addresses, or as a range of IP addresses in classless inter-domain routing (CIDR) notation.

    The following screenshot is an example of setting authorized IP addresses:

    Figure 11.61 – Authorized IP addresses

    You now understand the role that authorized IP ranges play in your AKS deployment.

    Next, we will explore the impact that network policy has on deployments.

    Network policy

    This is used tomanage traffic flow between Pods in an AKS cluster. By default, alltraffic is allowed, and by utilizing network policy, you enable the mechanism to manage this traffic using Linux iptables. Two implementations can be followed: Calico and Azure Network Policies. Calico is an open source solution provided by Tigera, whereas Azure has its ownimplementation of the same type of technology. Both services are fully compliant with the Kubernetes specification. The choice of network policy provider can only be chosen on the creation of the AKS cluster and can’t be changed, so it’s pivotal that you understand the differences between the solutions prior to making your choice.

    The key differences between the solutions are presented here:

    More Details
    Jan 4, 2024
    Upgrading an AKS cluster – Creating and Configuring Containers

    Upgrading an AKS cluster

    You have the choice to automatically upgrade your AKS clusters or to manually manage upgrades yourself. As part of your upgrade decisions, you can decide if you would like to upgrade both the node pools and control plane or the control plane only. Automatic upgrades have the option of choosing different channels that best apply to your requirements; these are listed as follows:

    • None: Used for disabling auto upgrading.

    • Patch: The cluster is automatically updated to the latest support patch version.

    • Stable: The cluster is automatically updated to the latest stable version.

    • Rapid: The cluster is automatically updated to the latest N-2 minor version.

    • Node-image: The cluster is automatically updated to the latest version available.

    Top Tip

    It’s important to note that when upgrading your AKS clusters, you will upgrade to a supported patch version for your cluster, one version at a time where more than one version upgrade exists.

    We will now perform the exercise of upgrading your cluster with the following steps:

    1. Sign in to the Azure portal at https://portal.azure.com.
    2. Navigate to the AKS cluster you created in the previous section. On the left menu, select the Cluster configuration option and click Upgrade version on the right, as illustrated in the following screenshot:

    Figure 11.62 – Cluster configuration

    1. Select your desired Kubernetes version and select an Upgrade scope type, then click Save. The process is illustrated in the following screenshot:

    Figure 11.63 – Upgrading the version of Kubernetes

    You have just successfully upgraded your Kubernetes version and understood the various automated options also available to do this. Next, we will run through the chapter summary and all that we have covered in this chapter.

    Summary

    In this chapter, we discovered what containers are and how we deploy and manage them, we learned about Docker, the limitations of Docker, and container deployments, and finally, we found out how we can extend default container services through orchestration tools such as Kubernetes that greatly enhance the way we manage and scale containers. As part of your learning, you have discovered how to work with ACI Instances and learned how to also attach persistent storage to containers using AKS, how to enhance the security around containers, and about the various networking options available to you as part of AKS. You also experienced working with deployments and administrative tasks such as creating an Azure container registry, deploying Azure container instances, and creating and configuring Azure container groups.

    You should now feel confident about the administration of containers within Azure, the methods of deployment, and how to orchestrate and manage these.

    In the next chapter, we will explore Azure App Service, what this is, how to configure and deploy it, and becoming confident in how to use this on Azure.

    More Details
    Sep 10, 2023
    Understanding App Service plans and App Service – Creating and Configuring App Services

    Understanding App Service plans and App Service

    When discussing Azure app services and understanding what they are, compared to traditional servers, it’s important to understand the relationship between Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), andserverless (such as Function as a service (FaaS)). As you move through the different service offerings, you have different layers of responsibility that you manage. This is also the easiest way of understanding the differences between the services. IaaS, PaaS, SaaS, and serverless are cloud-based services and fit well into the Azure platform since Microsoft has developed some great ways to manage the services you deploy. This also allows you to choose the level of control you would like to adopt. There are limitations to each model, which is a much deeper topic, but understanding these limitations at a core level will help you succeed in your Azure journey. The following diagram illustrates the management relationships between the cloud-based services:

    Figure 12.1 – Shared responsibility model

    As you can see, the closer you approach SaaS, the fewer components you are required to manage and, subsequently, can manage. Finally, the serverless component can be a little confusing as it falls between the PaaS and SaaS layers; you can only manage your code and, ideally, split your code into single repeatable components called functions. Serverless components are also classified as microservices since the services are broken down into their most basic forms. Here, you define the functions you need to run your code; you can deploy the code and forget about which server it runs on. This approach does lead to more in-depth and complex discussions that are beyond the scope of this book; you just need to understand that this exists and that in Azure, we often refer to it as FaaS. Now that you understand the relationship between these services and what you manage, we can classify Azure app services. They fall into the PaaS category; therefore, you only have to worry about how you manage your application and its data. You also have the choice to secure your application using controls that have been exposed to Azure. The rest is taken care of by the platform itself.

    App Service plans

    To run your applications, you must deploy and configure your server infrastructure appropriately to suit your applications. For example, your applications may require the Windows operating system and the .NET Framework. To accommodate these configurations, Azure has App Service plans. This is a server that’s related to your application deployments, where you can choose an operating system, the number of nodes in your cluster, server-related security configurations, and operations. It also allows you to run several applications against a server with the chosen specifications for memory and CPU resources and only scales as per your requirements or budget.

    Top Tip

    Although Azure Functions falls into the serverless category, when assigned to an App Service plan, it becomes a PaaS service since it is linked to a server. This increases what you can manage on the service and allows better control over, for example, security features.

    Now that you understand more about Azure App Service and App Service plans, let’s dive into some exercises where we will work with these later. In the next section, we will deploy an App Service plan and dive into the available configuration options.

    More Details
    Jul 4, 2023
    Creating an App Service plan – Creating and Configuring App Services

    Creating an App Service plan

    In this exercise, you will be creating an App Service plan for Azure. This will act as the server configuration for hosting your Azure web applications and function applications. Follow these steps to do so:

    1. Sign in to the Azure portal at https://portal.azure.com.
    2. Open the resource group you will be using for this exercise, click Overview via the left menu, and clickCreate.
    3. Type app service plan in the search bar and click App Service Plan:

    Figure 12.2 – App Service Plan

    1. On the next screen, click Create:

    Figure 12.3 – App Service Plan – Create

    1. Enter the name of your Resource Group, then enter a name for your App Service plan. Here, we have used myappserviceplan. Next, choose an Operating System. For this demo, we will deploy a Windows App Service plan. Finally, select your Region and SKU and size; we will select Standard S1. Click Review + create, then Create:

    Figure 12.4 – Create App Service Plan

    With that, you have configured your first App Service plan and are ready to host your first application on the service. In the next section, you will learn how to create an App Service in your newly deployed App Service plan.

    Creating an app service

    In this exercise, you will deploy your first web application in Azure using the Azure Web Apps service. Follow these steps:

    1. Sign in to the Azure portal at https://portal.azure.com.
    2. Open the resource group you will be using for this exercise, click Overview via the left menu, and clickCreate.
    3. From the left menu bar, clickWeb, then click Create under Web App:

    Figure 12.5 – Web App

    1. Enter the name of your Resource Group, then enter a name for your web app. Here, we have used myfirstwebapp221221. Next, choose the type of deployment you would like. We will select Code. Note that you could also select a Docker Container. Then, select a Runtime stack – this will support the code you are deploying. Now, choose an Operating System. For this demo, we will deploy a Windows web app; we did this for the App Service plan we deployed previously. Select your Region, this will also be the same as what you selected for your App Service plan:

    Figure 12.6 – Create Web App – Basics

    Finally, select a Windows Plan – this is the App Service plan you created previously. Note that when you select this, it automatically configures your SKU and size, which will match what you chose for your App Service plan. Also, note that you have the option to create your App Service plan directly in the Deployment menu. Click Next : Deployment >:

    Figure 12.7 – Create Web App – Basics 2

    1. Here, you have the option to do a Continuous deployment. We won’t be configuring this in this exercise. Click Next : Monitoring >:

    Figure 12.8 – Create Web App – Deployment

    1. On the Monitoring tab, you will have the option to deploy Application Insights for your application. Note that you can either create a new Application Insights deployment through this blade or create it as part of the deployment. For this exercise, we will select No for Enable Application Insights. Click Review + create, then Create:

    Figure 12.9 – Create Web App – Monitoring

    1. Navigate to your application, click on Overview via the left-hand menu, and note your URL for your application. This blue text is clickable; you can either click on this or copy it into your browser to navigate to your application to confirm that it’s working:

    Figure 12.10 – Web App – Overview

    You will be presented with a screen similar to the following for your application. Congratulations – you have successfully deployed your application using the Azure portal!

    Figure 12.11 – Web App – running in your browser

    Now that you know how to deploy a web application using the Azure portal, let’s learn how to do the same using PowerShell. This time, we will create a Linux service plan.

    More Details
    Mar 4, 2023
    PowerShell scripts 2 – Creating and Configuring App Services

    Here, you scaled down your application from the S1 SKU to the B1 SKU, which shows how easy it is to change its size. Note that the application will restart upon being resized. You will need to resize the application so that it’s a production SKU for the next exercise. When changing its size, select Production and click See additional options. Click S1 and then Apply:

    Figure 12.13 – Scaling up to S1

    Now, let’s learn how to scale out horizontally:

    1. Navigate to the App Service plan you worked on in the previous exercise.
    2. From the left menu blade, under theSettings context, click Scale out (App Service plan).
    3. Note that you can choose either Manual scale or Custom autoscale. Here, it would be best to manually scale since you are working on Dev / Test workloads, but for production workloads, you should choose Custom autoscale. Change Instance count to 2 and click Save:

    Figure 12.14 – Manual scale

    1. Now, change the setting to Custom autoscale. Enter a name for your Autoscale setting name and select your Resource group:

    Figure 12.15 – Custom autoscale

    For our Default scale condition, we will create the first one using Scale based on a metric for Scale mode, and we will set Instance limits to 1 for Minimum, 2 for Maximum, and 1 for Default. Then, click Add a rule:

    Figure 12.16 – Scale condition setup

    1. For the Criteria section, set Time aggregation to Average, Metric namespace to App Service plans standard metrics, and Metric name to CPU Percentage. Set Operator to = and Dimension Values to All values (this means any web app).

    Note the timeline chart at the bottom of the screen, which indicates the average CPU percentage that you have experienced over time, with the average also written below it. In this case, it is 3.78 %:

    Figure 12.17 – Scale rule

    1. Below the CPUPercentage (Average) section, you will notice some other configuration options. Set Operator to Greater than and Metric threshold to trigger scale action to 70. Then, set Duration (minutes) to 10 and Time grain statistic to Average. This will define a rule that states that when the CPU average percentage reaches greater than 70% usage over 10 minutes, it will trigger an Action.
    2. For the Action section, set Operation to Increase count by, Cool down (minutes) to 5, and Instance count to 1. This will increase the instance count of the running web applications by 1 when the criteria that we configured in step 7 have been identified. Once triggered, a cooldown period will occur, where no further actions can be performed until the cooldown window has elapsed. In this case, it is 5 minutes. If the criteria for scaling are observed again after this cooldown period, then the action will be triggered again. Click Add:

    Figure 12.18 – Configuring a scale rule – Thresholds

    1. You have just configured a rule for scaling your application up in terms of its instance count, but what if you would like the application to scale back down when you don’t need as many instances anymore? You would need to configure a new scale condition to trigger a scale-down action you would like to perform. Click + Add a rule below the Scale out rule you just created:

    Figure 12.19 – Add a rule

    1. For the Criteria section, set Time aggregation to Average, Metric namespace to App Service plans standard metrics, and Metric name to CPU Percentage. Set Operator to = and Dimension Values to All values (this means any web app).

    Note that the timeline chart at the bottom of the screen indicates the CPU percentage average that you have experienced over time, with the average also written below it. In this case, it is 2.55 %:

    Figure 12.20 – Scale rule

    1. Below the CPUPercentage (Average) section, you will notice some other configuration options. Set Operator to Less than and Metric threshold to trigger scale action to 30. Then, set Duration (minutes) to 10 and Time grain statistic to Average. This will define a rule that states that when the CPU average percentage reaches less than 30% usage over 10 minutes, it will trigger an Action.
    2. For the Action section, set Operation to Decrease count by, Cool down (minutes) to 5, and Instance count to 1. This will decrease the instance count of the running web applications by 1 when the criteria that we configured in Step 11 have been identified. Once triggered, there will be a cooldown period where no further actions can be performed until the cooldown window has elapsed. In this case, it is 5 minutes. If the criteria for scaling are observed again after this cooldown period, then the action will be triggered again. Click Add:

    Figure 12.21 – Scale rule – Threshold and Action sections

    1. Click Save.

    Now that you have configured your autoscale rules using the Azure portal, let’s learn how to use PowerShell to do the same.

    More Details