Use load-aware scheduling

Prerequisites

• The ack-koordinator component of version 1.1.1-ack.1 or later is installed. For more information, see ack-koordinator (ack-slo-manager).

• The ACK kube-scheduler in your cluster must use a version that supports load-aware scheduling. See the table below for details.

  ACK version	Supported ACK scheduler version
  1.26 or later	All versions are supported.
  1.24	v1.24.6-ack-4.0 or later
  1.22	v1.22.15-ack-4.0 or later

Billing

The ack-koordinator component is free to install and use. However, additional fees may be incurred in the following scenarios:

• ack-koordinator is a self-managed component and consumes worker node resources after installation. You can configure the resource requests for each module when you install the component.

• By default, ack-koordinator exposes monitoring metrics for features such as resource profiling and fine-grained scheduling in Prometheus format. If you select the Enable Prometheus Monitoring for ACK-Koordinator option when you configure the component and use the Alibaba Cloud Prometheus service, these metrics are considered custom metrics and incur fees. The fees depend on factors such as your cluster size and the number of applications. Before you enable this feature, carefully read the Billing of Prometheus instances documentation for Alibaba Cloud Prometheus to understand the free quota and billing policies for custom metrics. You can monitor and manage your resource usage by querying usage data.

Limitations

This feature is available only in ACK Pro clusters. For more information, see Create an ACK Pro cluster.

How load-aware scheduling works

Load-aware scheduling is a plugin for the ACK kube-scheduler and is implemented based on the Kubernetes Scheduling Framework. Unlike the native Kubernetes scheduler, which primarily makes scheduling decisions based on resource allocation, the ACK scheduler understands the actual resource load on each node. By analyzing historical load statistics and predicting the needs of new Pods, the scheduler places Pods on nodes with lower loads. This achieves better load balancing and prevents application or node failures caused by overloaded nodes.

As shown in the following figure, Requested represents the amount of resources that are requested, and Usage represents the amount of resources that are actually used. Only the resources that are actually used are counted as the actual load. Given two identical nodes, the ACK scheduler assigns a newly created Pod to Node B, which has a lower load.

To account for dynamic changes in node utilization over time due to the cluster environment and workload traffic, the ack-koordinator component provides a descheduling feature to prevent extreme load imbalance from re-emerging in the cluster after Pods are scheduled. You can achieve optimal cluster load balancing by combining load-aware scheduling with hotspot descheduling. For more information about hotspot descheduling, see Use hotspot descheduling.

Step 1: Enable load-aware scheduling

1. Log on to the ACK console. In the left navigation pane, click Clusters.

2. On the Clusters page, click the name of your cluster. In the left navigation pane, click Add-ons.

3. On the Add-ons page, locate Kube Scheduler, and then on the Kube Scheduler card, click Configuration.

4. In the dialog box, configure the parameters based on the following table and then click OK.

   The following table describes the main parameters for load-aware scheduling. For a detailed description of all parameters and their component version dependencies, see kube-scheduler and Custom scheduler parameters.

   Parameter	Type	Description	Value	Example
   loadAwareThreshold	A list consisting of a resource name (resourceName) and a threshold (threshold).	Specifies the threshold for a resource type based on the node filtering policy.	resourceName: cpu or memory. threshold: An integer from 0 to 100. The default value is empty, which means the filtering feature is disabled.	resourceName: cpu threshold: 80
   loadAwareResourceWeight	A list consisting of a resource name (resourceName) and a weight (resourceWeight).	This is the scoring weight of the resource type for the node sorting strategy. This setting takes effect only if you select Enable load-aware scoring for Pod scheduling.	resourceName: Validated by schema. Only cpu or memory is supported. resourceWeight: An integer from 1 to 100. Default: cpu=1, memory=1.	resourceName: cpu resourceWeight: 1
   loadAwareAggregatedUsageAggregationType	enum	The aggregation type for load statistics. The types are defined as follows: avg: Average value. p50: The 50th percentile value, the median. p90, p95, p99: 90th, 95th, and 99th percentile values, respectively.	avg p50 p90 p95 p99 The default value is avg.	p90

   In the navigation pane on the left, click Cluster Information. On the Basic Information tab, wait for the cluster status to become Running, which indicates that the feature is enabled.

