Distributed container scheduling system and method based on Docker native API

Abstract

The invention belongs to the technical field of computers, and particularly relates to a distributed container scheduling system and method based on a Docker native API (Application Program Interface), and the method comprises the steps: creating a communication connection with a local host Docker engine through a resource obtaining module according to a Docker SDK (Software Development Kit), and obtaining real-time resource data of a container managed by a local host; calling a preset self-defined index evaluation rule to evaluate node availability through an index evaluation module according to the real-time resource data, and constructing a dynamic resource pool; a decision tree is constructed through an intelligent scheduling decision module according to node information in a container managed in a local host, a dynamic resource pool is used as a growth resource of the decision tree, and a rule-based scheduling algorithm is called to distribute real-time resource data to nodes corresponding to the decision tree; and directly creating, starting, stopping and migrating the container through the management deployment module according to the resource scheduling distribution result of the intelligent scheduling decision module. According to the invention, the problem of poor strategy flexibility of a distributed container scheduling technology in the prior art can be solved.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a distributed container scheduling system and method based on the native API of Docker. Background Technology

[0002] In today's digital age, the rapid development of artificial intelligence and big data technologies has led to the widespread application of GPU clusters in numerous fields such as scientific research and industrial production. In particular, small and medium-sized GPU clusters, due to their relatively low cost and flexible deployment, have become the preferred choice for many enterprises and research institutions for tasks such as deep learning model training and data processing. However, as the cluster size increases and the application scenarios become increasingly complex, how to efficiently schedule and manage the resources in the GPU cluster has become a critical issue that urgently needs to be addressed.

[0003] The emergence of container technology has provided a new approach to solving this problem. Containers can package applications and their dependencies into an independent running unit, decoupling the application from the underlying infrastructure. They have advantages such as lightweight, portability, and ease of deployment. Common distributed container scheduling systems include Kubernetes and Docker Swarm. 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, Kubernetes has a relatively complex architecture and high configuration and maintenance costs, which may lead to excessive resource overhead for small to medium-sized GPU clusters. Docker Swarm is a container cluster management tool provided by Docker. It combines multiple Docker nodes into a cluster, enabling cross-node deployment and management of containers. However, compared to Kubernetes, Docker Swarm has relatively weaker functions and certain limitations in terms of scheduling strategy flexibility and scalability. Summary of the Invention

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

[0005] The basic solution provided by this invention is a distributed container scheduling system based on the Docker native API, including a resource acquisition module, a metric evaluation module, an intelligent scheduling decision module, and a management and deployment module, wherein: 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. The indicator evaluation module is used to evaluate node availability based on real-time resource data and call preset custom indicator evaluation rules to build a dynamic resource pool. The intelligent scheduling decision module is used to construct a decision tree based on the node information in the containers managed on the local host, use the dynamic resource pool as the growth resource of the decision tree, and call the rule-based scheduling algorithm to allocate real-time resource data to the corresponding nodes of the decision tree. The management and deployment module is used to directly create, start, stop, and migrate containers based on the resource scheduling and allocation results of the intelligent scheduling decision module.

[0006] Furthermore, 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 used to extract the core resource features of container scheduling as the basis for splitting the decision tree, and to dynamically update the decision tree according to changes in dynamic resource pool data. The resource scheduling unit is used to form a multi-objective scheduling candidate set by integrating GPU idle priority, load balancing and custom strategies, and to dynamically adjust the strategy weights according to the scheduling task volume using the improved Antlion optimization algorithm, and finally output the optimal scheduling strategy. The intelligent decision-making unit allocates real-time resource data to the execution nodes corresponding to the decision tree according to the optimal scheduling strategy.

[0007] Furthermore, the core resource features of container scheduling extracted by the decision tree construction unit are used as the basis for splitting the decision tree, specifically as follows: Using the percentage of idle GPU memory as the root node of the decision tree, and using the availability of nodes in the dynamic resource pool as the splitting threshold, the root node is split to generate root node branches. GPU computing load, CPU utilization, and memory utilization are used as the branches of the decision tree; The leaf nodes of the decision tree store detailed information on GPU computing load, CPU utilization, and memory utilization.

