A method for multi-tenant task scheduling based on Kubernetes using XXL-JOB

Abstract

The present invention discloses a method for realizing multi-tenant task scheduling based on Kubernetes using XXL-JOB, relating to the field of task scheduling technology, including: building and configuring a Kubernetes cluster; labeling task nodes in the Kubernetes cluster and deploying application modules, XXL-JOB scheduling centers and executors that a data governance platform relies on, while integrating Liquibase tools to automatically create database table structures to support executor registration; through a management center, resource monitoring and allocation are realized, executor instances are created and managed using XXL-JOB, and executor information is written into a scheduling resource configuration table; computing tasks are created and resources are selected through a front-end interface, computing tasks are bound to selected resources and a scheduling strategy is generated, and finally scheduling strategy information is registered to a scheduling center to manage and execute computing tasks. The present invention can effectively prevent and reduce the tilt problem of node resource usage in a Kubernetes platform, realize multi-node load balancing, and improve the utilization rate of node resources.

Description

Technical Field

[0001] The present invention relates to the technical field of task scheduling, and in particular to a method for implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes. Background Art

[0002] In the digital economy era, the rise of big data platforms and the Industrial Internet is continuously unlocking the value of data. Governments and businesses are accelerating their digital transformation efforts by building data lake platforms to unify data governance, integrated development, services, and visualization. This facilitates the implementation of big data and data middleware strategies, enabling data-driven business intelligence and driving digital transformation and business model innovation for both governments and businesses. Effective management and efficient concurrent execution of tasks such as metadata collection, quality inspection, aggregation, data aggregation, data labeling, data security desensitization, and data identification are key to data governance. However, traditional task scheduling suffers from insufficient resource isolation and complex management in multi-tenant data governance environments.

[0003] To address these issues, Kubernetes, a powerful container orchestration platform, provides efficient and flexible solutions for resource management, deployment, and scaling. XXL-JOB, a lightweight distributed task scheduling platform, has been widely used in the task scheduling field for its ease of use, high performance, and scalability.

[0004] Based on this, by combining the advantages of Kubernetes and XXL-JOB, we can better solve the problems of insufficient resource isolation and complex management in traditional task scheduling in a data governance multi-tenant environment, thereby improving the efficiency and reliability of task scheduling. At the same time, by leveraging the development of big data platforms and the industrial Internet, we can further explore the value of data and promote the digital transformation and upgrading of governments and enterprises, as well as business model innovation. Summary of the Invention

[0005] In response to the needs and shortcomings of current technological development, the present invention provides a method for implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes, which solves many problems of traditional task scheduling in data governance multi-tenant environments, such as unreasonable resource allocation and insufficient resource isolation, insufficient task isolation and scheduling failure, and complex management.

[0006] The present invention provides a method for implementing multi-tenant task scheduling based on Kubernetes using XXL-JOB, and the technical solution adopted to solve the above technical problems is as follows:

[0007] A method for implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes includes the following steps:

[0008] S1. Build and configure a highly available and elastically scalable Kubernetes cluster to provide basic support for XXL-JOB deployment and task scheduling. Label the nodes that execute tasks in the Kubernetes cluster and deploy application modules, the XXL-JOB scheduling center, and executors that the data governance platform relies on. In addition, integrate the Liquibase tool to automatically create the database table structure to support executor registration.

[0009] S2. Implement resource monitoring and allocation through the Kubernetes cluster management center, use XXL-JOB to create and manage executor instances, and write executor information into the scheduling resource configuration table;

[0010] S3. Create computing tasks and select resources through the front-end interface of the Kubernetes cluster management center, bind the computing tasks to the selected resources and generate a scheduling policy. Finally, register the scheduling policy information with the scheduling center to manage and execute computing tasks.

[0011] Optionally, step S1 specifically includes the following operations:

[0012] S110. Build and configure the Kubernetes cluster to ensure high availability and elastic scalability. Then, configure the network and storage resources of the Kubernetes cluster according to actual needs to provide basic support for XXL-JOB deployment and task scheduling on the Kubernetes cluster.

[0013] S120. In the Kubernetes cluster, label the nodes used to execute tasks with the datalake-scheduler label. When creating task executors for different tenants, deploy the created executors to the nodes with the datalake-scheduler label.

