Distributed container scheduling system and method based on docker native API

Abstract

The application belongs to the technical field of computers, and particularly relates to a distributed container scheduling system and method based on a Docker native API. A resource acquisition module creates a communication connection with a local host Docker engine according to a Docker SDK, and acquires real-time resource data of a container managed by the local host. An index evaluation module calls preset custom index evaluation rules to evaluate node availability according to the real-time resource data, and constructs a dynamic resource pool. An intelligent scheduling decision module constructs a decision tree according to node information in the container managed by the local host, takes the dynamic resource pool as a growing resource of the decision tree, calls a rule-based scheduling algorithm to distribute the real-time resource data to nodes corresponding to the decision tree, and a management deployment module directly creates, starts, stops and migrates the container according to a resource scheduling and distribution result of the intelligent scheduling decision module. The application can solve the problem of poor strategy flexibility in the prior art.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computers, and particularly relates to a distributed container scheduling system and method based on a Docker native API. BACKGROUND

[0002] In the current digital era, the rapid development of artificial intelligence and big data technology promotes the wide application of GPU clusters in many fields such as scientific research and industrial production. In particular, small and medium-sized GPU clusters have become the first choice for many enterprises and research institutions to conduct deep learning model training and data processing because of their relatively low cost and flexible deployment. However, as the cluster size expands and the application scenarios become increasingly complex, how to efficiently schedule and manage resources in the GPU cluster has become a key problem to be solved.

[0003] The emergence of container technology provides a new way to solve this problem. Containers can package application programs and their dependencies into an independent running unit, decouple applications from underlying infrastructure, and have the advantages of lightweight, portability, and easy deployment. Common distributed container scheduling systems include Kubernetes, Docker Swarm, etc. Kubernetes is an open-source container orchestration system with powerful functions and a rich plugin ecosystem, supporting automatic deployment, scaling, and management of containerized applications. However, the architecture of Kubernetes is relatively complex, and the configuration and maintenance cost is high. For small and medium-sized GPU clusters, there may be a problem of excessive resource overhead. Docker Swarm is a container cluster management tool provided by Docker, which groups multiple Docker nodes into a cluster to achieve cross-node deployment and management of containers. However, compared with Kubernetes, Docker Swarm has relatively weak functions and certain limitations in flexibility and scalability of scheduling strategies. SUMMARY

[0004] The technical problem solved by the application is to provide a distributed container scheduling system and method based on a Docker native API to solve the problem of poor strategy flexibility in existing distributed container scheduling technology.

[0005] The basic scheme provided by the application is a distributed container scheduling system based on a Docker native API, which includes a resource acquisition module, an index evaluation module, an intelligent scheduling decision module, and a management and deployment module, wherein:

[0006] The resource acquisition module is used to create a communication connection with the local host Docker engine according to the Docker SDK, and to acquire real-time resource data of containers managed by the local host.

[0007] The index evaluation module is configured to evaluate node availability according to the real-time resource data by invoking a preset custom index evaluation rule, and construct a dynamic resource pool;

[0008] The intelligent scheduling decision module is configured to construct a decision tree according to node information in the containers managed in the local host, take the dynamic resource pool as a growing resource of the decision tree, and invoke a rule-based scheduling algorithm to distribute real-time resource data to nodes corresponding to the decision tree;

[0009] The management and deployment module is configured to directly create, start, stop and migrate the containers according to the resource scheduling and distribution results of the intelligent scheduling decision module.

[0010] Further, the intelligent scheduling decision module includes a decision tree construction unit, a resource scheduling unit and an intelligent decision unit. The decision tree construction unit is configured to extract core resource features of container scheduling as a splitting basis of the decision tree, and dynamically update the decision tree according to changes in dynamic resource pool data;

[0011] The resource scheduling unit is configured to form a multi-objective scheduling candidate set by fusing GPU idle priority, load balancing and custom strategy, and dynamically control strategy weights according to scheduling task quantity by using an improved ant lion optimization algorithm, and finally output an optimal scheduling strategy;

[0012] The intelligent decision unit distributes real-time resource data to execution nodes corresponding to the decision tree according to the optimal scheduling strategy.

[0013] Further, the decision tree construction unit extracts core resource features of container scheduling as a splitting basis of the decision tree, specifically as follows:

[0014] Taking GPU idle memory occupancy as the root node of the decision tree, splitting the root node based on node availability in the dynamic resource pool as a splitting threshold to generate root node branches;

[0015] Taking GPU computing load, CPU usage and memory usage as branches of the decision tree;

[0016] Detailed information of GPU computing load, CPU usage and memory usage is stored in leaf nodes of the decision tree.

