Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive
On this page

Load-aware Scheduling

Updated on 2025-02-18 GMT+08:00

Volcano Scheduler offers CPU and memory load-aware scheduling for pods and preferentially schedules pods to the node with the lightest load to balance node loads. This prevents an application or node failure due to heavy loads on a single node.

Prerequisites

Features

The native Kubernetes scheduler schedules resources only based on requested resources. However, the actual resource usage of a pod differs greatly from the requested or limited value of the requested resources, which is the cause of cluster load imbalance.

  1. The actual resource usage of certain nodes in a cluster is far lower than the resource allocation rate, but no more pods are scheduled onto the nodes, leading to resource waste.
  2. The scheduler failed to detect that some nodes in the cluster are overloaded, which could significantly affect the stability of the service.

Volcano resolves the preceding issues based on actual loads. If there are plenty of resources, pods are preferentially scheduled to nodes with the lightest load to balance the load on each node in the cluster.

The status, workload traffic, and requests of a cluster change dynamically, and the resource usage of nodes changes in real time. To prevent extreme load imbalance in a cluster after pod scheduling, Volcano provides load-aware hotspot descheduling for the optimal load balancing of cluster nodes. For details about hotspot descheduling, see Descheduling.

How It Works

Load-aware scheduling is implemented using both Volcano and the CCE cloud native monitoring add-on (kube-prometheus-stack). After load-aware scheduling is enabled, metrics such as CPU and memory loads are defined by following Prometheus adapter rules. Then, the kube-prometheus-stack add-on collects and saves the actual CPU and memory loads of each node based on the defined metric rules. Volcano scores and sorts nodes based on the metric values provided by the kube-prometheus-stack add-on and preferentially schedules pods to the node with the lightest load.

Load-aware scheduling scores each node using the weighted average of the CPU and memory metrics as well as the load-aware scheduling policy and preferentially selects the node with the highest score for scheduling. You can create custom weights for the CPU, memory, and load-aware scheduling policy on the Scheduling tab by choosing Settings in the navigation pane of the target cluster.