[0008] Furthermore, the resource scheduling unit integrates GPU idle priority, load balancing, and custom strategies to form a multi-objective scheduling candidate set, specifically as follows: Initialize the node set as ; For each node The GPU idle priority strategy score is calculated based on the node's GPU idle resources and load, and the expression is:

[0009] in, For nodes GPU free memory, Total video memory, For GPU computing load, , It is a fixed coefficient; The GPU idle-first strategy is scored, and the score range after standardization is: ; The load balancing strategy score is calculated based on the overall node load, and the expression is:

[0010] in, Indicates CPU utilization. For GPU computing load, For memory usage, , , For load weight, The load balancing strategy is scored, and the standardized score range is as follows: ; Calculate custom strategy scores based on user-configured rules. .

[0011] Furthermore, the improved antlion optimization algorithm dynamically adjusts the strategy weights based on the scheduling task load, ultimately outputting the optimal scheduling strategy as follows: Initialize the task set to ; Calculate the task volume index The expression is:

[0012] in, This represents the workload index. The current number of tasks. To the maximum number of concurrent tasks, The GPU memory requirements for task t. Total free GPU memory in the cluster; , For coefficients; Based on task volume index The weights of the GPU idle priority strategy, load balancing strategy, and custom strategy are dynamically adjusted to obtain the GPU idle priority strategy weight. Load balancing strategy weights Custom strategy weights ; After initializing the population by invoking the improved antlion optimization algorithm, a fitness function based on a GPU idle priority strategy, a load balancing strategy, and a custom strategy is constructed, with the following expression:

[0013] Based on the task volume index Ants update their position by simulating an antlion's trap, expressed as:

[0014] in, ,correspond , , ; This represents the weight of the j-th antlion in the t-th generation. This is the inertia coefficient, which is dynamically adjusted according to the workload. ; After each iteration, calculate the fitness of all ants and antlions, select the top 50% of antlions with the highest fitness to retain, replace the rest with the ants with the highest fitness, and retain the globally optimal antlion. The globally optimal antlion does not participate in the replacement. Once the preset number of iterations is reached, the iteration stops, and the weight combination corresponding to the globally optimal antlion is output. ; Calculate the comprehensive score of all nodes based on the weight combination corresponding to the globally optimal antlion, and select the node with the highest comprehensive score as the optimal scheduling strategy.

[0015] Furthermore, the preset custom indicator evaluation rules in the indicator evaluation module include GPU memory usage evaluation rules and computing load evaluation rules. The GPU memory usage evaluation rules include obtaining the GPU memory usage through command line tools and extracting the total memory capacity and used capacity of each GPU. The computational load assessment rule is to obtain the system CPU utilization through the psutil library, and at the same time obtain the number of processes currently running in the system and the number of processes in a waiting state to assess the CPU load. The node availability is specifically defined as follows: When the GPU memory usage is lower than a preset threshold and the computing load is lower than a preset threshold, the node is determined to be a usable node, the usable node is added to the dynamic resource pool, and the node information in the dynamic resource pool is updated in real time.

[0016] Furthermore, the indicator evaluation module also includes a preset dynamic resource pool update mechanism, which specifically includes: Obtain the resource scheduling and allocation results from the intelligent scheduling decision module, and determine the calling status of nodes at each level of the decision tree; If the decision tree utilization rate is high, the result of the judgment result reaches the preset call threshold. If the decision tree utilization rate is low, the result of the decision tree utilization rate is output. The dynamic resource pool pre-removes or pre-expands available nodes within the pool based on the utilization results of the decision tree. The pre-removal is as follows: the dynamic resource pool has an expansion pool. Based on the result of low decision tree utilization, the dynamic resource pool removes a preset number of available nodes to the expansion pool. The remaining available nodes in the dynamic resource pool participate in the construction of the decision tree. The pre-expansion is as follows: based on the result of high utilization of the decision tree, the dynamic resource pool extracts a preset number of available nodes from the expansion pool to supplement the dynamic resource pool and participate in the construction of the decision tree.