[0017] Further, in the resource scheduling unit, the multi-objective scheduling candidate set is formed by fusing GPU idle priority, load balancing and custom strategy, specifically as follows:

[0018] Initialize the node set as ;

[0019] For each node , the GPU idle priority strategy score is calculated based on the idle resources and load of the node GPU, and the expression is:

[0020]

[0021] wherein, is the GPU idle video memory of the node , is the total video memory, is the GPU computing load, , is a fixed coefficient; is the GPU idle priority strategy score, and the score range after standardization processing is ;

[0022] The load balancing strategy score is calculated based on the comprehensive load of the node, and the expression is:

[0023]

[0024] wherein, represents the CPU usage rate, is the GPU computing load, is the memory usage rate, , , is the load weight, is the load balancing strategy score, and the score range after standardization processing is ;

[0025] The custom strategy score is calculated according to the rules configured by the user .

[0026] Further, the improved ant lion optimization algorithm is used to dynamically control the strategy weight according to the scheduling task quantity, and finally outputs the optimal scheduling strategy, which is specifically:

[0027] The initial scheduling task set is ;

[0028] The task quantity index is calculated, and the expression is:

[0029]

[0030] wherein, is the task quantity index, is the current task quantity, is the maximum concurrent task number, is the GPU video memory demand of task t, is the total idle GPU video memory of the cluster; , is a coefficient;

[0031] based on the task amount index The GPU idle priority strategy, the load balancing strategy and the weight of the custom strategy are dynamically regulated, and the weight of the GPU idle priority strategy , the weight of the load balancing strategy , and the weight of the custom strategy are obtained.

[0032] After calling the improved ant lion optimization algorithm, initializing the population, constructing the fitness function based on the GPU idle priority strategy, the load balancing strategy and the custom strategy, the expression is:

[0033]

[0034] According to the task amount index , the ant updates the position by simulating the trap of the ant lion, and the expression is:

[0035]

[0036] Among them, corresponding , , ; indicates the jth weight of the tth generation of ant lion, is the inertia coefficient, which is dynamically adjusted with the task amount, ;

[0037] After each iteration, the fitness of all ants and ant lions is calculated, the top 50% of ant lions with the highest fitness are selected and reserved, the rest are replaced by the ants with the highest fitness, and the global optimal ant lion is reserved. Global optimal ant lion does not participate in replacement;

[0038] When the number of iterations reaches the preset number of iterations, the iteration is stopped, and the weight combination corresponding to the global optimal ant lion is output ;

[0039] According to the weight combination corresponding to the global optimal ant lion, the comprehensive score of all nodes is calculated, and the node with the highest comprehensive score is selected as the optimal scheduling strategy.

[0040] Further, the preset custom index evaluation rule in the index evaluation module includes a GPU memory occupation evaluation rule and a computing load evaluation rule. The GPU memory occupation evaluation rule includes obtaining the memory usage of the GPU through a command line tool, and extracting the total capacity and used capacity of the memory of each GPU.

[0041] The computing load evaluation rule is to obtain the CPU usage of the system through the psutil library, and simultaneously obtain the number of running processes and the number of processes in the waiting state in the current system, and evaluate the load of the CPU.

[0042] The node availability is specifically:

[0043] When GPU memory usage is lower than a preset threshold and the computing load is lower than a preset threshold, the node is determined as an available node, the available node is included in the dynamic resource pool, and the node information in the dynamic resource pool is updated in real time.

[0044] Further, the index evaluation module further presets a dynamic resource pool updating mechanism, and the dynamic resource pool updating mechanism is specifically:

[0045] The resource scheduling and allocation result in the intelligent scheduling decision module is obtained, and the calling condition of each level node on the decision tree is judged.

[0046] If the calling condition in the judgment result reaches a preset calling threshold, a result of high utilization of the decision tree is output.

[0047] If the calling condition in the judgment result does not reach the preset calling threshold, a result of low utilization of the decision tree is output.

[0048] The dynamic resource pool performs pre-removal or pre-expansion on the available nodes in the pool according to the utilization result of the decision tree.

[0049] The pre-removal is that the dynamic resource pool is provided with an expansion pool, the dynamic resource pool removes a preset amount of available nodes to the expansion pool according to the result of low utilization of the decision tree, and the remaining available nodes in the dynamic resource pool participate in the construction of the decision tree.

[0050] The pre-expansion is that the dynamic resource pool extracts a preset amount of available nodes from the expansion pool to supplement to the dynamic resource pool according to the result of high utilization of the decision tree, and participates in the construction of the decision tree.

[0051] Further, in the management and deployment module, the direct creation, start, stop and migration operations of the container according to the resource scheduling and allocation result of the intelligent scheduling decision module are specifically:

