Approach 1: Configure a GNS-Scoped Autoscaling Policy Using Tanzu Service Mesh UI

To scale the microservices in your application inside a global namespace, you can create the autoscaling policies through the Tanzu Service Mesh Console UI.

The use of the autoscaler is based on the assumption that resources are available for it to continue to scale out instances. If the cluster becomes resource-constrained, the cluster administrator must handle underlying cluster expansion manually or automatically through additional automation.

Prerequisites

• Onboard your Kubernetes clusters where your services are deployed.

• Configure a global namespace.

Procedure

1. In the navigation panel on the left, select New Workflow > New Policy > Autoscaling Policy.

   Alternatively, you can create the autoscaling policy by navigating to the panel on the left and selecting Configuration > Autoscaling Policy . In the upper-right corner of the Autoscaling Policy page, click New Policy.

2. In the New Autoscaling window, provide a name for the autoscaler that is not already in use. Optionally add a description.
3. Select a global namespace from the GNS Scope drop –down menu.
4. Select a target service from the Target Service drop –down menu.
5. Select a service version from the Service Version drop –down menu.

   You can configure only one autoscaling policy per service version.

6. (Optional) Specify a label for the autoscaling policy.
7. Select the Autoscaling Mode: Performance or Efficiency.

   The following screenshot shows the autoscaling policy in the Tanzu Service Mesh Console UI using Performance mode. The highlighted areas are explained in the following step.

   
   
   
8. If you choose to scale by the Performance mode, specify the following fields:

   • Autoscaling Metric. You can select from a range of metrics, such as a latency metric (p90), traffic(requests) or a compute resource metric (CPU and Memory usage). The Autoscaler metric triggers scaling out in performance mode. You can specify a metrics window period over which trigger metric must be monitored by the autoscaler. This value must be an integer between 60 to 3600 seconds.

   • Scale-up Condition. Specify when the scaling up of the instances should occur. The Scale Up Condition defines the maximum threshold value for the trigger metric beyond which the service will be scaled up.

   • Max. Instance Count. Specify the maximum number of instances that the autoscaler can set.

   This screenshot shows an autoscaling policy in the Tanzu Service Mesh Console UI with autoscaling Efficiency mode. The highlighted areas in the screenshot are explained in the following step.

   
   
   
9. If you choose to scale by Efficiency mode, specify the following fields:

   • Autoscaling Metric. You can select from a range of metrics, such as a latency metric (p90), traffic(requests) or a compute resource metric (CPU and Memory usage). The Autoscaler metric triggers scaling up and scaling down in efficiency mode. You can specify metrics window period over which trigger metric must be monitored by the autoscaler. This value must be an integer between 60 to 3600 seconds. The metrics window period specified here is used by the autoscaler as an aggregation window; that is, the metric specified here will be averaged over this window periodically and compared with the scale-up and scale-down threshold values. See details about scale-up and scale-down conditions below.

   • Scale-up Condition. Specify when the scaling up of the instances should occur. The Scale Up Condition defines the maximum threshold value for the trigger metric beyond which the service will be scaled up.

   • Max. Instance Count. Specify the maximum number of instances that the autoscaler can set.

   • Scale-down Condition. Specify when the scaling down of the instances occurs. The Scale-down Condition defines the minimum threshold value for the trigger metric below which the service will be scaled down.Specify the minimum amount of time that must pass before a scale-down action can be allowed after the last scale up or the last scale down. The value must be a positive integer greater than 0. The default value is 300 seconds.

   • Min. Instance Count. Specify the minimum number of instances that the autoscaler can set.

10. Select a scaling method.

    • TSM Default autoscaling. The default autoscaling method where the desired instance count is calculated proportional to the resource consumption or latency values depending on configured trigger metric.

    Note:

    As an example, the following Autoscaler thresholds (CPU Usage) are configured:

    • Scale-up condition. 75 %.

    • Scale-down condition. 30%.

    This is the current service state:

    • Сurrent instance count. 3.

    • Current metric average value. 95%.

    After the autoscaling configuration is applied, this is the expected autoscaling outcome:

    • Desired instance count. 3* 95/ 75 = 3.8 = round up to 4 instances.

    The autoscaler will now scale the service to 4 instances.

    • Stepped autoscaling. If you select Stepped autoscaling, specify these two settings:

    • Scale Up (Performance and Efficiency autoscaling mode). The desired instance count will be incremented by this value from the current instance count.

    • Scale down (Efficiency Mode). The desired instance count will be decremented by this value from the current instance count.

11. Set a Panic Mode.

    There can be situations when service metrics are unavailable for some time, or there could be other error conditions that prevent the autoscaler from calculating a desired instances count. You can instruct the autoscaler on how to react to these conditions in one of the following ways:

    • Do Not Scale Services. Autoscaler will leave the services at their current instance count.

    • Scale to instances. Autoscaler will set the desired count to the specified number here if the current instance count is less than that.

12. On the next page, select what happens when you save policy.

    • Activate Policy. The autoscaling policy will be enforced on the service immediately.

    • Simulation Mode Only. Autoscaling trigger metrics will be monitored, and the desired instance count will be calculated and displayed. However, the autoscaling policy will not be enforced.

13. On the Summary page, review the autoscaling policy and click Save.

Results

The new autoscaling policy appears on the Autoscaling Policies page.

What to do next

To edit an existing autoscaling policy, perform these steps.

1. On the Autoscaling Policies page, click the vertical three dots to the right of the autoscaling policy.

2. On the menu, click Edit Configuration.

3. To advance through the configuration pages after making changes, click Next.

To delete an autoscaling policy that you no longer need, perform these steps.

1. Click the vertical three dots to the right of the autoscaling policy.

2. On the menu, click Delete.

Note:

You can define an autoscaling policy through the Tanzu Service Mesh Console UI before an application is deployed.

To see autoscaling at work in the Tanzu Service Mesh Console UI, perform these steps.

1. In the navigation panel on the left, click Home.

2. On the Home page, click the GNS Overview tab.

3. Click the global namespace that contains the services being autoscaled.

4. In the service topology graph, click a microservice.

5. Click the Performance tab to see the Instance Autoscaling chart.

To find a specific autoscaling policy, use the highlighted filters on the Autoscaling Policies page.

Edit an actionable SLO from the Autoscaling Policies page, as shown in the following screenshot.