[0017] Furthermore, in the management and deployment module, the direct creation, startup, shutdown, and migration operations of containers based on the resource scheduling and allocation results of the intelligent scheduling decision module are specifically as follows: Create a container: Initialize container configuration information, including the image name used by the container, the commands to run inside the container, environment variable settings, and resource limits; Start the container: Call the start method to start the container; Stop the container: Call the stop method to stop the container; Migrate a container: Create a new container on the target node with the same configuration information as the original container; copy the data from the original container into the new container; start the new container on the target node and stop the original container.

[0018] Furthermore, it also includes a fault detection module and a self-healing module. 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 self-healing module is used to control the management and deployment module to perform a restart or migration operation on the corresponding container based on the abnormal state of the monitored container.

[0019] A distributed container scheduling method based on Docker's native API, applied to the aforementioned distributed container scheduling system based on Docker's native API, includes: S1: 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; S2: Evaluate node availability based on real-time resource data and call preset custom indicator evaluation rules to build a dynamic resource pool; S3: Construct a decision tree based on the node information in the containers managed on the local host, use the dynamic resource pool as the growth resource for the decision tree, and call the rule-based scheduling algorithm to allocate real-time resource data to the corresponding nodes of the decision tree; S4: Based on the resource scheduling and allocation results of the intelligent scheduling decision module, perform direct creation, startup, stop, and migration operations on containers.

[0020] The principles and advantages of this invention are as follows: The technical solution of this application takes the Docker native API as the core technology foundation, and collects resource data such as CPU, GPU, and memory of nodes in real time by calling the Docker SDK. Combined with custom indicators (GPU memory usage, computing load) to build a dynamic resource pool; the intelligent scheduling decision module builds a three-level decision tree based on the dynamic resource pool, with the GPU idle memory ratio as the root node and the CPU / memory usage rate as the branch node. It integrates the quantitative scoring function of GPU idle priority, load balancing and custom strategies, introduces an improved antlion optimization algorithm, dynamically adjusts the weight of the three strategies through the task volume index, and optimizes the ant position update logic by using the inertia coefficient of the integrated task volume. Finally, it outputs the globally optimal weight combination and the corresponding scheduling node; at the same time, it achieves fault self-healing through heartbeat detection and resource anomaly monitoring of a lightweight agent, forming a closed-loop technical architecture of "resource perception - intelligent decision-making - container management - fault self-healing".

[0021] The advantages are: the technology in this application effectively balances the lightweight requirements and scheduling reliability of small- to medium-sized GPU clusters. 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. 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

[0022] Figure 1 This is a functional block diagram of an embodiment of the present invention; Figure 2 This is a flowchart of an embodiment of the present invention; Figure 3 This is the process of the dynamic resource pool update mechanism in this embodiment of the invention. Detailed Implementation

[0023] The following detailed description illustrates the specific implementation method: 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: 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. 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.

[0024] 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.

[0025] Therefore, this application leverages the powerful features of the Docker SDK to achieve real-time monitoring of resource usage on each node through the `stats` method. Specifically, using Python as the development tool, a connection to the local Docker daemon is first established using the `docker.from_env()` method. After establishing the connection, the `client.containers.list()` method is used to obtain a list of all running containers on the current host. For each container, its `stats()` method is called. This method sends an HTTP request to the Docker daemon to obtain the container's real-time resource usage data. For example, when obtaining CPU usage, the JSON data returned by the `stats()` method includes a `cpu_stats` field. Under `cpu_usage`, `total_usage` represents the cumulative CPU time used by the container since startup, and `system_cpu_usage` represents the total CPU time used by the system since startup. By calculating the ratio of these two values ​​and combining them with the time interval, the container's CPU usage can be accurately obtained. For memory usage information, relevant data can be obtained from the `memory_stats` field in the returned JSON data. Here, `usage` represents the amount of memory currently used by the container, and `limit` represents the maximum amount of memory the container is limited to using. These two values ​​can be used to calculate the memory utilization rate, providing a clear understanding of the container's memory resource consumption.

[0026] The indicator evaluation module is used to evaluate node availability based on real-time resource data and call preset custom indicator evaluation rules to build a dynamic resource pool. In this embodiment, the preset custom indicator evaluation rules in the indicator evaluation module include GPU memory usage evaluation rules and computing load evaluation rules. The GPU memory usage evaluation rules include obtaining the GPU memory usage through command-line tools, extracting the total memory capacity and used capacity of each GPU, for example, using regular expressions to match the memory usage data in the output and converting it into numerical form for calculation; when the GPU memory usage is less 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.

[0027] The computational load assessment rule is to obtain the system CPU utilization through the psutil library, and at the same time obtain the number of processes currently running in the system and the number of processes in the waiting state to assess the CPU load. For example, when the computational load is below 40%, the node is considered to have good availability in terms of computing resources and can stably run new tasks.

[0028] The metric evaluation module assesses GPU memory usage and computational load based on GPU memory usage and computational load evaluation rules. When both GPU memory usage and computational load fall below preset thresholds (e.g., below 30% and 40% respectively), the node is deemed available and added to the dynamic resource pool, with the pool's node information updated in real-time. When new tasks need scheduling, available nodes are prioritized from the dynamic resource pool to ensure tasks run on resource-sufficient and stable nodes, improving execution efficiency and success rate. This node availability evaluation method based on custom metrics allows the system to more flexibly and accurately adapt to different workloads and resource requirements, optimizing resource allocation and improving the overall cluster performance and reliability.

[0029] The intelligent scheduling decision module constructs a decision tree based on node information in containers managed on the local host. Using a dynamic resource pool as the growth resource for the decision tree, it invokes a rule-based scheduling algorithm to allocate real-time resource data to the corresponding nodes in 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 extracts core resource features for container scheduling as the basis for splitting the decision tree and dynamically updates the decision tree based on changes in the dynamic resource pool data. Specifically: First, the root node of the decision tree is selected using the percentage of free GPU memory as the root node. The node's branch is then split based on the availability of nodes in the dynamic resource pool. In this application, the percentage of free GPU memory is used as the root node splitting feature because, in a GPU cluster, GPU resources are the most critical constraint for task scheduling; prioritizing nodes with sufficient GPU resources reduces subsequent computational overhead. Regarding the design of the splitting threshold, this application is based on the standard definition of available nodes in the dynamic resource pool (GPU memory usage). 30% is the percentage of free GPU memory. 70%), combined with resource redundancy, three splitting thresholds are set, specifically: Threshold 1: Percentage of idle GPU memory 70% indicates sufficient GPU resources, making it a priority candidate; Threshold 2: 30% GPU free memory percentage 70% indicates moderate GPU resources, making it a secondary candidate; Threshold 3: Percentage of idle GPU memory A score of 30% indicates that GPU resources are strained, and the device is not eligible for consideration.

[0030] Therefore, the root node splits into 3 branches, each branch corresponding to a set of child nodes, for example: Branch A: Includes the percentage of free video memory used by all GPUs. 70% of the nodes; Branch B: Contains all 30% GPU free memory percentage 70% of the nodes; Branch C: Includes the percentage of free video memory used by all GPUs. 30% of the nodes; Next, GPU computing load, CPU utilization, and memory utilization are used as branches of the decision tree. In this embodiment, when selecting the root node, branches A and B are mainly selected. GPU computing load is selected as the branch for branch A, CPU utilization is selected as the branch for branch B, and memory utilization is used as the branch for both branches A and B. The leaf nodes of the decision tree store detailed information on GPU computing load, CPU utilization, and memory utilization, including: a list of node IDs, resource data information, priority coefficients, etc.