[0052] Creating a container: initializing container configuration information, including the image name used by the container, the command running in the container, the environment variable setting and the resource limit;

[0053] Starting the container: calling the start method to start the container;

[0054] Stopping the container: calling the stop method to stop the container;

[0055] Migrating the container: creating a new container on the target node, the configuration information of which is the same as that of the original container; copying the original container data to the new container, starting the new container on the target node, and stopping the original container.

[0056] Further, a fault detection module and a self-recovery module are further included, the fault detection module continuously monitors abnormal states of the containers by deploying a lightweight Agent and running a heartbeat service inside the containers;

[0057] The self-recovery module is used for controlling the management deployment module to perform a restart operation or a migration operation on the corresponding container according to the monitored abnormal states of the containers.

[0058] The distributed container scheduling method based on the Docker native API is applied to the distributed container scheduling system based on the Docker native API and includes the following steps:

[0059] S1: A communication connection with a local host Docker engine is created according to a Docker SDK, and real-time resource data of containers managed by the local host is acquired;

[0060] S2: The real-time resource data is used to call preset custom index evaluation rules to evaluate node availability, and a dynamic resource pool is constructed;

[0061] S3: A decision tree is constructed according to node information in the containers managed in the local host, the dynamic resource pool is used as a growing resource of the decision tree, a rule-based scheduling algorithm is called to distribute the real-time resource data to nodes corresponding to the decision tree, and the real-time resource data is distributed to the nodes corresponding to the decision tree;

[0062] S4: Containers are directly created, started, stopped and migrated according to resource scheduling and distribution results of the intelligent scheduling decision module.

[0063] The principle and advantages of the application are that the technical scheme of the application takes the Docker native API as a core technical base, collects node CPU, GPU, memory and other resource data in real time by calling the Docker SDK, constructs a dynamic resource pool in combination with custom indexes (GPU memory occupation, calculation load), an intelligent scheduling decision module constructs a three-level decision tree with GPU idle memory occupation ratio as a root node and CPU / memory usage ratio as branch nodes based on the dynamic resource pool, fuses a quantitative scoring function of GPU idle priority, load balancing and a custom strategy, introduces an improved ant lion optimization algorithm, dynamically controls weights of the three strategies through a task amount index, and optimizes ant position update logic by using an inertia coefficient fused with the task amount, finally outputs a global optimal weight combination and a corresponding scheduling node; meanwhile, fault self-recovery is realized through heartbeat detection and resource anomaly monitoring of a lightweight Agent, and a full-closed-loop technical architecture of "resource perception-intelligent decision-container management-fault self-recovery" is formed.

[0064] The advantages are that the technical scheme of the application effectively takes into account the lightweight demand and scheduling reliability of a small and medium-sized GPU cluster.

[0065] On the one hand, by directly connecting to Docker's native API, the overhead of intermediate layers in complex orchestration systems such as Kubernetes is avoided. The decision tree structure significantly reduces the range of node selection. The improved Antlion optimization algorithm can dynamically adapt the strategy weight according to the task volume, thereby reducing scheduling latency and improving resource utilization.

[0066] On the other hand, the dynamic resource pool and fault self-healing mechanism (automatic restart or migration of abnormal containers) ensure high service availability and high system availability. At the same time, it supports custom strategy configuration, which can flexibly adapt to AI training, data processing and other scenarios, solving the problem of insufficient adaptability of traditional fixed strategies when the workload fluctuates, and achieving dual optimization of resource efficiency and service stability. Attached Figure Description

[0067] Figure 1 This is a functional block diagram of an embodiment of the present invention;

[0068] Figure 2 This is a flowchart of an embodiment of the present invention;

[0069] Figure 3 This describes the dynamic resource pool update mechanism process in this embodiment of the invention. Detailed Implementation

[0070] The following detailed description illustrates the specific implementation method:

[0071] The basic implementation examples are as follows: Figure 1 As shown: A distributed container scheduling system based on Docker's native API, including a resource acquisition module, a metric evaluation module, an intelligent scheduling decision module, and a management and deployment module, wherein:

[0072] The resource acquisition module is used to create a communication connection with the local host Docker engine based on the Docker SDK to obtain real-time resource data of containers managed by the local host.

[0073] In this embodiment, Docker, as an open-source containerization platform, provides a rich set of native APIs, namely the Docker SDK, which allows developers to interact with the Docker engine programmatically to perform various operations on containers and images.

[0074] The core principle of the Docker SDK is based on the RESTful architecture, communicating with the Docker daemon via the HTTP protocol. This communication method allows developers to use various programming languages, such as Python, Go, and Java, to write applications that interact with Docker, greatly improving the system's flexibility and scalability.

