An ASMAdaptiveConcurrency CustomResourceDefinition (CRD) can dynamically adjust the maximum number of concurrent requests that are allowed for a service based on the sampled request data. If the number of concurrent requests exceeds the maximum value supported by the service, excess requests are rejected to protect the service. This topic describes how to use an ASMAdaptiveConcurrency CRD to implement adaptive concurrency control.
Prerequisites
A Service Mesh (ASM) instance whose version is 1.12.4.19 or later is created. For more information, see Create an ASM instance.
The cluster is added to the ASM instance. For more information, see Add a cluster to an ASM instance.
A kubectl client is connected to the cluster. For more information, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.
Background information
Services are expected to reject excess requests if the load capacity is exceeded. This prevents other chain reactions. You can configure destination rules for an ASM instance to implement basic circuit breaking. You must specify a threshold for triggering circuit breaking, such as a specific number of pending requests. If the number of access requests on the data plane of the ASM instance exceeds the threshold, excess requests are rejected.However, it is difficult to accurately estimate the load capacity of a service in actual scenarios.
An ASMAdaptiveConcurrency CRD uses an adaptive concurrency control algorithm to dynamically adjust the concurrency limit for a service by periodically comparing the sample latency with the calculated minimum latency and performing a series of computations. This way, the concurrency limit is near the load capacity of the service, and excess requests are rejected. If a request is rejected, the HTTP status code 503 and the error message reached concurrency limit
are returned.
During the periodic calculation of the minimum round-trip time (MinRTT), the number of connections is limited to a small value that is specified by the min_concurrency parameter. After you create an ASMAdaptiveConcurrency CRD for a service, we recommend that you create a destination rule to enable the retry feature for the service. This way, the requests that are rejected during MinRTT calculation can be served as much as possible based on the retries of the sidecar proxy.
Step 1: Deploy sample applications
Deploy the testserver and gotest applications. Set the load capacity of the testserver application to 500 concurrent requests. Requests that exceed the concurrency limit are queued for processing. Set the time required to process each request to 1000 ms. Set each replica of the gotest application to initiate 200 requests at a time.
Deploy a testserver application.
Create a testserver.yaml file that contains the following content:
The
-m
parameter specifies the maximum number of concurrent requests that the application supports. The-t
parameter specifies the time required to process each request.Run the following command to deploy the testserver application:
kubectl apply -f testserver.yaml
Deploy a Service named testserver in the testserver application.
Create a testservice.yaml file that contains the following content:
Run the following command to deploy the testserver Service:
kubectl apply -f testservice.yaml
Deploy a gotest application.
Create a gotest.yaml file that contains the following content:
Run the following command to deploy the gotest application:
kubectl apply -f gotest.yaml
Step 2: Create an ASMAdaptiveConcurrency CRD
Use kubectl to connect to your ASM instance. For more information. see Use kubectl on the control plane to access Istio resources.
Create an adaptiveconcurrency.yaml file that contains the following content:
Run the following command to create an ASMAdaptiveConcurrency CRD:
kubectl apply -f adaptiveconcurrency.yaml
Step 3: Enable Managed Service for Prometheus
To help you understand the running status of the concurrency controller and optimize the parameters, you can export the metrics related to adaptive concurrency control to Managed Service for Prometheus. You can view the running status of the concurrency controller in the Managed Service for Prometheus console.
Enable Managed Service for Prometheus. For more information, see Managed Service for Prometheus.
Configure ServiceMonitor in the cluster so that Managed Service for Prometheus can obtain the data of the testserver Service.
Create a servicemonitor.yaml file that contains the following content:
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: testserver-envoy-metrics namespace: default spec: endpoints: - interval: 5s path: /stats/prometheus port: metrics namespaceSelector: any: true selector: matchLabels: app: testserver
Use kubectl to connect to the ACK cluster based on the information in the kubeconfig file, and then run the following command to create a ServiceMonitor:
kubectl apply -f servicemonitor.yaml
Step 4: Verify whether the ASMAdaptiveConcurrency CRD takes effect
Set the number of replicas to 5 for the gotest application.
A replica of the gotest application initiates 200 requests at a time. Five replicas of the application initiate 1,000 requests at a time in total.
Log on to the ACK console.
In the left-side navigation pane of the ACK console, click Clusters.
On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
In the left-side navigation pane of the details page, choose .
On the Deployments page, set Namespace to default and choose in the Actions column of the gotest application.
In the Edit YAML dialog box, set
replicas
to5
and click Update.
Upload the following JSON file to import a Grafana dashboard. You can view the running status of the concurrency controller on the imported dashboard. For more information, see ARMS documentation.
On the dashboard, select the cluster in which the ASMAdaptiveConcurrency CRD resides. Set the Service parameter to testserver and the Pod parameter to ALL.
The gotest application initiates 1,000 requests to the testserver Service, but the number of concurrent requests that are processed by the testserver Service is lower than 500. This indicates that the ASMAdaptiveConcurrency CRD takes effect.