[0031] Finally, when performing dynamic updates to the decision tree, the decision tree is updated every preset time interval, such as 10 seconds.

[0032] The resource scheduling unit is used to form a multi-objective scheduling candidate set by integrating GPU idle priority, load balancing, and custom strategies, and to dynamically adjust the strategy weights based on the scheduling task volume using an improved Antlion optimization algorithm, ultimately outputting the optimal scheduling strategy; wherein, the generation of the multi-objective scheduling candidate set is specifically as follows: Initialize the node set as ; For each node The GPU idle priority strategy score is calculated based on the node's GPU idle resources and load, and the expression is:

[0033] in, For nodes GPU free memory, Total video memory, For GPU computing load, , It is a fixed coefficient; The GPU idle-first strategy is scored, and after standardization, the scoring range is ensured to be within a certain range. ; The load balancing strategy score is calculated based on the overall node load, and the expression is:

[0034] in, Indicates CPU utilization. For GPU computing load, For memory usage, , , For load weight, The load balancing strategy is scored, and after standardization, the scoring range is ensured to be within a certain range. ; Calculate custom strategy scores based on user-configured rules. In this embodiment, the custom strategy is to prioritize low-load nodes, and the expression is:

[0035] in, For the overall load of the nodes, Load thresholds set for users; Next, the improved Antlion optimization algorithm is used to dynamically adjust the strategy weights based on the amount of scheduled tasks, specifically: Initialize the task set to ; Calculate the task volume index The expression is:

[0036] in, This represents the workload index. The current number of tasks. To the maximum number of concurrent tasks, The GPU memory requirements for task t. Total free GPU memory in the cluster; , As a coefficient, in this application , ; Based on task volume index The weights of the GPU idle priority strategy, load balancing strategy, and custom strategy are dynamically adjusted to obtain the GPU idle priority strategy weight. Load balancing strategy weights Custom strategy weights The dynamic weight adjustment rules are as follows: GPU idle priority strategy weight When the task volume is small, priority is given to ensuring rapid task deployment. The weight decreases as T increases, as expressed in the following expression:

[0037] Load balancing strategy weight When the workload is heavy, resource allocation should be avoided first. The weight increases as T increases, as expressed in the following expression:

[0038] Custom strategy weights First, based on the GPU idle priority strategy weights... and load balancing strategy weights The calculation results, and ensure Then through To obtain custom strategy weights The value; After initializing the population by invoking the improved antlion optimization algorithm, a fitness function based on a GPU idle priority strategy, a load balancing strategy, and a custom strategy is constructed, with the following expression:

[0039] Based on the task volume index Ants update their position by simulating an antlion's trap, expressed as:

[0040] in, ,correspond , , ; This represents the weight of the j-th antlion in the t-th generation. This is the inertia coefficient, which is dynamically adjusted according to the workload. ; After each iteration, calculate the fitness of all ants and antlions, select the top 50% of antlions with the highest fitness to retain, replace the rest with the ants with the highest fitness, and retain the globally optimal antlion. The globally optimal antlion does not participate in the replacement. Once the preset number of iterations is reached, the iteration stops, and the weight combination corresponding to the globally optimal antlion is output. ; Calculate the comprehensive score of all nodes based on the weight combination corresponding to the globally optimal antlion, and select the node with the highest comprehensive score as the optimal scheduling strategy.