[0014] S130. Deploy the application modules, XXL-JOB scheduling center, and executors that the data governance platform relies on in the Kubernetes cluster.

[0015] When deploying the XXL-JOB scheduling center, an XXL-JOB scheduling center instance is automatically created. The XXL-JOB scheduling center instance is deployed as an independent Pod, and adopts the deployment type and multi-replica mode. The name of each Pod is prefixed with "idlf-scheduler";

[0016] When deploying an executor, it is deployed as an independent Pod, using the deployment type and multiple replicas. The Pod name of each executor is prefixed with "idlf-executor-depl";

[0017] When the executor is registered with the XXL-JOB dispatch center, the executor is registered using its corresponding APPNAME;

[0018] During the deployment of the XXL-JOB scheduling center, the Liquibase tool is integrated to automatically create the database table structure. At the same time, the default APPNAME of the application module that the data governance platform depends on is inserted into the database table for automatic registration by the executor.

[0019] Further optionally, step S2 specifically includes the following operations:

[0020] S210. The platform administrator creates a workspace in the tenant management module of the Kubernetes cluster management center and assigns an administrator to the workspace.

[0021] S220: Add task scheduling resources, specifically including:

[0022] S221. The administrator or user initiates the creation of a task executor through the front-end interface of the Kubernetes cluster management center. The Kubernetes cluster management center calls the Prometheus interface to obtain the CPU and memory usage of nodes with the datalake-scheduler label and calculates the CPU and memory usage of each node within a day.

[0023] S222. The Kubernetes cluster management center calculates the remaining CPU and memory resources of each node based on the CPU usage and memory usage of each node, and displays them on the front-end interface for user reference;

[0024] S223. The user views the remaining CPU and memory resources of each node on the front-end interface and configures resources for various task executor instances in the executor according to actual needs;

[0025] S224. After the user completes filling in the resource configuration, the filled information is returned to the management center backend; the backend first performs resource verification based on the filled information and the remaining resources of the node. After the verification passes, an APPNAME and a separate namespace are created for the executor. Then, based on the filled information and creation information, the ConfigMap and deployment of the executor to be created are rendered, and the k8s interface is called to create the Pod application of the executor;

[0026] S225. Write the executor information into the scheduling resource configuration table for use by the application module deployed under the Kubernetes cluster to create tasks.

[0027] Preferably, step S223 is executed to configure resources for various task executor instances in the executor according to actual needs. The configured resources include specifying the CPU specifications and memory specifications of each executor, specifying the number of copies of each executor, and specifying the workspace, wherein the workspace corresponds to at least one task executor instance, at least one task executor instance exclusively enjoys the resources within its workspace, or at least two task executor instances share the resources within their workspace.

[0028] Further preferably, step S224 is executed, and the Kubernetes cluster management center backend first performs resource verification based on the filled-in specification information and the remaining resources of the node:

[0029] If the verification fails, a prompt message will be returned to the front-end interface.

[0030] If the verification passes, the XXL-JOB interface is called through the management center to create an APPNAME for the executor. The K8S interface is called through the management center to create a separate namespace for the executor, and the namespace name is in the format of ns-idlf-scheduler-yyyyMMdd+6-digit serial number.

[0031] Then, based on the filled-in specification information, number of replicas, created APPNAME and namespace, use freemarker.template.Template to render the ConfigMap and deployment of the executor to be created according to the template, and call the k8s interface through the Kubernetes API or the kubectl command-line tool to create the Pod application of the executor.

[0032] Further preferably, step S224 is executed, and the background performs resource verification based on the filled-in specification information and the remaining resources of the node to verify whether the resource allocation meets the following resource verification rules:

[0033] a) The remaining CPU resources of a single node are greater than the total CPU resources required by a single replica of the executor multiplied by the number of replicas, and the remaining memory resources of a single node are greater than the total memory resources required by a single replica of the executor multiplied by the number of replicas;

[0034] b) Node A's CPU resources are greater than the total CPU required by a single replica of the executor, and Node A's memory resources are greater than the total memory required by a single replica of the executor. Meanwhile, Node B's CPU resources are greater than the total CPU required by a single replica of the executor, and Node B's memory resources are greater than the total memory required by a single replica of the executor.