The formula for scoring a node is as follows: Weight of the load-aware scheduling policy × [(1 - CPU usage) x CPU weight + (1 - Memory usage) × Memory weight]/(CPU weight + Memory weight)

  • CPU usage: average CPU usage of all nodes in the target cluster in the last 10 minutes (The collection frequency can be modified in the Prometheus adapter rule.)
  • Memory usage: average memory usage of all nodes in the target cluster in the last 10 minutes
  1. After installing the Cloud Native Cluster Monitoring add-on, you need to enable Metrics API to provide container resource metrics such as CPU usage and memory usage.

    NOTE:

    Resource metrics can be provided by Metrics API only when local data storage is enabled for the Cloud Native Cluster Monitoring add-on.

    Check whether Metrics API has been enabled for the cluster. If it is enabled, you can skip this step.

    kubectl get APIServices | grep v1beta1.metrics.k8s.io

    If any command output is displayed, Metrics API is enabled. Skip this step and go to the next step to add metric collection rules.

    If no Metrics API is found, you can manually create an APIService object to enable it.

    1. Create a file named metrics-apiservice.yaml. Example file content:
      apiVersion: apiregistration.k8s.io/v1
      kind: APIService
      metadata:
        labels:
          app: custom-metrics-apiserver
          release: cceaddon-prometheus
        name: v1beta1.metrics.k8s.io
      spec:
        group: metrics.k8s.io
        groupPriorityMinimum: 100
        insecureSkipTLSVerify: true
        service:
          name: custom-metrics-apiserver
          namespace: monitoring
          port: 443
        version: v1beta1
        versionPriority: 100
    2. Create an APIService object.
      kubectl create -f metrics-apiservice.yaml
    3. Check whether Metrics API is enabled for the cluster.
      kubectl get APIServices | grep v1beta1.metrics.k8s.io
      NOTE:

      After Metrics API is enabled, if you need to uninstall the Cloud Native Cluster Monitoring add-on, run the following kubectl and delete the APIService object. Otherwise, the residual APIService resources will cause the Kubernetes Metrics Server add-on to fail to be installed.

      kubectl delete APIService v1beta1.metrics.k8s.io

  2. Add collection rules for custom metrics.

    1. Modify the user-adapter-config configuration item.
      kubectl edit configmap user-adapter-config -n monitoring
    2. Add collection rules to the rules field.
      In the following example rules, the rules in red are new ones and those in black are existing ones:
      ...
      data:
        config.yaml: >
          rules:
          - seriesQuery: '{__name__=~"node_cpu_seconds_total"}'
            resources:
              overrides:
                instance:
                  resource: node
            name:
              matches: node_cpu_seconds_total
              as: node_cpu_usage_avg
            metricsQuery: avg_over_time((1 - avg (irate(<<.Series>>{mode="idle"}[5m])) by (instance))[10m:30s])
          - seriesQuery: '{__name__=~"node_memory_MemTotal_bytes"}'
            resources:
              overrides:
                instance:
                  resource: node
            name:
              matches: node_memory_MemTotal_bytes
              as: node_memory_usage_avg
            metricsQuery: avg_over_time(((1-node_memory_MemAvailable_bytes/<<.Series>>))[10m:30s])
          resourceRules:
            cpu:
              containerQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>,container!="",pod!=""}[1m])) by (<<.GroupBy>>)
              nodeQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>, id='/'}[1m])) by (<<.GroupBy>>)
              resources:
                overrides:
                  instance:
                    resource: node
                  namespace:
                    resource: namespace
                  pod:
                    resource: pod
              containerLabel: container
            memory:
              containerQuery: sum(container_memory_working_set_bytes{<<.LabelMatchers>>,container!="",pod!=""}) by (<<.GroupBy>>)
              nodeQuery: sum(container_memory_working_set_bytes{<<.LabelMatchers>>,id='/'}) by (<<.GroupBy>>)
              resources:
                overrides:
                  instance:
                    resource: node
                  namespace:
                    resource: namespace
                  pod:
                    resource: pod
              containerLabel: container
            window: 1m
      ...
      • Rules for collecting the average CPU usage
        • node_cpu_usage_avg: average CPU usage of nodes. The name of this metric cannot be changed.
        • metricsQuery: avg_over_time((1 - avg (irate(<<.Series>>{mode="idle"}[5m])) by (instance))[10m:30s]): statement for obtaining nodes' average CPU usage.

          metricsQuery indicates to obtain the average CPU usage of all nodes in the target cluster in the last 10 minutes. To change the period, for example, to the last 5 or 30 minutes, change 10m in red to 5m or 30m.

      • Rules for collecting the average memory usage
        • node_memory_usage_avg: average memory usage of nodes. The name of this metric cannot be changed.
        • metricsQuery: avg_over_time(((1-node_memory_MemAvailable_bytes/<<.Series>>))[10m:30s]): statement for obtaining nodes' average memory usage.

          metricsQuery indicates to obtain the average memory usage of all nodes in the target cluster in the last 10 minutes. To change the period, for example, to the last 5 or 30 minutes, change 10m in red to 5m or 30m.

    3. Redeploy the custom-metrics-apiserver workload in the monitoring namespace.
      kubectl rollout restart deployment custom-metrics-apiserver -n monitoring
    4. Verify that the custom rules are configured successfully.
      1. Run the following command. If the custom metric information is returned, the metric collection configuration on Prometheus is successful.
        kubectl get --raw=/apis/custom.metrics.k8s.io/v1beta1

      2. Query information about nodes in the cluster.
        kubectl get nodes 

        Run the following command on any node. Replace xxxx with the obtained value of node_name. If you want to query the resource information of all nodes, replace xxxx with an asterisk (*).

        kubectl get --raw=/apis/custom.metrics.k8s.io/v1beta1/nodes/xxxx/node_cpu_usage_avg

        Information similar to the following is displayed.

  3. Enable load-aware scheduling.

    After Volcano is installed, you can enable or disable load-aware scheduling on the Scheduling page by choose Settings in the navigation pane. This function is disabled by default.
    1. Log in to the CCE console.
    2. Click the cluster name to access the cluster console. Choose Settings in the navigation pane. In the right pane, click the Scheduling tab.
    3. In the Resource utilization optimization scheduling area, modify the load-aware scheduling settings.
      NOTE:

      For optimal load-aware scheduling, disable bin packing because this policy preferentially schedules pods to the node with the maximal resources allocated based on pods' requested resources. This affects load-aware scheduling to some extent. For details about the combination of multiple policies, see Configuration Cases for Resource Usage-based Scheduling.

      Parameter

      Description

      Default Value

      Load-Aware Scheduling Policy Weight

      A larger value indicates a higher weight of the load-aware policy in overall scheduling.

      5

      CPU Weight

      A larger value indicates CPU resources will be preferentially balanced.

      1

      Memory Weight

      A larger value indicates memory resources will be preferentially balanced.

      1

      Actual load threshold effective mode

      • Soft constraint: When the actual CPU or memory load of a node reaches the threshold, new tasks will be preferentially allocated to underutilized nodes, but this node can still be scheduled.
      • Hard constraint: When the actual CPU or memory load of a node reaches the threshold, no new tasks can be scheduled to this node.

      Hard constraint

      Actual CPU Load Threshold

      When a node's CPU usage goes beyond this threshold, workloads will be scheduled based on how the load threshold takes effect. New workloads will be preferentially or forcibly scheduled to other nodes. Existing workloads on the nodes are not affected.

      80

      Actual Memory Load Threshold

      When a node's memory usage goes beyond this threshold, workloads will be scheduled based on how the load threshold takes effect. New workloads will be preferentially or forcibly scheduled to other nodes. Existing workloads on the nodes are not affected.

      80

  1. Install prometheus-adapter in the cluster.

    1. Run the following commands to install prometheus-adapter:
      git clone https://github.com/kubernetes-sigs/prometheus-adapter.git
      cd prometheus-adapter/deploy/manifests
      kubectl apply -f .
    2. Modify the configuration for prometheus-adapter to connect to prometheus-server.
      kubectl edit deployment prometheus-adapter -n monitoring

      Change the value of prometheus-url as follows:

      • Change HTTPS to HTTP.
      • Change the default domain name to the IP address and port of Prometheus Service. You can run the kubectl get service -n monitoring command to query the IP address and port.
      ...
            containers:
              - name: prometheus-adapter
                image: registry.k8s.io/prometheus-adapter/prometheus-adapter:v0.12.0
                args:
                  - --cert-dir=/var/run/serving-cert
                  - --config=/etc/adapter/config.yaml
                  - --prometheus-url=http://10.21.72.124:9090/
                  - --secure-port=6443
                  - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
      ...
    3. Verify that the native node_cpu_seconds_total and node_memory_MemAvailable_bytes metrics can be obtained on Prometheus.

  2. Enable Custom Metrics API to provide container resource metrics.

    Check whether Custom Metrics API has been enabled for the cluster. If it is enabled, you can skip this step.

    kubectl get APIServices | grep v1beta1.custom.metrics.k8s.io

    If any command output is displayed, Custom Metrics API has been enabled. If no command output is displayed, perform the following operations to register the APIService object. (Note that the Service name and namespace must be consistent with those in the actual installation environment.) The following uses the default values of kube-prometheus.

    1. Create a file named custom-metrics-apiservice.yaml. Example file content:
      apiVersion: apiregistration.k8s.io/v1
      kind: APIService
      metadata:
        labels:
          app.kubernetes.io/component: metrics
          app.kubernetes.io/name: prometheus-adapter
          app.kubernetes.io/part-of: prometheus-adapter
        name: v1beta1.custom.metrics.k8s.io
      spec:
        group: custom.metrics.k8s.io
        groupPriorityMinimum: 100
        insecureSkipTLSVerify: true
        service:
          name: prometheus-adapter
          namespace: monitoring
          port: 443
        version: v1beta1
        versionPriority: 100
    2. Create an APIService object.
      kubectl create -f custom-metrics-apiservice.yaml
    3. Check whether Custom Metrics API is enabled for the cluster.
      kubectl get APIServices | grep v1beta1.custom.metrics.k8s.io

  3. Add collection rules for custom metrics.

    1. Modify the adapter-config configuration item.
      kubectl edit configmap adapter-config -n monitoring
    2. Add collection rules to the rules field.
      Example collection rules:
      ...
      data:
        config.yaml: >
          rules:
          - seriesQuery: '{__name__=~"node_cpu_seconds_total"}'
            resources:
              overrides:
                instance:
                  resource: node
            name:
              matches: node_cpu_seconds_total
              as: node_cpu_usage_avg
            metricsQuery: avg_over_time((1 - avg (irate(<<.Series>>{mode="idle"}[5m])) by (instance))[10m:30s])
          - seriesQuery: '{__name__=~"node_memory_MemTotal_bytes"}'
            resources:
              overrides:
                instance:
                  resource: node
            name:
              matches: node_memory_MemTotal_bytes
              as: node_memory_usage_avg
            metricsQuery: avg_over_time(((1-node_memory_MemAvailable_bytes/<<.Series>>))[10m:30s])
      ...
    3. Redeploy the prometheus-adapter workload in the monitoring namespace.
      kubectl rollout restart deployment prometheus-adapter -n monitoring
    4. Verify that the custom rules are configured successfully.
      1. Run the following command. If the custom metric information is returned, the metric collection configuration on Prometheus is successful.
        kubectl get --raw=/apis/custom.metrics.k8s.io/v1beta1

      2. Query information about nodes in the cluster.
        kubectl get nodes 

        Run the following command on any node. Replace xxxx with the obtained value of node_name. If you want to query the resource information of all nodes, replace xxxx with an asterisk (*).

        kubectl get --raw=/apis/custom.metrics.k8s.io/v1beta1/nodes/xxxx/node_cpu_usage_avg

        Information similar to the following is displayed.

  4. Enable load-aware scheduling.

    1. Log in to the CCE console.
    2. Click the cluster name to access the cluster console. Choose Settings in the navigation pane. In the right pane, click the Scheduling tab.
    3. In Expert mode, click Try Now.

    4. Modify the parameter settings in expert mode and configure the load-aware scheduling policy. The parameters in red are added to enable load-aware scheduling. The details are as follows:
      admission_kube_api_qps: 200
      admissions: /jobs/mutate,/jobs/validate,/podgroups/mutate,/pods/validate,/pods/mutate,/queues/mutate,/queues/validate,/eas/pods/mutate,/eas/pods/validate,/npu/jobs/validate,/resource/validate,/resource/mutate,/workloadbalancer/balancer/validate,/workloadbalancer/balancerpolicytemplate/validate
      annotations: {}
      colocation_enable: "true"
      controller_kube_api_qps: 200
      default_scheduler_conf:
        actions: allocate, backfill, preempt
        metrics:
          interval: 30s
          type: prometheus_adaptor
        tiers:
          - plugins:
              - name: priority
              - enableJobStarving: false
                enablePreemptable: false
                name: gang
              - name: conformance
              - name: oversubscription
          - plugins:
              - enablePreemptable: false
                name: drf
              - name: predicates
              - name: nodeorder
              - arguments:
                   cpu.weight: 1
                   memory.weight: 1
                   thresholds:
                      cpu: 80
                      mem: 80
                  usage.weight: 5
                enablePredicate: true
                name: usage
          - plugins:
              - name: cce-gpu-topology-predicate
              - name: cce-gpu-topology-priority
              - name: xgpu
          - plugins:
              - name: nodelocalvolume
              - name: nodeemptydirvolume
              - name: nodeCSIscheduling
              - name: networkresource
      deschedulerPolicy:
        profiles:
          - name: ProfileName
            pluginConfig:
              - args:
                  nodeFit: true
                name: DefaultEvictor
              - args:
                  evictableNamespaces:
                    exclude:
                      - kube-system
                  thresholds:
                    cpu: 20
                    memory: 20
                name: HighNodeUtilization
              - args:
                  evictableNamespaces:
                    exclude:
                      - kube-system
                  metrics:
                    type: prometheus_adaptor
                  nodeFit: true
                  targetThresholds:
                    cpu: 80
                    memory: 85
                  thresholds:
                    cpu: 30
                    memory: 30
                name: LoadAware
            plugins:
              balance:
                enabled: null
      descheduler_enable: "false"
      deschedulingInterval: 10m
      enable_workload_balancer: false
      oversubscription_method: nodeResource
      oversubscription_profile_period: 300
      oversubscription_ratio: 60
      recommendation_enable: ""
      scheduler_kube_api_qps: 200
      update_pod_status_qps: 50
      workload_balancer_score_annotation_key: ""
      workload_balancer_third_party_types: ""

      The key parameters for cluster load-aware scheduling are as follows:

      • usage.weight: indicates the weight of the load-aware scheduling policy. A larger value indicates a higher weight of the load-aware policy in overall scheduling.
      • cpu.weight: indicates the CPU weight. A larger value indicates CPU resources will be preferentially balanced.
      • memory.weight: indicates the memory weight. A larger value indicates memory resources will be preferentially balanced.
      • thresholds:
        • cpu: indicates the actual CPU load threshold.
        • mem: indicates the actual memory load threshold.
      • enablePredicate: indicates the actual effective mode of the load threshold.
        • If the value is true, hard constraints are enabled. When the actual CPU or memory load of a node reaches the threshold, no new tasks can be scheduled to this node.
        • If the value is false, soft constraints are enabled. When the actual CPU or memory load of a node reaches the threshold, new tasks will be preferentially allocated to underutilized nodes, but this node can still be scheduled.

  1. After installing the Cloud Native Cluster Monitoring add-on, you need to enable Metrics API to provide container resource metrics such as CPU usage and memory usage.

    NOTE:

    Resource metrics can be provided by Metrics API only when local data storage is enabled for the Cloud Native Cluster Monitoring add-on.

    Check whether Metrics API has been enabled for the cluster. If it is enabled, you can skip this step.

    kubectl get APIServices | grep v1beta1.metrics.k8s.io

    If any command output is displayed, Metrics API is enabled. Skip this step and go to the next step to add metric collection rules.

    If no Metrics API is found, you can manually create an APIService object to enable it.

    1. Create a file named metrics-apiservice.yaml. Example file content:
      apiVersion: apiregistration.k8s.io/v1
      kind: APIService
      metadata:
        labels:
          app: custom-metrics-apiserver
          release: cceaddon-prometheus
        name: v1beta1.metrics.k8s.io
      spec:
        group: metrics.k8s.io
        groupPriorityMinimum: 100
        insecureSkipTLSVerify: true
        service:
          name: custom-metrics-apiserver
          namespace: monitoring
          port: 443
        version: v1beta1
        versionPriority: 100
    2. Create an APIService object.
      kubectl create -f metrics-apiservice.yaml
    3. Check whether Metrics API is enabled for the cluster.
      kubectl get APIServices | grep v1beta1.metrics.k8s.io
      NOTE:

      After Metrics API is enabled, if you need to uninstall the Cloud Native Cluster Monitoring add-on, run the following kubectl and delete the APIService object. Otherwise, the residual APIService resources will cause the Kubernetes Metrics Server add-on to fail to be installed.

      kubectl delete APIService v1beta1.metrics.k8s.io

  2. Add collection rules for custom metrics.

    1. Modify the user-adapter-config configuration item.
      kubectl edit configmap user-adapter-config -n monitoring
    2. Add collection rules to the rules field.
      In the following example rules, the rules in red are new ones and those in black are existing ones:
      ...
      data:
        config.yaml: >
          rules:
          - seriesQuery: '{__name__=~"node_cpu_seconds_total"}'
            resources:
              overrides:
                instance:
                  resource: node
            name:
              matches: node_cpu_seconds_total
              as: node_cpu_usage_avg
            metricsQuery: avg_over_time((1 - avg (irate(<<.Series>>{mode="idle"}[5m])) by (instance))[10m:30s])
          - seriesQuery: '{__name__=~"node_memory_MemTotal_bytes"}'
            resources:
              overrides:
                instance:
                  resource: node
            name:
              matches: node_memory_MemTotal_bytes
              as: node_memory_usage_avg
            metricsQuery: avg_over_time(((1-node_memory_MemAvailable_bytes/<<.Series>>))[10m:30s])
          resourceRules:
            cpu:
              containerQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>,container!="",pod!=""}[1m])) by (<<.GroupBy>>)
              nodeQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>, id='/'}[1m])) by (<<.GroupBy>>)
              resources:
                overrides:
                  instance:
                    resource: node
                  namespace:
                    resource: namespace
                  pod:
                    resource: pod
              containerLabel: container
            memory:
              containerQuery: sum(container_memory_working_set_bytes{<<.LabelMatchers>>,container!="",pod!=""}) by (<<.GroupBy>>)
              nodeQuery: sum(container_memory_working_set_bytes{<<.LabelMatchers>>,id='/'}) by (<<.GroupBy>>)
              resources:
                overrides:
                  instance:
                    resource: node
                  namespace:
                    resource: namespace
                  pod:
                    resource: pod
              containerLabel: container
            window: 1m
      ...
      • Rules for collecting the average CPU usage
        • node_cpu_usage_avg: average CPU usage of nodes. The name of this metric cannot be changed.
        • metricsQuery: avg_over_time((1 - avg (irate(<<.Series>>{mode="idle"}[5m])) by (instance))[10m:30s]): statement for obtaining nodes' average CPU usage.

          metricsQuery indicates to obtain the average CPU usage of all nodes in the target cluster in the last 10 minutes. To change the period, for example, to the last 5 or 30 minutes, change 10m in red to 5m or 30m.

      • Rules for collecting the average memory usage
        • node_memory_usage_avg: average memory usage of nodes. The name of this metric cannot be changed.
        • metricsQuery: avg_over_time(((1-node_memory_MemAvailable_bytes/<<.Series>>))[10m:30s]): statement for obtaining nodes' average memory usage.

          metricsQuery indicates to obtain the average memory usage of all nodes in the target cluster in the last 10 minutes. To change the period, for example, to the last 5 or 30 minutes, change 10m in red to 5m or 30m.

    3. Redeploy the custom-metrics-apiserver workload in the monitoring namespace.
      kubectl rollout restart deployment custom-metrics-apiserver -n monitoring
    4. Verify that the custom rules are configured successfully.
      1. Run the following command. If the custom metric information is returned, the metric collection configuration on Prometheus is successful.
        kubectl get --raw=/apis/custom.metrics.k8s.io/v1beta1

      2. Query information about nodes in the cluster.
        kubectl get nodes 

        Run the following command on any node. Replace xxxx with the obtained value of node_name. If you want to query the resource information of all nodes, replace xxxx with an asterisk (*).

        kubectl get --raw=/apis/custom.metrics.k8s.io/v1beta1/nodes/xxxx/node_cpu_usage_avg

        Information similar to the following is displayed.

  3. Enable load-aware scheduling.

    After Volcano is installed, you can enable or disable load-aware scheduling on the Scheduling page by choose Settings in the navigation pane. This function is disabled by default.
    1. Log in to the CCE console.
    2. Click the cluster name to access the cluster console. Choose Settings in the navigation pane. In the right pane, click the Scheduling tab.
    3. In the Resource utilization optimization scheduling area, modify the load-aware scheduling settings.
      NOTE:

      For optimal load-aware scheduling, disable bin packing because this policy preferentially schedules pods to the node with the maximal resources allocated based on pods' requested resources. This affects load-aware scheduling to some extent. For details about the combination of multiple policies, see Configuration Cases for Resource Usage-based Scheduling.

      Parameter

      Description

      Default Value

      Load-Aware Scheduling Policy Weight

      A larger value indicates a higher weight of the load-aware policy in overall scheduling.

      5

      CPU Weight

      A larger value indicates CPU resources will be preferentially balanced.

      1

      Memory Weight

      A larger value indicates memory resources will be preferentially balanced.

      1

      Actual load threshold effective mode

      • Soft constraint: When the actual CPU or memory load of a node reaches the threshold, new tasks will be preferentially allocated to underutilized nodes, but this node can still be scheduled.
      • Hard constraint: When the actual CPU or memory load of a node reaches the threshold, no new tasks can be scheduled to this node.

      Hard constraint

      Actual CPU Load Threshold

      When a node's CPU usage goes beyond this threshold, workloads will be scheduled based on how the load threshold takes effect. New workloads will be preferentially or forcibly scheduled to other nodes. Existing workloads on the nodes are not affected.

      80

      Actual Memory Load Threshold

      When a node's memory usage goes beyond this threshold, workloads will be scheduled based on how the load threshold takes effect. New workloads will be preferentially or forcibly scheduled to other nodes. Existing workloads on the nodes are not affected.

      80

  1. Install prometheus-adapter in the cluster.

    1. Run the following commands to install prometheus-adapter:
      git clone https://github.com/kubernetes-sigs/prometheus-adapter.git
      cd prometheus-adapter/deploy/manifests
      kubectl apply -f .
    2. Modify the configuration for prometheus-adapter to connect to prometheus-server.
      kubectl edit deployment prometheus-adapter -n monitoring

      Change the value of prometheus-url as follows:

      • Change HTTPS to HTTP.
      • Change the default domain name to the IP address and port of Prometheus Service. You can run the kubectl get service -n monitoring command to query the IP address and port.
      ...
            containers:
              - name: prometheus-adapter
                image: registry.k8s.io/prometheus-adapter/prometheus-adapter:v0.12.0
                args:
                  - --cert-dir=/var/run/serving-cert
                  - --config=/etc/adapter/config.yaml
                  - --prometheus-url=http://10.21.72.124:9090/
                  - --secure-port=6443
                  - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
      ...
    3. Verify that the native node_cpu_seconds_total and node_memory_MemAvailable_bytes metrics can be obtained on Prometheus.

  2. Enable Custom Metrics API to provide container resource metrics.

    Check whether Custom Metrics API has been enabled for the cluster. If it is enabled, you can skip this step.

    kubectl get APIServices | grep v1beta1.custom.metrics.k8s.io

    If any command output is displayed, Custom Metrics API has been enabled. If no command output is displayed, perform the following operations to register the APIService object. (Note that the Service name and namespace must be consistent with those in the actual installation environment.) The following uses the default values of kube-prometheus.

    1. Create a file named custom-metrics-apiservice.yaml. Example file content:
      apiVersion: apiregistration.k8s.io/v1
      kind: APIService
      metadata:
        labels:
          app.kubernetes.io/component: metrics
          app.kubernetes.io/name: prometheus-adapter
          app.kubernetes.io/part-of: prometheus-adapter
        name: v1beta1.custom.metrics.k8s.io
      spec:
        group: custom.metrics.k8s.io
        groupPriorityMinimum: 100
        insecureSkipTLSVerify: true
        service:
          name: prometheus-adapter
          namespace: monitoring
          port: 443
        version: v1beta1
        versionPriority: 100
    2. Create an APIService object.
      kubectl create -f custom-metrics-apiservice.yaml
    3. Check whether Custom Metrics API is enabled for the cluster.
      kubectl get APIServices | grep v1beta1.custom.metrics.k8s.io

  3. Add collection rules for custom metrics.

    1. Modify the adapter-config configuration item.
      kubectl edit configmap adapter-config -n monitoring
    2. Add collection rules to the rules field.
      Example collection rules:
      ...
      data:
        config.yaml: >
          rules:
          - seriesQuery: '{__name__=~"node_cpu_seconds_total"}'
            resources:
              overrides:
                instance:
                  resource: node
            name:
              matches: node_cpu_seconds_total
              as: node_cpu_usage_avg
            metricsQuery: avg_over_time((1 - avg (irate(<<.Series>>{mode="idle"}[5m])) by (instance))[10m:30s])
          - seriesQuery: '{__name__=~"node_memory_MemTotal_bytes"}'
            resources:
              overrides:
                instance:
                  resource: node
            name:
              matches: node_memory_MemTotal_bytes
              as: node_memory_usage_avg
            metricsQuery: avg_over_time(((1-node_memory_MemAvailable_bytes/<<.Series>>))[10m:30s])
      ...
    3. Redeploy the prometheus-adapter workload in the monitoring namespace.
      kubectl rollout restart deployment prometheus-adapter -n monitoring
    4. Verify that the custom rules are configured successfully.
      1. Run the following command. If the custom metric information is returned, the metric collection configuration on Prometheus is successful.
        kubectl get --raw=/apis/custom.metrics.k8s.io/v1beta1

      2. Query information about nodes in the cluster.
        kubectl get nodes 

        Run the following command on any node. Replace xxxx with the obtained value of node_name. If you want to query the resource information of all nodes, replace xxxx with an asterisk (*).

        kubectl get --raw=/apis/custom.metrics.k8s.io/v1beta1/nodes/xxxx/node_cpu_usage_avg

        Information similar to the following is displayed.

  4. Enable load-aware scheduling.

    1. Log in to the CCE console.
    2. Click the cluster name to access the cluster console. Choose Settings in the navigation pane. In the right pane, click the Scheduling tab.
    3. In Expert mode, click Try Now.

    4. Modify the parameter settings in expert mode and configure the load-aware scheduling policy. The parameters in red are added to enable load-aware scheduling. The details are as follows:
      admission_kube_api_qps: 200
      admissions: /jobs/mutate,/jobs/validate,/podgroups/mutate,/pods/validate,/pods/mutate,/queues/mutate,/queues/validate,/eas/pods/mutate,/eas/pods/validate,/npu/jobs/validate,/resource/validate,/resource/mutate,/workloadbalancer/balancer/validate,/workloadbalancer/balancerpolicytemplate/validate
      annotations: {}
      colocation_enable: "true"
      controller_kube_api_qps: 200
      default_scheduler_conf:
        actions: allocate, backfill, preempt
        metrics:
          interval: 30s
          type: prometheus_adaptor
        tiers:
          - plugins:
              - name: priority
              - enableJobStarving: false
                enablePreemptable: false
                name: gang
              - name: conformance
              - name: oversubscription
          - plugins:
              - enablePreemptable: false
                name: drf
              - name: predicates
              - name: nodeorder
              - arguments:
                   cpu.weight: 1
                   memory.weight: 1
                   thresholds:
                      cpu: 80
                      mem: 80
                  usage.weight: 5
                enablePredicate: true
                name: usage
          - plugins:
              - name: cce-gpu-topology-predicate
              - name: cce-gpu-topology-priority
              - name: xgpu
          - plugins:
              - name: nodelocalvolume
              - name: nodeemptydirvolume
              - name: nodeCSIscheduling
              - name: networkresource
      deschedulerPolicy:
        profiles:
          - name: ProfileName
            pluginConfig:
              - args:
                  nodeFit: true
                name: DefaultEvictor
              - args:
                  evictableNamespaces:
                    exclude:
                      - kube-system
                  thresholds:
                    cpu: 20
                    memory: 20
                name: HighNodeUtilization
              - args:
                  evictableNamespaces:
                    exclude:
                      - kube-system
                  metrics:
                    type: prometheus_adaptor
                  nodeFit: true
                  targetThresholds:
                    cpu: 80
                    memory: 85
                  thresholds:
                    cpu: 30
                    memory: 30
                name: LoadAware
            plugins:
              balance:
                enabled: null
      descheduler_enable: "false"
      deschedulingInterval: 10m
      enable_workload_balancer: false
      oversubscription_method: nodeResource
      oversubscription_profile_period: 300
      oversubscription_ratio: 60
      recommendation_enable: ""
      scheduler_kube_api_qps: 200
      update_pod_status_qps: 50
      workload_balancer_score_annotation_key: ""
      workload_balancer_third_party_types: ""

      The key parameters for cluster load-aware scheduling are as follows:

      • usage.weight: indicates the weight of the load-aware scheduling policy. A larger value indicates a higher weight of the load-aware policy in overall scheduling.
      • cpu.weight: indicates the CPU weight. A larger value indicates CPU resources will be preferentially balanced.
      • memory.weight: indicates the memory weight. A larger value indicates memory resources will be preferentially balanced.
      • thresholds:
        • cpu: indicates the actual CPU load threshold.
        • mem: indicates the actual memory load threshold.
      • enablePredicate: indicates the actual effective mode of the load threshold.
        • If the value is true, hard constraints are enabled. When the actual CPU or memory load of a node reaches the threshold, no new tasks can be scheduled to this node.
        • If the value is false, soft constraints are enabled. When the actual CPU or memory load of a node reaches the threshold, new tasks will be preferentially allocated to underutilized nodes, but this node can still be scheduled.

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback