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, and a collective name for various traffic scheduling policies developed based on this architecture model. It is designed to schedule and manage requests in cloud-native distributed applications in a centralized manner. These capabilities can enhance the reliability of cloud-native distributed applications as well as reducing costs and improving resource utilization.
The core architecture of the ASM traffic scheduling suite mainly consists of the ASM request scheduling controller and the ASM request scheduling agent. When a sidecar proxy forwards inbound or outbound requests of a pod, the sidecar proxy interacts with the ASM request scheduling agent to obtain traffic scheduling decisions from the agent. Then, the sidecar proxy performs throttling and queuing on the requests. The ASM traffic scheduling suite provides a series of preset traffic scheduling policies. These policies are published by the ASM request scheduling controller to the ASM request scheduling agent to dynamically control traffic scheduling.
Enable the ASM traffic scheduling suite
Before you enable the ASM traffic scheduling suite, make sure that storageclasses named alibabacloud-cnfs-nas exists in the corresponding cluster on the data plane. For more information about how to create a StorageClass, see StorageClasses.
ACK Serverless does 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, perform the following steps:
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. In this way, you can verify whether a specific policy in ASM traffic scheduling suite takes effect.
Managed service for Prometheus
You can 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
You need to add the JSON file of Managed service for Prometheus to the scrape_configs nodes of Prometheus instances. For more information, see Prometheus configuration.