[0035] The resource allocation satisfies at least one resource verification rule in a) and b), that is, passes the resource verification.

[0036] Optionally, execute step S225, write the executor information into the scheduling resource configuration table, and start a scheduled task to regularly check the pod status of the executor:

[0037] If all containers in the Pod become Ready within the set time, the Pod is considered normal;

[0038] If the set time has passed and there are still containers in the Pod that are not Ready, the Pod status is considered abnormal.

[0039] Optionally, step S3 specifically includes the following operations:

[0040] S310. The user creates a computing task through the front-end interface of the Kubernetes cluster management center and selects the workspace ID and task type for the computing task.

[0041] S320: Query the scheduling resource configuration table based on the workspace ID and task type of the computing task to obtain a list of available task scheduling resources that match the workspace and task type. The list includes the CPU specification, memory specification, number of replicas, and namespace of each available task scheduling resource.

[0042] S330: The user selects the required resources from the available task scheduling resource list and binds the computing task to the selected resources. The selected resources constitute a virtual resource pool for the computing task for subsequent task execution.

[0043] S340: After the computing task is successfully bound to the selected resource, the corresponding scheduling policy information is automatically generated and registered in the designated task group of the scheduling center so that the scheduling center can manage and execute the scheduling task according to the scheduling policy.

[0044] The method of implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes in the present invention has the following beneficial effects compared with the prior art:

[0045] 1. This invention uses the Kubernetes cluster management center to allocate task executor resources to different tenants based on their tasks. It leverages Kubernetes' resource isolation, elastic scaling, and automated management features, combined with Prometheus to monitor the CPU and memory usage of each K8s task node, dynamically allocates task executor resources, and uses XXL-JOB's lightweight distributed task scheduling function to achieve effective management of task scheduling, efficient execution, and rational use of resources in a multi-tenant environment, as well as isolated execution of tasks under different tenants.

[0046] 2. The present invention enables users to perform task scheduling resource configuration and automatic deployment of task executors based on task usage, effectively preventing and reducing the problem of node resource usage imbalance in the Kubernetes platform, achieving multi-node load balancing, and improving node resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Attachment Figure 1 This is a flow chart of the method described in Example 1 of the present invention. DETAILED DESCRIPTION

[0048] In order to make the technical solution, the technical problems solved and the technical effects of the present invention more clear, the technical solution of the present invention is clearly and completely described below in conjunction with specific embodiments.

[0049] The English words involved in the embodiment are now explained:

[0050] Kubernetes is an open-source container orchestration platform for automating the deployment, scaling, and management of containerized applications. It provides an efficient way to manage microservice architectures, enabling applications to run efficiently in clusters by offering load balancing, automatic scaling, and fault tolerance. Kubernetes also offers powerful resource management and scheduling capabilities, automatically allocating computing resources based on application needs.

[0051] XXL-JOB is a lightweight distributed task scheduling platform designed to solve the problem of executing tasks on multiple machines. It supports scheduled execution, task dependencies, and task sharding, helping developers meet complex task scheduling requirements.

[0052] APPNAME refers to the name of the application module, which is pre-defined and used to identify the executor instance of each application module.

[0053] A Pod is the smallest deployable unit in Kubernetes. It contains one or more containers. Each container runs in the same environment and shares the same namespace.

[0054] Example 1:

[0055] Combined with attachment Figure 1 This embodiment proposes a method for implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes, which includes the following steps:

[0056] S1. Build and configure a highly available and elastically scalable Kubernetes cluster to provide basic support for XXL-JOB deployment and task scheduling. Label the nodes that execute tasks in the Kubernetes cluster and deploy application modules, the XXL-JOB scheduling center, and executors that the data governance platform relies on. In addition, integrate the Liquibase tool to automatically create the database table structure to support executor registration.

[0057] To implement step S1, you need to perform the following operations:

[0058] S110. Build and configure the Kubernetes cluster to ensure high availability and elastic scalability. Then, configure the network and storage resources of the Kubernetes cluster according to actual needs to provide basic support for XXL-JOB deployment and task scheduling on the Kubernetes cluster.

[0059] S120. In the Kubernetes cluster, label the nodes used to execute tasks with the datalake-scheduler label. When creating task executors for different tenants, deploy the created executors to the nodes with the datalake-scheduler label.