[0075] Therefore, the application utilizes the powerful function characteristics of the Docker SDK to realize real-time monitoring of resource usage of each node through the stats method. Specifically, taking Python as the development tool, firstly, a connection with the local Docker daemon is established through the docker.from_env() method. After the connection is established, the client.containers.list() method is used to obtain a list of all running containers on the current host. For each container, the stats() method thereof is called. The stats() method sends an HTTP request to the Docker daemon to obtain real-time resource usage data of the container. For example, when obtaining the CPU usage, the JSON data returned by the stats() method contains the cpu_stats field, wherein total_usage under the cpu_usage indicates the cumulative CPU time used by the container since startup, and system_cpu_usage indicates the total CPU time of the system since startup. By calculating the ratio of the two and combining the time interval, the CPU usage of the container can be accurately obtained.

[0076] For the memory usage, relevant information is obtained from the memory_stats field in the returned JSON data. The usage indicates the amount of memory currently used by the container, and the limit indicates the maximum amount of memory that the container is limited to use. By using the two values, the memory usage rate can be calculated to intuitively understand the degree of occupation of the container to the memory resource.

[0077] The index evaluation module is configured to evaluate the node availability according to the real-time resource data by calling preset custom index evaluation rules, and construct a dynamic resource pool;

[0078] In the embodiment, the preset custom index evaluation rules in the index evaluation module include a GPU memory occupation evaluation rule and a computing load evaluation rule. The GPU memory occupation evaluation rule includes obtaining the GPU memory usage through a command line tool, extracting the total capacity and used capacity of the memory of each GPU. For example, the regular expression is used to match the memory usage data in the output, which is converted into a numerical form for calculation. When the GPU memory occupation is lower than 30%, it indicates that the GPU node has high availability in terms of memory resources and can provide sufficient memory space for new tasks.

[0079] The computing load evaluation rule is to obtain the system CPU usage through the psutil library, and simultaneously obtain the number of running processes and the number of processes in the waiting state in the current system to evaluate the CPU load. For example, when the computing load is lower than 40%, it is considered that the node has good availability in terms of computing resources and can stably run new tasks.

[0080] The index evaluation module evaluates GPU memory occupation and computing load according to the GPU memory occupation evaluation rule and the computing load evaluation rule. When the GPU memory occupation is lower than a preset threshold and the computing load is lower than a preset threshold, for example, when the GPU memory occupation is lower than 30% and the computing load is lower than 40%, the node is determined as an available node. The available node is included in the dynamic resource pool, and the node information in the dynamic resource pool is updated in real time. When a new task needs to be scheduled, the available node is preferentially selected from the dynamic resource pool, so as to ensure that the task can run on a node with sufficient resources and stable performance, and improve the execution efficiency and success rate of the task. Through the node availability evaluation method based on the self-defined index, the system can more flexibly and accurately adapt to different workloads and resource demands, optimize resource allocation, and improve the performance and reliability of the entire cluster.

[0081] The intelligent scheduling decision module is configured to construct a decision tree according to node information in a container managed by a local host, take the dynamic resource pool as growth resources of the decision tree, and call a rule-based scheduling algorithm to allocate real-time resource data to nodes corresponding to the decision tree. The intelligent scheduling decision module includes a decision tree construction unit, a resource scheduling unit, and an intelligent decision unit. The decision tree construction unit is configured to extract core resource features of container scheduling as a splitting basis of the decision tree, and dynamically update the decision tree according to changes in dynamic resource pool data. Specifically,