[0041] Meanwhile, the indicator evaluation module also includes a preset dynamic resource pool update mechanism, such as... Figure 3 As shown, the preset dynamic resource pool update mechanism is as follows: Obtain the resource scheduling and allocation results from the intelligent scheduling decision module, and determine the calling status of nodes at each level of the decision tree; If the decision tree utilization rate is high, the result of the judgment result reaches the preset call threshold. If the decision tree utilization rate is low, the result of the decision tree utilization rate is output. The dynamic resource pool pre-removes or pre-expands available nodes within the pool based on the utilization results of the decision tree. The pre-removal is as follows: the dynamic resource pool has an expansion pool. Based on the result of low decision tree utilization, the dynamic resource pool removes a preset number of available nodes to the expansion pool. The remaining available nodes in the dynamic resource pool participate in the construction of the decision tree. The pre-expansion is as follows: based on the result of high utilization of the decision tree, the dynamic resource pool extracts a preset number of available nodes from the expansion pool to supplement the dynamic resource pool and participate in the construction of the decision tree. In the above technical solution, specifically, in the final resource scheduling and allocation result, the calling status of nodes at each level of the decision tree is judged. The calling status reflects the computing power required by the system. When the calling status covers 70%-90% or more of the nodes in the decision tree, it indicates that the decision tree is in a state of high utilization, but there may be insufficient available nodes. In this case, the available nodes in the dynamic resource pool are pre-expanded. Conversely, when the calling status covers less than 70% of the decision tree, it indicates that the nodes in the decision tree are underutilized. In this case, the resource pool is dynamically updated based on the utilization status of the decision tree, and available nodes in the resource pool are pre-removed. 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 ensures that the computing power of the system is used reasonably and efficiently, avoiding resource waste.

[0042] Then, the intelligent decision-making unit allocates real-time resource data to the corresponding execution nodes of the decision tree according to the optimal scheduling strategy.

[0043] Finally, the management and deployment module directly creates, starts, stops, and migrates containers based on the resource scheduling and allocation results from the intelligent scheduling decision module. Specifically: Create a container: Initialize container configuration information, including the image name used by the container, the commands to run inside the container, environment variable settings, and resource limits; Start the container: Call the start method to start the container; Stop the container: Call the stop method to stop the container; Migrate a container: Create a new container on the target node with the same configuration information as the original container; copy the data from the original container into the new container; start the new container on the target node and stop the original container.

[0044] Therefore, the container operation method of directly using Docker API in the management and deployment module of this application avoids complex intermediate layer processing, improves the efficiency and flexibility of operation, and also reduces the complexity and maintenance cost of the system.

[0045] In addition, it includes a fault detection module and a self-healing module. The fault detection module deploys a lightweight agent and runs a heartbeat service inside the container to continuously monitor the container's abnormal state. Specifically, a heartbeat service runs inside the container, listening on a specific port and waiting for the agent to send heartbeat requests. The agent sends an HTTP GET request to the container's heartbeat port at regular intervals (e.g., 5 seconds). If the heartbeat service inside the container is running normally, it will respond to the agent's request in a timely manner, returning a specific response message indicating that the container process is alive. When no heartbeat response is received for three consecutive times, the agent determines that the process is abnormal. This may be due to reasons such as application crashes inside the container or resource exhaustion leading to system termination of the process. Once a process abnormality is detected, the agent will immediately report this information to the system's self-healing module, triggering the corresponding self-healing mechanism.

[0046] The self-healing module controls the management and deployment module to perform restart or migration operations on the corresponding containers based on the abnormal states of the monitored containers. Specifically, when an abnormal container process or abnormal resource usage is detected, the system first attempts to restart the container using the Docker API's `restart` method. If the problem persists after restarting, or if the abnormal situation indicates that restarting cannot resolve the issue, the system will choose to migrate the container to another available node. The migration process is as follows: First, the system selects an available target node based on the node information in the dynamic resource pool. Then, on the target node, a new container is created using the same configuration information as the original container, via the Docker API's `create_container` method. Next, the data from the original container is copied to the new container, which can be achieved 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, container migration between different nodes is achieved, ensuring service continuity and high availability. Throughout the entire anomaly handling and self-healing process, the system records anomaly information and the handling process for subsequent fault analysis and system optimization.