[0060] S130. Deploy the application modules, XXL-JOB scheduling center, and executors that the data governance platform relies on in the Kubernetes cluster.

[0061] When deploying the XXL-JOB scheduling center, an XXL-JOB scheduling center instance is automatically created. The XXL-JOB scheduling center instance is deployed as an independent Pod, and adopts the deployment type and multi-replica mode. The name of each Pod is prefixed with "idlf-scheduler";

[0062] When deploying an executor, it is deployed as an independent Pod, using the deployment type and multiple replicas. The Pod name of each executor is prefixed with "idlf-executor-depl".

[0063] When the executor is registered with the XXL-JOB dispatch center, the executor is registered using its corresponding APPNAME.

[0064] During the deployment of the XXL-JOB scheduling center, the Liquibase tool is integrated to automatically create the database table structure. At the same time, the default APPNAME of the application module that the data governance platform depends on is inserted into the database table for automatic registration by the executor.

[0065] S2. Implement resource monitoring and allocation through the Kubernetes cluster management center, use XXL-JOB to create and manage executor instances, and write executor information into the scheduling resource configuration table.

[0066] To implement step S2, you need to perform the following operations:

[0067] S210. The platform administrator creates a workspace in the tenant management module of the Kubernetes cluster management center and assigns an administrator to the workspace.

[0068] S220: Add task scheduling resources, specifically including:

[0069] S221. The administrator or user initiates the creation of a task executor through the front-end interface of the Kubernetes cluster management center. The Kubernetes cluster management center calls the Prometheus interface to obtain the CPU and memory usage of nodes with the datalake-scheduler label and calculates the CPU usage and memory usage of each node within one day.

[0070] It should be added here that what is usually calculated is the average CPU usage and average memory usage of each node within a day.

[0071] S222. The Kubernetes cluster management center calculates the remaining CPU and memory resources of each node based on the CPU usage and memory usage of each node, and displays them on the front-end interface for user reference.

[0072] S223. The user views the remaining CPU and memory resources of each node on the front-end interface, and configures resources for various task executor instances in the executor according to actual needs; the configured resources include specifying the CPU specifications and memory specifications of each executor, specifying the number of copies of each executor, and specifying the workspace, wherein the workspace corresponds to at least one task executor instance, at least one task executor instance exclusively enjoys the resources within its workspace, or at least two task executor instances share the resources within their workspace.

[0073] S224. After the user completes filling in the resource configuration, the filled information is returned to the Kubernetes cluster management center backend;

[0074] The backend first performs resource verification based on the filled-in specification information and the remaining resources of the node.

[0075] a) If the verification fails, a prompt message will be returned to the front-end interface.

[0076] b) If the verification passes, the XXL-JOB interface is called through the management center to create an APPNAME for the executor. The K8S interface is also called through the management center to create a separate namespace for the executor, using the format of ns-idlf-scheduler-yyyyMMdd+6-digit serial number as the namespace name;

[0077] Then, based on the filled-in specification information, number of replicas, created APPNAME and namespace, use freemarker.template.Template to render the ConfigMap and deployment of the executor to be created according to the template, and call the k8s interface through the Kubernetes API or the kubectl command-line tool to create the Pod application of the executor.

[0078] It should be noted that the backend performs resource verification based on the entered specification information and the remaining resources of the node to verify whether the resource allocation meets the following resource verification rules:

[0079] a) The remaining CPU resources of a single node are greater than the total CPU resources required by a single replica of the executor multiplied by the number of replicas, and the remaining memory resources of a single node are greater than the total memory resources required by a single replica of the executor multiplied by the number of replicas;

[0080] b) Node A's CPU resources are greater than the total CPU required by a single replica of the executor, and Node A's memory resources are greater than the total memory required by a single replica of the executor. Meanwhile, Node B's CPU resources are greater than the total CPU required by a single replica of the executor, and Node B's memory resources are greater than the total memory required by a single replica of the executor.

[0081] The resource allocation satisfies at least one resource verification rule in a) and b), that is, passes the resource verification.

[0082] S225. Write the executor information of step S224 into the scheduling resource configuration table for use in creating tasks for application modules deployed under the Kubernetes cluster.

