The Service Mesh (ASM) traffic scheduling suite provides a non-intrusive and scalable dynamic traffic scheduling architecture for centralized management and control of all traffic in a distributed system. This helps you enhance the reliability of cloud-native distributed applications, reduce costs, and improve resource utilization. This topic describes the ASM traffic scheduling suite and its features.
What is the ASM traffic scheduling suite?
The ASM traffic scheduling suite is an ASM-based centralized traffic scheduling architecture model. It is designed to schedule and manage requests in cloud-native distributed applications in a centralized manner.
The ASM traffic scheduling suite, consisting of the Agent and the controller, provides a series of preset traffic scheduling policies. These policies are published by the controller to the Agent, to dynamically control traffic scheduling. When a sidecar proxy forwards inbound or outbound requests of a pod, the Agent passes traffic scheduling decisions to it to throttle or queuing these requests.
Enable the ASM traffic scheduling suite
ACK Serverless and Container Compute Service (ACS) do not support the ASM traffic scheduling suite.
To use the ASM traffic scheduling suite, make sure that the version of your ASM instance is 1.21.6.82 or later and that a Kubernetes cluster is added to your ASM instance. For more information, see Add a cluster to an ASM instance.
To enable the ASM traffic scheduling suite, follow the steps below:
On ASM console
Log on to the ASM console. In the left-side navigation pane, choose .
Click the name of the ASM instance. In the left-side navigation pane, choose .
Select the Advanced Traffic Scheduling tab and click Enable Traffic Scheduling.
Refer to the table below, and the click OK.
Configuration item
Description
Storage Class
Valid storage classes that are necessary for traffic scheduling suite to implement data exchange between scheduling agents and metadata.
Configure Resource
Configurations for Agent Pod.
Limit default to 2 CPU and 1024MiB.
Request default to 0.5CPU and 512MiB.
Timeout Period
The traffic scheduling suite supports queuing requests when the system is overloaded. Requests queued for a specified period will be discarded.
Effective Scope
If not configured, it defaults to global scope. Supported scopes include:
Gateway scope: Applies to resources associated with a specific gateway.
Workload scope: Applies to a specific workload.
Namespace scope: Applies to a specific namespace.
By kubectl
Use kubectl to connect to the ASM instance. For more information, see Use kubectl on the control plane to access Istio resources.
Run the following command:
kubectl patch asmmeshconfig default --type=merge --patch='{"spec":{"adaptiveSchedulerConfiguration":{"enabled":true,"schedulerScopes":[{"namespace":"default"}]}}}'
Traffic scheduling policies supported by the ASM traffic scheduling suite
The following table describes the policies supported by the ASM traffic scheduling suite.
Policy | Description | References |
Traffic rate limiting | A traffic rate limiting policy is created by using the RateLimtingPolicy CustomResourceDefinition (CRD). Such a policy provides global throttling for specified services in an ASM instance. Compared with the throttling solution provided by open source Istio, a policy created by using the RateLimtingPolicy CRD supports advanced throttling features such as user-specific throttling, setting burst traffic windows, and configuring a custom consumption rate for request tokens. | Use RateLimitingPolicy to implement user-specific throttling |
Priority-based request scheduling based on the average latency | A priority-based request scheduling policy compares the real-time latency with the historical average latency to determine whether traffic overload occurs. If traffic overload occurs, scheduling mechanisms based on token bucket and priority are used to schedule requests. When the system is overloaded, high-priority requests can be processed preferentially. | Use AverageLatencySchedulingPolicy to implement priority-based request scheduling |
Concurrency control | Concurrency control maintains a record of requests that are being processed (that is, requests that have been sent but not yet responded to). When the number of requests that are being processed exceeds the specified limit, subsequent incoming requests are rejected. | Use ConcurrencyLimitingPolicy to implement request concurrency limiting |
Priority-based request scheduling under controlled concurrency | ConcurrencySchedulingPolicy determines whether traffic is overloaded based on the limits on concurrent requests. When the number of concurrent requests exceeds the specified upper limit, subsequent requests are queued and scheduled based on their priorities. | |
Progressive service release policy | The ASM traffic scheduling suite supports progressive service release policies. When you release a new service, you can configure a progressive release policy to gradually increase the traffic received by the service. This ensures that the service is smoothly released. | Use LoadRampingPolicy to implement progressive service release |
Priority-based request scheduling with a specified request quota | When the number of requests being processed in a unit time in the system exceeds the specified quota, subsequent requests will be queued and high-priority requests can be processed preferentially. | Use QuotaSchedulingPolicy to implement request call quota management |
Configurations for collecting the monitoring metrics of ASM traffic scheduling suite
If your Kubernetes clusters are integrated with Managed Service for Prometheus instances or self-built Prometheus instances, you can perform the following configurations to collect the monitoring metric of an ASM request scheduling agent. This helps you to verify whether a specific policy in ASM traffic scheduling suite takes effect.
Managed service for Prometheus
Run the following codes to add a custom collection rule. For more information, see Other Prometheus service discovery configurations.
scrape_configs:
- job_name: asm-adaptive-scheduler-stats
scrape_interval: 30s
scrape_timeout: 30s
metrics_path: /metrics
scheme: http
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels:
- __meta_kubernetes_namespace
action: keep
regex: istio-system
- source_labels:
- __meta_kubernetes_pod_container_port_name
action: keep
regex: server
- source_labels:
- __meta_kubernetes_pod_container_name
action: keep
regex: aperture-agentSelf-built Prometheus instances
Add the JSON file of Managed service for Prometheus to the scrape_configs nodes of Prometheus instances. For more information, see Prometheus configuration.