[0082] First, the GPU idle memory occupation ratio is taken as the root node of the decision tree, and the node availability in the dynamic resource pool is taken as the splitting threshold to split the root node to generate root node branches. In this application, the GPU idle memory occupation ratio is taken as the root node splitting feature. In a GPU cluster, GPU resources are the most critical constraints for task scheduling, and preferentially selecting nodes with sufficient GPU resources can reduce subsequent computing overhead. As for the design of the splitting threshold, three splitting thresholds are set based on the standard definition of available nodes in the dynamic resource pool (GPU memory occupation 30% (i.e., GPU idle memory occupation ratio 70%)

[0083] Threshold 1: GPU idle memory occupation ratio 70%, indicating that the GPU resources are sufficient and are preferentially selected;

[0084] Threshold 2: 30% GPU idle memory occupation ratio 70%, indicating that the GPU resources are medium and are secondarily selected;

[0085] Threshold 3: GPU idle memory occupation ratio 30%, indicating that the GPU resources are insufficient and are not selected.

[0086] Therefore, the root node is split into 3 branches, each branch corresponds to a set of child nodes, for example:

[0087] Branch A: contains all GPU free memory ratio 70% of the nodes;

[0088] Branch B: contains all 30% GPU free memory ratio 70% of the nodes;

[0089] Branch C: contains all GPU free memory ratio 30% of the nodes;

[0090] Then, the GPU computing load, CPU usage and memory usage are used as the branches of the decision tree; in this embodiment, the branches are mainly selected as Branch A and Branch B when selecting the root node, the GPU computing load is selected as the branch of Branch A, the CPU usage is selected as the branch of Branch B, and the memory usage is selected as the branch of Branch A and Branch B.

[0091] The detailed information of the GPU computing load, CPU usage and memory usage is stored in the leaf nodes of the decision tree, including: node ID list, resource data information, priority coefficient, etc.

[0092] Finally, when performing dynamic updating of the decision tree, the decision tree is updated every preset time, for example, 10s.

[0093] The resource scheduling unit is used to form a multi-objective scheduling candidate set by fusing GPU free priority, load balancing and custom strategy, and to dynamically control the strategy weight according to the scheduling task amount by using an improved ant lion optimization algorithm, and finally to output the optimal scheduling strategy; wherein the generation of the multi-objective scheduling candidate set is specifically:

[0094] The initialized node set is ;

[0095] For each node , the GPU free priority strategy score is calculated based on the node GPU free resource and load, and the expression is:

[0096]

[0097] Wherein, is the GPU free memory of the node , is the total memory, is the GPU computing load, , is a fixed coefficient; ​To score the GPU idle priority strategy, the score range is ensured to be ;

[0098] The load balancing strategy score is calculated based on the node comprehensive load, and the expression is:

[0099]

[0100] wherein, represents the CPU usage rate, represents the GPU computing load, represents the memory usage rate, , , represents the load weight, represents the load balancing strategy score, and the score range is ensured to be ;

[0101] The custom strategy score is calculated according to the rules configured by the user , and in this embodiment, the custom strategy is low-load node priority, and the expression is:

[0102]

[0103] wherein, represents the node comprehensive load, represents the load threshold set by the user;

[0104] Then, the strategy weight is dynamically regulated according to the scheduling task amount by using the improved lion-ant optimization algorithm, and specifically:

[0105] The initial scheduling task set is ;

[0106] The task amount index is calculated ; the expression is:

[0107]

[0108] wherein, represents the task amount index, represents the current task number, represents the maximum concurrent task number, represents the GPU memory requirement of task t, represents the total idle GPU memory of the cluster; , are coefficients, and in this application , ;

[0109] The task amount index The weight of the GPU idle priority strategy, the load balancing strategy and the custom strategy is dynamically regulated to obtain the weight of the GPU idle priority strategy , the weight of the load balancing strategy and the weight of the custom strategy . The dynamic regulation rule of the weight is as follows:

[0110] The weight of the GPU idle priority strategy : when the task amount is small, the task is preferentially guaranteed to be quickly deployed, the weight decreases with the increase of T, and the expression is:

[0111]

[0112] The weight of the load balancing strategy : when the task amount is large, resource inclination is preferentially avoided, the weight increases with the increase of T, and the expression is:

[0113]

[0114] The weight of the custom strategy : firstly, the calculation results of the weight of the GPU idle priority strategy and the weight of the load balancing strategy are ensured , and then the value of the weight of the custom strategy is obtained through ;

[0115] The improved ant lion optimization algorithm is called, the population is initialized, the fitness function based on the GPU idle priority strategy, the load balancing strategy and the custom strategy is constructed, and the expression is:

[0116]

[0117] According to the task amount index , the ant updates the position by simulating the trap of the ant lion, and the expression is:

[0118]

[0119] wherein, , corresponds to , , ; represents the jth weight of the tth generation of ant lion, is an inertia coefficient, which is dynamically adjusted according to the task amount ;

[0120] After each iteration, the fitness of all ants and ant lions is calculated, the top 50% of ant lions with the highest fitness are retained, the rest are replaced by the ants with the highest fitness, and the global optimal ant lion is retained, and the global optimal ant lion does not participate in replacement;

[0121] When the number of iterations reaches the preset number of iterations, the iteration is stopped, and the weight combination corresponding to the global optimal ant lion is output ;

[0122] According to the weight combination corresponding to the global optimal ant lion, the comprehensive scores of all nodes are calculated, and the node with the highest comprehensive score is selected as the optimal scheduling strategy.

[0123] At the same time, a dynamic resource pool updating mechanism is also preset in the index evaluation module, as shown in Figure 3 , the preset dynamic resource pool updating mechanism is specifically:

[0124] Obtain the resource scheduling and distribution result in the intelligent scheduling decision module, and judge the calling condition of each level node on the decision tree;

[0125] If the calling condition in the judgment result reaches the preset calling threshold, the result of the decision tree with high utilization rate is output;

[0126] If the calling condition in the judgment result does not reach the preset calling threshold, the result of the decision tree with low utilization rate is output;

[0127] The dynamic resource pool pre-eliminates or pre-expands the available nodes in the pool according to the utilization rate result of the decision tree;

[0128] The pre-elimination is that the dynamic resource pool is provided with an expansion pool, the dynamic resource pool eliminates a preset amount of available nodes to the expansion pool according to the result of the low utilization rate of the decision tree, and the remaining available nodes in the dynamic resource pool participate in the construction of the decision tree;

[0129] The pre-expansion is that the dynamic resource pool extracts a preset amount of available nodes from the expansion pool to supplement into the dynamic resource pool according to the result of the high utilization rate of the decision tree, and participates in the construction of the decision tree;

[0130] In the above technical solution, specifically, in the final resource scheduling allocation result, the calling condition of each level node on the decision tree of the node is judged, and the calling condition can reflect the computing power required by the system. When the calling condition covers 70%-90% of the nodes of the decision tree or even more, it indicates that the decision tree is in a high utilization state, and there may not be enough available nodes. Therefore, the available nodes in the dynamic resource pool are pre-expanded. When the calling condition covers less than 70% of the decision tree, it indicates that the utilization rate of the nodes on the decision tree is not high. At this time, the dynamic resource pool pre-removes the available nodes in the resource pool according to the utilization rate of the decision tree. In this way, on the one hand, the stability and sustainability of the decision tree in container scheduling are ensured, and on the other hand, the dynamic construction process of the decision tree makes the computing power of the system be reasonably and efficiently utilized, and the waste of resources is avoided.

[0131] Then the intelligent decision unit allocates the real-time resource data to the execution node corresponding to the decision tree according to the optimal scheduling strategy.

[0132] Finally, the management and deployment module directly creates, starts, stops and migrates the container according to the resource scheduling allocation result of the intelligent scheduling decision module. Specifically:

[0133] Create a container: initialize the container configuration information, including the image name used by the container, the command running in the container, the environment variable setting and the resource limit;

[0134] Start the container: call the start method to start the container;

[0135] Stop the container: call the stop method to stop the container;

[0136] Migrate the container: create a new container on the target node, and the configuration information is the same as that of the original container; copy the original container data to the new container, start the new container on the target node, and stop the original container.

[0137] Therefore, in the management and deployment module of the present application, the container operation is directly performed by using the Docker API, which avoids complex intermediate layer processing, improves the efficiency and flexibility of operation, and reduces the complexity and maintenance cost of the system.

[0138] Further, the fault detection module and the self-recovery module are also included, the fault detection module continuously monitors the abnormal state of the container by deploying a lightweight Agent and running a heartbeat service inside the container; the specific implementation manner is that a heartbeat service is run inside the container, the service listens to a specific port and waits for the Agent to send a heartbeat request. The Agent sends an HTTP GET request to the heartbeat port of the container at a certain time interval (for example, 5 seconds); if the heartbeat service inside the container runs normally, it will respond to the request of the Agent in time and return a specific response information indicating that the container process is alive; when the response of the heartbeat packet is not received for 3 times in succession, the Agent determines that the process is abnormal, which may be caused by the application program crash inside the container, resource exhaustion, process termination caused by the system and the like; once the process abnormality is detected, the Agent will immediately report the information to the self-recovery module of the system to trigger the corresponding self-recovery mechanism.

[0139] The self-recovery module is used for controlling and managing the deployment module to perform a restart operation or a migration operation on the corresponding container according to the monitored abnormal state of the container; specifically, when the container process abnormality or the resource occupation abnormality is detected, the system first attempts to restart the container through the restart method of the Docker API, if the problem still exists after the container is restarted, or the restart cannot solve the problem according to the abnormal situation, the system will select to migrate the container to other available nodes; the migration process is as follows: first, the system selects an available target node according to the node information in the dynamic resource pool; then, a new container is created on the target node by using the same configuration information as the original container through the create_container method of the Docker API; then, the data of the original container is copied to the new container, which can be realized by using the docker cp command or by mounting a shared storage volume; finally, the new container is started on the target node and the original container is stopped. In this way, the migration of the container between different nodes is realized, and the continuity and high availability of the service are ensured. In the whole abnormality processing and self-recovery process, the system records the abnormal information and the processing process, so as to facilitate the subsequent fault analysis and system optimization.

[0140] As shown in FIG. 1, Figure 2 As shown in FIG. 1,

[0141] S1: A communication connection with a local host Docker engine is created according to the Docker SDK, and real-time resource data of a container managed by the local host is acquired;

[0142] S2: calling preset custom index evaluation rules to evaluate node availability according to real-time resource data, and constructing a dynamic resource pool;

[0143] S3: constructing a decision tree according to node information in the container managed in the local host, taking the dynamic resource pool as the growing resource of the decision tree, and calling a rule-based scheduling algorithm to distribute real-time resource data to nodes corresponding to the decision tree;

[0144] S4: directly creating, starting, stopping and migrating the container according to the resource scheduling and distribution result of the intelligent scheduling decision module.

[0145] The above is only an embodiment of the present application, and common knowledge such as specific structures and characteristics in the scheme is not described in detail here. The person skilled in the art knows all the common technical knowledge in the field of the present application before the filing date or the priority date, can know all the prior art in the field, and has the ability to apply conventional experimental means before that date. The person skilled in the art can improve and implement the present scheme based on the disclosure given in the present application, and the typical known structures or known methods should not be an obstacle for the person skilled in the art to implement the present application. It should be noted that, for those skilled in the art, without departing from the structure of the present application, a number of modifications and improvements can be made, which should also be considered as the protection scope of the present application, and these will not affect the effect and practicality of the present application. The protection scope of the present application should be subject to the content of its claims, and the specific implementation mode and the like in the specification can be used to explain the content of the claims.

Claims

1. A distributed container scheduling system based on Docker native API, characterized in that: The system comprises a resource acquisition module, an index evaluation module, an intelligent scheduling decision module, and a management deployment module, wherein: The resource acquisition module is configured to create a communication connection with a local host Docker engine according to a Docker SDK, and to acquire real-time resource data of a container managed by the local host; The index evaluation module is configured to evaluate node availability according to the real-time resource data by calling a preset custom index evaluation rule, and to construct a dynamic resource pool; The intelligent scheduling decision module is configured to construct a decision tree according to node information in the container managed by the local host, to use the dynamic resource pool as a growing resource of the decision tree, and to call a rule-based scheduling algorithm to distribute the real-time resource data to nodes corresponding to the decision tree; The management deployment module is configured to directly create, start, stop, and migrate the container according to a resource scheduling and distribution result of the intelligent scheduling decision module; The intelligent scheduling decision module comprises a decision tree construction unit, a resource scheduling unit, and an intelligent decision unit, the decision tree construction unit is configured to extract core resource features of container scheduling as a split basis of the decision tree, and to dynamically update the decision tree according to dynamic resource pool data changes; The resource scheduling unit is configured to form a multi-objective scheduling candidate set by fusing a GPU idle priority, load balancing, and a custom strategy, to dynamically regulate and control strategy weights according to a scheduling task amount by using an improved ant lion optimization algorithm, and to finally output an optimal scheduling strategy; The intelligent decision unit is configured to distribute the real-time resource data to execution nodes corresponding to the decision tree according to the optimal scheduling strategy; The improved ant lion optimization algorithm is called, a population is initialized, an adaptability function based on the GPU idle priority strategy, the load balancing strategy, and the custom strategy is constructed, and an expression is as follows: The initialization scheduling task set is ; Computing task volume index , the expression is: wherein, is a task amount index, is a current task amount, is a maximum concurrent task number, is a GPU memory requirement of a task t, is a total free GPU memory of a cluster; , is a coefficient; Task-based index Dynamically regulate the weight of the GPU idle priority strategy, the load balancing strategy and the custom strategy to obtain the weight of the GPU idle priority strategy , the weight of the load balancing strategy , and the weight of the custom strategy ; After each iteration, the adaptabilities of all ants and ant lions are calculated, the top 50% of ant lions with the highest adaptabilities are reserved, the rest are replaced by ants with the highest adaptabilities, and a globally optimal ant lion is reserved and does not participate in replacement; wherein, represents a GPU idle priority policy score, represents a load balancing policy score, represents a custom policy score; According to the task amount index The ants update their positions by simulating the traps of ant lions, expressed as: wherein, , corresponding , , ; denotes the jth weight of the tth generation of aardvarks, is an inertia coefficient, dynamically adjusted with the task volume, ; The comprehensive scores of all nodes are calculated according to a weight combination corresponding to the globally optimal ant lion, and a node with the highest comprehensive score is selected as the optimal scheduling strategy; When the number of iterations reaches the preset number of iterations, the iteration is stopped, and a weight combination corresponding to the global optimal ant lion is output ; In the resource scheduling unit, the GPU idle priority, the load balancing, and the custom strategy are fused to form a multi-objective scheduling candidate set, and the specific process is as follows: A load balancing strategy score is calculated based on node comprehensive load, and an expression is as follows: The set of initialization nodes is initialized to ; For each node , the GPU idle priority policy score is calculated based on the node GPU idle resources and load, expressed as: wherein, is the GPU free memory, is the GPU idle memory, is the total memory, is the GPU computing load, , is the fixed coefficient; is the GPU idle priority policy score, the score range is after standardization processing. In the decision tree construction unit, the core resource features of container scheduling are extracted as the split basis of the decision tree, and the specific process is as follows: wherein, represents the CPU usage rate, is the GPU computing load, is the memory usage rate, , , is the load weight, is the load balancing strategy score, and the score range after standardization is ; Calculating a custom policy score according to user-configured rules . 2.The Docker native API based distributed container scheduling system of claim 1, wherein: GPU idle memory occupancy is taken as a root node of the decision tree, node availability in the dynamic resource pool is taken as a split threshold, and the root node is split to generate root node branches; GPU computing load, CPU usage, and memory usage are taken as branches of the decision tree; Detailed information of the GPU computing load, the CPU usage, and the memory usage is stored in leaf nodes of the decision tree. ​ 3.The Docker native API based distributed container scheduling system of claim 1, wherein: The preset custom index evaluation rule in the index evaluation module includes a GPU memory occupation evaluation rule and a computing load evaluation rule, the GPU memory occupation evaluation rule includes obtaining GPU memory usage through a command line tool, and extracting total capacity and used capacity of memory of each GPU; The computing load evaluation rule is to obtain system CPU usage through a psutil library, and simultaneously obtain the number of processes running in the current system and the number of processes in a waiting state, so as to evaluate the load of the CPU; The node availability is specifically: When the GPU memory occupation is lower than a preset threshold and the computing load is lower than a preset threshold, the node is determined as an available node, the available node is included in a dynamic resource pool, and node information in the dynamic resource pool is updated in real time.

4. The Docker native API based distributed container scheduling system according to claim 1, characterized in that: The index evaluation module further presets a dynamic resource pool updating mechanism, and the dynamic resource pool updating mechanism is specifically: Obtaining a resource scheduling and distribution result in the intelligent scheduling decision module, judging calling conditions of nodes at each level in a decision tree; If the calling condition in the judgment result reaches a preset calling threshold, a result with high utilization of the decision tree is output; If the calling condition in the judgment result does not reach the preset calling threshold, a result with low utilization of the decision tree is output; The dynamic resource pool performs pre-removal or pre-expansion on available nodes in the pool according to the utilization result of the decision tree; The pre-removal is that: the dynamic resource pool is provided with an expansion pool, and the dynamic resource pool removes a preset number of available nodes to the expansion pool according to the result with low utilization of the decision tree, and the remaining available nodes in the dynamic resource pool participate in construction of the decision tree; The pre-expansion is that: the dynamic resource pool extracts a preset number of available nodes from the expansion pool according to the result with high utilization of the decision tree, and supplements the available nodes to the dynamic resource pool to participate in construction of the decision tree. 5.The Docker native API based distributed container scheduling system of claim 1, wherein: In the management and deployment module, the resource scheduling and distribution result of the intelligent scheduling decision module is used to directly create, start, stop and migrate a container, and the direct creation, start, stop and migration of the container are specifically: Creating a container: initializing container configuration information, including an image name used by the container, a command running in the container, environment variable setting and resource limitation; Starting the container: calling a start method to start the container; Stopping the container: calling a stop method to stop the container; Migrating the container: creating a new container on a target node, the configuration information of the new container being the same as that of the original container; copying data of the original container to the new container, starting the new container on the target node, and stopping the original container. 6.The Docker native API based distributed container scheduling system of claim 5, wherein: Further comprising a fault detection module and a self-healing module, the fault detection module deploys a lightweight agent and runs a heartbeat service inside a container to continuously monitor an abnormal state of the container; The self-healing module is used to control the management and deployment module to perform a restart operation or a migration operation on a corresponding container according to the monitored abnormal state of the container.

7. A distributed container scheduling method based on Docker's native API, applied to the distributed container scheduling system based on Docker's native API as described in any one of claims 1-6, characterized in that: Including: S1: According to the Docker SDK, a communication connection with a local host Docker engine is created to obtain real-time resource data of a container managed by the local host; S2: According to the real-time resource data, a preset custom index evaluation rule is called to evaluate node availability, and a dynamic resource pool is constructed; S3: Construct a decision tree according to the node information in the container managed in the local host, take the dynamic resource pool as the growth resource of the decision tree, and call the rule-based scheduling algorithm to allocate the real-time resource data to the node corresponding to the decision tree; S4: Directly create, start, stop and migrate the container according to the resource scheduling allocation result of the intelligent scheduling decision module.

Images