[0083] After writing the executor information of step S224 into the scheduling resource configuration table, start a scheduled task to regularly check the pod status of the executor:

[0084] If all containers in the Pod become Ready within the set time of 20 minutes, the Pod is considered normal;

[0085] If there are still containers in the Pod that are not Ready after 20 minutes, the Pod status is considered abnormal, and the Pod status is then updated, and a message reminder is sent to the administrator or user.

[0086] S3. Create computing tasks and select resources through the front-end interface of the Kubernetes cluster management center, bind the computing tasks to the selected resources and generate a scheduling policy. Finally, register the scheduling policy information with the scheduling center to manage and execute computing tasks.

[0087] To implement step S3, you need to perform the following operations:

[0088] S310. The user creates a computing task through the front-end interface of the Kubernetes cluster management center and selects the workspace ID and task type for the computing task.

[0089] S320: Query the scheduling resource configuration table based on the workspace ID and task type of the computing task to obtain a list of available task scheduling resources that match the workspace and task type. The list includes the CPU specification, memory specification, number of replicas, and namespace of each available task scheduling resource.

[0090] S330: The user selects the required resources from the available task scheduling resource list and binds the computing task to the selected resources. The selected resources constitute a virtual resource pool for the computing task for subsequent task execution.

[0091] S340: After the computing task is successfully bound to the selected resource, the corresponding scheduling policy information is automatically generated and registered in the designated task group of the scheduling center so that the scheduling center can manage and execute the scheduling task according to the scheduling policy.

[0092] In summary, the method of implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes of the present invention realizes dynamic allocation of resources for task executors under different tenants according to the different requirements of different tenants for tasks, utilizes the resource isolation, elastic scaling and automated management characteristics of k8s, and calculates the remaining CPU and memory of each task node through Promethues resource monitoring for user reference. Combined with the lightweight distributed task scheduling function of XXL-JOB, it effectively realizes the reasonable allocation of resources, effective management, efficient and isolated execution of task scheduling in a multi-tenant environment.

[0093] The above specific examples are used to illustrate the principles and implementation methods of the present invention in detail. These examples are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made by those skilled in the art without departing from the principles of the present invention should fall within the scope of patent protection of the present invention.

Claims

1. A method for implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes, characterized in that: The steps include: S1. Build and configure a highly available and elastically scalable Kubernetes cluster to provide basic support for XXL-JOB deployment and task scheduling. Label the nodes that execute tasks in the Kubernetes cluster and deploy application modules, the XXL-JOB scheduling center, and executors that the data governance platform relies on. In addition, integrate the Liquibase tool to automatically create the database table structure to support executor registration. S2. Implement resource monitoring and allocation through the Kubernetes cluster management center, use XXL-JOB to create and manage executor instances, and write executor information to the scheduling resource configuration table. This process specifically includes the following operations: S210. The platform administrator creates a workspace in the tenant management module of the Kubernetes cluster management center and assigns an administrator to the workspace. S220: Add task scheduling resources, specifically including: S221. The administrator or user initiates the creation of a task executor through the front-end interface of the Kubernetes cluster management center. The Kubernetes cluster management center calls the Prometheus interface to obtain the CPU and memory usage of nodes with the datalake-scheduler label and calculates the CPU and memory usage of each node within a day. S222. The Kubernetes cluster management center calculates the remaining CPU and memory resources of each node based on the CPU usage and memory usage of each node, and displays them on the front-end interface for user reference; S223. The user views the remaining CPU and memory resources of each node on the front-end interface and configures resources for various task executor instances in the executor according to actual needs. The configured resources include specifying the CPU specifications and memory specifications of each executor, specifying the number of replicas of each executor, and specifying the workspace. The workspace corresponds to at least one task executor instance, and at least one task executor instance exclusively uses the resources in its workspace, or at least two task executor instances share the resources in their workspace. S224. After the user completes filling in the resource configuration, the filled information is returned to the management center backend; the backend first performs resource verification based on the filled information and the remaining resources of the node: If the verification fails, a prompt message will be returned to the front-end interface. If the verification passes, the XXL-JOB interface is called through the management center to create an APPNAME for the executor. The K8S interface is called through the management center to create a separate namespace for the executor, and the namespace name is in the format of ns-idlf-scheduler-yyyyMMdd+6-digit serial number. Then, based on the filled-in specification information, number of replicas, created APPNAME and namespace, use freemarker.template.Template to render the ConfigMap and deployment of the executor to be created according to the template. Use the Kubernetes API or the kubectl command-line tool to call the k8s interface to create the pod application of the executor. S225. Write the executor information into the scheduling resource configuration table for use in creating tasks for application modules deployed in the Kubernetes cluster. S3. Create computing tasks and select resources through the front-end interface of the Kubernetes cluster management center, bind the computing tasks to the selected resources and generate a scheduling policy. Finally, register the scheduling policy information with the scheduling center to manage and execute computing tasks.