[0047] like Figure 2 As shown, in another embodiment of this example, a distributed container scheduling method based on the Docker native API is also included, applied to the aforementioned distributed container scheduling system based on the Docker native API, including: S1: 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; S2: Evaluate node availability based on real-time resource data and call preset custom indicator evaluation rules to build a dynamic resource pool; S3: Construct a decision tree based on the node information in the containers managed on the local host, use the dynamic resource pool as the growth resource for the decision tree, and call the rule-based scheduling algorithm to allocate real-time resource data to the corresponding nodes of the decision tree; S4: Based on the resource scheduling and allocation results of the intelligent scheduling decision module, perform direct creation, startup, stop, and migration operations on containers.

[0048] The above are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A distributed container scheduling system based on Docker's native API, characterized by: It includes a resource acquisition module, an indicator evaluation module, an intelligent scheduling decision-making module, and a management and deployment module, among which: 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. The indicator evaluation module is used to evaluate node availability based on real-time resource data and call preset custom indicator evaluation rules to build a dynamic resource pool. The intelligent scheduling decision module is used to construct a decision tree based on the node information in the containers managed on the local host, use the dynamic resource pool as the growth resource of the decision tree, and call the rule-based scheduling algorithm to allocate real-time resource data to the corresponding nodes of the decision tree. The management and deployment module is used to directly create, start, stop, and migrate containers based on the resource scheduling and allocation results of the intelligent scheduling decision module. 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 used to extract the core resource features of container scheduling as the basis for splitting the decision tree, and to dynamically update the decision tree according to changes in dynamic resource pool data. The resource scheduling unit is used to form a multi-objective scheduling candidate set by integrating GPU idle priority, load balancing and custom strategies, and to dynamically adjust the strategy weights according to the scheduling task volume using the improved Antlion optimization algorithm, and finally output the optimal scheduling strategy. The intelligent decision-making unit allocates real-time resource data to the execution nodes corresponding to the decision tree according to the optimal scheduling strategy. The improved antlion optimization algorithm dynamically adjusts the strategy weights based on the scheduling task load, and finally outputs the optimal scheduling strategy as follows: Initialize the task set to ; Calculate the task volume index The expression is: in, This represents the workload index. The current number of tasks. To the maximum number of concurrent tasks, The GPU memory requirements for task t. Total free GPU memory in the cluster; , For coefficients; Based on task volume index The weights of the GPU idle priority strategy, load balancing strategy, and custom strategy are dynamically adjusted to obtain the GPU idle priority strategy weight. Load balancing strategy weights Custom strategy weights ; After initializing the population by invoking the improved antlion optimization algorithm, a fitness function based on a GPU idle priority strategy, a load balancing strategy, and a custom strategy is constructed, with the following expression: Based on the task volume index Ants update their position by simulating an antlion's trap, expressed as: in, ,correspond , , ; This represents the weight of the j-th antlion in the t-th generation. This is the inertia coefficient, which is dynamically adjusted according to the workload. ; After each iteration, calculate the fitness of all ants and antlions, select the top 50% of antlions with the highest fitness to retain, replace the rest with the ants with the highest fitness, and retain the globally optimal antlion. The globally optimal antlion does not participate in the replacement. Once the preset number of iterations is reached, the iteration stops, and the weight combination corresponding to the globally optimal antlion is output. ; Calculate the comprehensive score of all nodes based on the weight combination corresponding to the globally optimal antlion, and select the node with the highest comprehensive score as the optimal scheduling strategy.

2. The distributed container scheduling system based on Docker's native API according to claim 1, characterized in that: The core resource features of container scheduling extracted from the decision tree construction unit are used as the basis for splitting the decision tree, specifically: Using the percentage of idle GPU memory as the root node of the decision tree, and using the availability of nodes in the dynamic resource pool as the splitting threshold, the root node is split to generate root node branches. GPU computing load, CPU utilization, and memory utilization are used as the branches of the decision tree; The leaf nodes of the decision tree store detailed information on GPU computing load, CPU utilization, and memory utilization.

