Approach 3: Deploying the Tanzu Service Mesh Service Autoscaler Through CRD

To scale the microservices in your application, you need to deploy Tanzu Service Mesh Service Autoscaler by applying a Definition custom resource to each microservice to be scaled.

The Definition custom resource was created specifically for Tanzu Service Mesh Service Autoscaler to implement and customize the autoscaler. Enabling the autoscaler is easy if you are familiar with Kubernetes and the kubectl client. You can see the actions of the autoscaler (if enabled) from both the command line, using kubectl commands, and the Tanzu Service Mesh Console user interface, where graphs of service instance counts and metrics are displayed.

Important:

Autoscaling with the Definition custom resource is only available for services directly in cluster namespaces. The Definition custom resource is not available for services inside a global namespace.

You do not need to install the custom resource definition on your cluster. During onboarding, Tanzu Service Mesh Lifecycle Manager Operator automatically installs this custom resource definition on the cluster.

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.

Warning:

If you create a GNS-scoped autoscaling policy through UI and an org-scoped autoscaling policy through CRD for a target service, the GNS-scoped policy will override the org-scoped policy.

Prerequisites

Onboard your Kubernetes clusters to Tanzu Service Mesh.
Verify that your clusters use Tanzu Service Mesh Data Plane version 4.3.0 or later.

Procedure

Install the microservices application on the onboarded cluster.
1. Create a namespace for the application.
```
kubectl create namespace {namespace}
```
2. Verify that Tanzu Service Mesh is enabled in the namespace by checking the list of namespace exclusions for the cluster.
  You can view the list of namespace exclusions for the cluster in the Edit Cluster dialog box. The defined exclusions are displayed under Namespace Exclusions in the dialog box. If the namespace does not match any of the exclusions, Tanzu Service Mesh is enabled in it. For more information about viewing the namespace exclusions for a cluster, see Edit a Cluster in the Getting Started with Tanzu Service Mesh documentation.
  
  To verify that the namespace has Tanzu Service Mesh enabled in it, you can also run the following command.
```
kubectl --context {cluster} get ns {namespace} -L istio-injection
```
  Where {cluster} is the name of your cluster and {namespace} is the name of the namespace. If the output contains enabled under the ISTIO-INJECTION column, Tanzu Service Mesh is enabled in the namespace.
3. Create a Deployment manifest for every microservice in the application.
4. (Optional) To allow scaling to calculate resource usage percentages, set the resources.requests for every container in the Deployment manifests.
5. (Optional) To ensure that the application is healthy and is displayed as such, specify liveness and readiness probes that Kubernetes can use.
6. To apply the Deployment manifests, run the following command for every microservice.
```
kubectl apply -n {namespace} -f {manifest yaml file} 
```
Create a Definition custom resource manifest yaml (see Configuration Example 1) for every service to be autoscaled.

Important:
Ensure that there is only one autoscaling definition per service with the name set in scaleTargetRef.kubernetes.name. For more information, see the spec.scaleTargetRef.kubernetes section in Tanzu Service Mesh Service Autoscaler Configuration Details.

For the properties to configure, refer to the Tanzu Service Mesh Service Autoscaler Configuration Reference.
To apply each created Definition custom resource manifest (yaml) file, run this command.
```
kubectl apply -f <definition manifest yaml file> -n <namespace>
```
After the Definition custom resource is applied, to see the status of scaling, run the following command.
```
kubectl get definition -n {namespace}
```
Note:
You can also use asd in this and other kubectl commands. asd is the short name of the Definition custom resource definition.

See an example output of this command in Configuration Example 2.
Note:
To see the status of scaling with more details of a particular Definition custom resource, run this command.
```
kubectl describe definition frontend-asd -n {namespace}
```
In the command above, frontend-asd is the name of a specific custom object of the Definition custom resource.

See Configuration Example 3.
To change the Definition custom resource, edit the manifest file (for example, frontend-asd.yaml) and re-apply it.
```
kubectl apply -f frontend-asd.yaml -n {namespace}
```

What to do next

You can now view the Definition custom resource through the Tanzu Service Mesh Console UI. To see the autoscaling policy created using the Kubernetes CRD, perform these steps.

In the navigation panel on the left, click Autoscaling Policies.
To view the policy details, expand the autoscaling definition.

Note:

From the Tanzu Service Mesh Console UI, you can only view the autoscaling definition, but you cannot modify it.

To see autoscaling at work (if it has been enabled) in the Tanzu Service Mesh Console user interface, perform these steps.

In the navigation panel on the left, click Home.
On the Home page, click the Cluster Overview tab.
Click the cluster that has a service being autoscaled.
In the service topology graph, click a microservice.
Click the Performance tab.
In the upper-right corner of the tab, click Chart Settings to show service instances and other metrics of interest. You can select a maximum of four metrics to be displayed.

To access the autoscaling endpoints in the Tanzu Service Mesh API through the API Explorer, perform these steps.

On the bottom of the Tanzu Service Mesh Console UI, toward the right, click API Explorer.
On the Rest HTTP tab, expand the Autoscaling section and click the GET /v1alpha1/ autoscaling/configs endpoint.

This endpoint gets a list of all autoscaling policies and their details.

If you no longer need autoscaling, delete the Definition custom resource.

kubectl delete definition frontend-asd -n <namespace>

In the command above, frontend-asd is the name of the specific custom object of the Definition custom resource that is deleted.

For more examples and explanations, check out the sample apps placed in GitHub and test out the commands above on Tanzu Service Mesh with detailed instructions on how to deploy autoscaler to a sample app on cluster:

https://github.com/vmwarecloudadvocacy/acme_fitness_demo

https://github.com/vmware-samples/