2. The method for implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes according to claim 1, characterized in that: The step S1 specifically includes the following operations: S110. Build and configure the Kubernetes cluster to ensure high availability and elastic scalability. Then, configure the network and storage resources of the Kubernetes cluster according to actual needs to provide basic support for XXL-JOB deployment and task scheduling on the Kubernetes cluster. S120. In the Kubernetes cluster, label the nodes used to execute tasks with the datalake-scheduler label. When creating task executors for different tenants, deploy the created executors to the nodes with the datalake-scheduler label. S130. Deploy the application modules, XXL-JOB scheduling center, and executors that the data governance platform relies on in the Kubernetes cluster. When deploying XXL-JOB Scheduling Center, an XXL-JOB Scheduling Center instance is automatically created. The XXL-JOB Scheduling Center instance is deployed as an independent Pod, and adopts the deployment type and multi-replica mode. The name of each Pod is prefixed with "idlf-scheduler"; When deploying an executor, it is deployed as an independent Pod, using the deployment type and multiple replicas. The Pod name of each executor is prefixed with "idlf-executor-depl"; When the executor is registered with the XXL-JOB dispatch center, the executor is registered using its corresponding APPNAME; During the deployment of the XXL-JOB scheduling center, the Liquibase tool is integrated to automatically create the database table structure. At the same time, the default APPNAME of the application module that the data governance platform depends on is inserted into the database table for automatic registration by the executor.

3. The method for implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes according to claim 1, characterized in that: Execute step S224. The backend performs resource verification based on the entered specification information and the remaining resources of the node to verify whether the resource allocation meets the following resource verification rules: a) The remaining CPU resources of a single node are greater than the total CPU resources required by a single replica of the executor multiplied by the number of replicas, and the remaining memory resources of a single node are greater than the total memory resources required by a single replica of the executor multiplied by the number of replicas; b) Node A's CPU resources are greater than the total CPU required by a single replica of the executor, and Node A's memory resources are greater than the total memory required by a single replica of the executor. Meanwhile, Node B's CPU resources are greater than the total CPU required by a single replica of the executor, and Node B's memory resources are greater than the total memory required by a single replica of the executor. The resource allocation satisfies at least one of the resource verification rules in a) and b), that is, passes the resource verification.

4. The method for implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes according to claim 1, characterized in that: Execute step S225, after writing the executor information into the scheduling resource configuration table, start a scheduled task to regularly check the pod status of the executor: If all containers in the Pod become Ready within the set time, the Pod is considered normal; If the set time has passed and there are still containers in the Pod that are not Ready, the Pod status is considered abnormal.

5. The method for implementing multi-tenant task scheduling using XXL-JOB based on Kubernetes according to claim 1, characterized in that: The step S3 specifically includes the following operations: S310. The user creates a computing task through the front-end interface of the Kubernetes cluster management center and selects the workspace ID and task type for the computing task. S320: Query the scheduling resource configuration table based on the workspace ID and task type of the computing task to obtain a list of available task scheduling resources that match the workspace and task type. The list includes the CPU specification, memory specification, number of replicas, and namespace of each available task scheduling resource. S330: The user selects the required resources from the available task scheduling resource list and binds the computing task to the selected resources. The selected resources constitute a virtual resource pool for the computing task for subsequent task execution. S340: After the computing task is successfully bound to the selected resource, the corresponding scheduling policy information is automatically generated and registered in the designated task group of the scheduling center so that the scheduling center can manage and execute the scheduling task according to the scheduling policy.

Images