3. The distributed container scheduling system based on Docker's native API according to claim 1, characterized in that: The resource scheduling unit integrates GPU idle priority, load balancing, and custom strategies to form a multi-objective scheduling candidate set, specifically as follows: Initialize the node set as ; For each node The GPU idle priority strategy score is calculated based on the node's GPU idle resources and load, and the expression is: in, For nodes GPU free memory, Total video memory, For GPU computing load, , It is a fixed coefficient; The GPU idle-first strategy is scored, and the score range after standardization is: ; The load balancing strategy score is calculated based on the overall node load, and the expression is: in, Indicates CPU utilization. For GPU computing load, For memory usage, , , For load weight, The load balancing strategy is scored, and the standardized score range is as follows: ; Calculate custom strategy scores based on user-configured rules. .

4. The distributed container scheduling system based on Docker's native API according to claim 1, characterized in that: The preset custom indicator evaluation rules in the indicator evaluation module include GPU memory usage evaluation rules and computing load evaluation rules. The GPU memory usage evaluation rules include obtaining the GPU memory usage through command line tools and extracting the total memory capacity and used capacity of each GPU. The computational load assessment rule is to obtain the system CPU utilization through the psutil library, and at the same time obtain the number of processes currently running in the system and the number of processes in a waiting state to assess the CPU load. The node availability is specifically defined as follows: When the GPU memory usage is lower than a preset threshold and the computing load is lower than a preset threshold, the node is determined to be a usable node, the usable node is added to the dynamic resource pool, and the node information in the dynamic resource pool is updated in real time.

5. The distributed container scheduling system based on Docker's native API according to claim 1, characterized in that: The indicator evaluation module also includes a preset dynamic resource pool update mechanism, which specifically includes: Obtain the resource scheduling and allocation results from the intelligent scheduling decision module, and determine the calling status of nodes at each level of the decision tree; If the decision tree utilization rate is high, the result of the decision tree utilization rate is output. If the decision tree utilization rate is low, the result of the decision tree utilization rate is output. The dynamic resource pool pre-removes or pre-expands available nodes within the pool based on the utilization results of the decision tree. The pre-removal is as follows: the dynamic resource pool has an expansion pool. Based on the result of low decision tree utilization, the dynamic resource pool removes a preset number of available nodes to the expansion pool. The remaining available nodes in the dynamic resource pool participate in the construction of the decision tree. The pre-expansion is as follows: based on the result of high utilization of the decision tree, the dynamic resource pool extracts a preset number of available nodes from the expansion pool to supplement the dynamic resource pool and participate in the construction of the decision tree.

6. The distributed container scheduling system based on Docker's native API according to claim 1, characterized in that: In the management and deployment module, the direct creation, startup, shutdown, and migration operations of containers based on the resource scheduling and allocation results of the intelligent scheduling decision module are specifically as follows: Create a container: Initialize container configuration information, including the image name used by the container, the commands to run inside the container, environment variable settings, and resource limits; Start the container: Call the start method to start the container; Stop the container: Call the stop method to stop the container; Migrate a container: Create a new container on the target node with the same configuration information as the original container; copy the data from the original container into the new container; start the new container on the target node and stop the original container.

7. The distributed container scheduling system based on the Docker native API according to claim 6, characterized in that: It also includes a fault detection module and a self-healing module. 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 self-healing module is used to control the management and deployment module to perform a restart or migration operation on the corresponding container based on the abnormal state of the monitored container.

8. 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-7, characterized in that: include: S1: 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; S2: Evaluate node availability based on real-time resource data and call preset custom indicator evaluation rules to build a dynamic resource pool; S3: Construct a decision tree based on the node information in the containers managed on the local host, use the dynamic resource pool as the growth resource for the decision tree, and call the rule-based scheduling algorithm to allocate real-time resource data to the corresponding nodes of the decision tree; S4: Based on the resource scheduling and allocation results of the intelligent scheduling decision module, perform direct creation, startup, stop, and migration operations on containers.

Images