Step 2: Verify load-aware scheduling

The following example uses a cluster with three 4-core, 16 GB nodes.

1. Create a file named stress-demo.yaml with the following YAML content.

   YAML content

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: stress-demo
     namespace: default
     labels:
       app: stress-demo
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: stress-demo
     template:
       metadata:
         name: stress-demo
         labels:
           app: stress-demo
       spec:
         containers:
           - args:
               - '--vm'
               - '2'
               - '--vm-bytes'
               - '1600M'
               - '-c'
               - '2'
               - '--vm-hang'
               - '2'
             command:
               - stress
             image: polinux/stress
             imagePullPolicy: Always
             name: stress
             resources:
               limits:
                 cpu: '2'
                 memory: 4Gi
               requests:
                 cpu: '2'
                 memory: 4Gi
         restartPolicy: Always

2. Run the following command to create a Pod. This will increase the load on one of the nodes.

   kubectl create -f stress-demo.yaml
   # Expected output
   deployment.apps/stress-demo created

3. Run the following command to check the status of the Pod until it is running.

   kubectl get pod -o wide

   Expected output:

   NAME                           READY   STATUS    RESTARTS   AGE   IP           NODE                    NOMINATED NODE   READINESS GATES
   stress-demo-7fdd89cc6b-g****   1/1     Running   0          82s   10.XX.XX.112   cn-beijing.10.XX.XX.112   <none>           <none>

   The output shows that the Pod stress-demo-7fdd89cc6b-g**** is scheduled to the node cn-beijing.10.XX.XX.112.

   Wait about 3 minutes for the Pod to initialize and for the node's load to increase.

4. Run the following command to check the load on each node.

   kubectl top node

   Expected output:

   NAME                    CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.10.XX.XX.110   92m          2%     1158Mi          9%
   cn-beijing.10.XX.XX.111   77m          1%     1162Mi          9%
   cn-beijing.10.XX.XX.112   2105m        53%    3594Mi          28%

   The output shows that the node cn-beijing.10.XX.XX.111 has the lowest load, while the node cn-beijing.10.XX.XX.112 has the highest load. This indicates an uneven load distribution in the cluster.

5. Create a file named nginx-with-loadaware.yaml with the following YAML content.

   YAML content

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-with-loadaware
     namespace: default
     labels:
       app: nginx
   spec:
     replicas: 6
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         name: nginx
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx
           resources:
             limits:
               cpu: 500m
             requests:
               cpu: 500m

6. Run the following command to create the Pods.

   kubectl create -f nginx-with-loadaware.yaml
   # Expected output
   deployment/nginx-with-loadaware created

7. Run the following command to view the Pod scheduling details.

   kubectl get pods -l app=nginx -o wide

   Expected output:

   NAME                                    READY   STATUS    RESTARTS   AGE   IP             NODE                       NOMINATED NODE   READINESS GATES
   nginx-with-loadaware-5646666d56-2****   1/1     Running   0          18s   10.XX.XX.118   cn-beijing.10.XX.XX.110    <none>           <none>
   nginx-with-loadaware-5646666d56-7****   1/1     Running   0          18s   10.XX.XX.115   cn-beijing.10.XX.XX.110    <none>           <none>
   nginx-with-loadaware-5646666d56-k****   1/1     Running   0          18s   10.XX.XX.119   cn-beijing.10.XX.XX.110    <none>           <none>
   nginx-with-loadaware-5646666d56-q****   1/1     Running   0          18s   10.XX.XX.113   cn-beijing.10.XX.XX.111    <none>           <none>
   nginx-with-loadaware-5646666d56-s****   1/1     Running   0          18s   10.XX.XX.120   cn-beijing.10.XX.XX.111    <none>           <none>
   nginx-with-loadaware-5646666d56-z****   1/1     Running   0          18s   10.XX.XX.116   cn-beijing.10.XX.XX.111    <none>           <none>

   The output shows that with load-aware scheduling enabled, the scheduler avoids the high-load node cn-beijing.10.XX.XX.112 and schedules the Pods to other, less-loaded nodes.

Related operations

FAQ