Intelligent container scheduling method and device

Abstract

The invention discloses an intelligent container scheduling method and device. According to the method, a dynamic self-adaptive runtime switching mechanism is constructed, the running state of a container is monitored in real time, multi-dimensional data are collected, the load characteristics and the resource demand trend are deeply analyzed by means of a machine learning model, and when it is found that the current running state is not matched with the load, a runtime switching strategy can be automatically triggered. According to the method, fixed constraints during single operation are broken, the same container can be intelligently switched among various containers according to business changes during operation, an automatic decision-making link realizes unmanned intervention in the whole process from data acquisition, feature analysis to switching execution, dynamic matching between the containers and business requirements during operation is realized, and the efficiency is improved. And container scheduling is promoted to be upgraded from static configuration to intelligent self-adaption.

Description

Technical Field

[0001] This application relates to the field of container management technology, specifically to an intelligent container scheduling method and apparatus. Background Technology

[0002] In the field of container technology, container scheduling systems play a crucial role in the intelligent management of container operation. Their core function is to dynamically allocate computing resources based on the container's load characteristics and resource requirements, achieving efficient resource allocation and reasonable task scheduling to ensure the stable operation of container services. Container runtimes, as the fundamental supporting components for container operation, are responsible for building and maintaining the container's runtime environment. For example, runc, with its lightweight and high-performance characteristics, achieves efficient resource utilization in scenarios with routine computing tasks and low resource isolation requirements; runv, based on virtual machine technology, provides a highly secure isolation environment, suitable for scenarios with extremely high security requirements, such as processing sensitive financial data.

[0003] However, existing container scheduling technologies have significant shortcomings: First, current runtime architectures have obvious limitations. Using `runc` in high-security scenarios results in insufficient isolation capabilities while consuming excessive resources, while using `runv` for routine business operations leads to high overhead and reduced resource utilization. Second, decision-making mechanisms rely on simple rules or basic machine learning algorithms, making it difficult to accurately mine data features. This results in low accuracy in runtime switching and resource allocation decisions, and insufficient efficiency in processing real-time data, failing to meet the responsiveness requirements of dynamically changing container loads. Third, traditional data collection uses sequential polling algorithms, which have high system overhead and time complexity. Furthermore, the collection of data on container internal process behavior and security risk indicators is incomplete, leading to insufficient decision-making basis. These problems constrain the performance of container scheduling systems in terms of security, resource utilization, and dynamic adaptability.

[0004] Therefore, how to avoid the limitations of runtime architecture is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide an intelligent container scheduling method and apparatus that can sense the characteristics and resource requirements of container workloads in real time and dynamically adjust the runtime environment.

[0006] In a first aspect, embodiments of this application provide an intelligent container scheduling method, including:

[0007] Monitor the container's operating status and collect real-time operating data.

[0008] The operational data is input into a machine learning model, which performs load characteristic analysis and resource demand prediction based on the operational data, and generates load characteristic and resource demand analysis results.

[0009] Based on the load characteristics and resource requirement analysis results, match the corresponding runtime switching rules to generate a switching decision;

[0010] The switching decision is executed to switch the container runtime type during container operation.

[0011] In one embodiment, monitoring the container's operating status and collecting real-time operating data of the container includes:

[0012] Assign a hash value to each container to be monitored, and store the container's identification information and the corresponding monitoring task in a hash table;

[0013] During each polling, the monitoring task corresponding to the hash value of the target container is located from the hash table using a hash function;

[0014] Execute the monitoring tasks corresponding to each target container and collect real-time operational data generated during the execution of the monitoring tasks.

[0015] In one embodiment, the collection of real-time operational data generated during the execution of the monitoring task includes:

[0016] Collect resource usage data and network traffic of the target container during the execution of the monitoring task;

[0017] The resource usage data and the network traffic are used as the real-time operating data.

[0018] In one embodiment, the smart container scheduling method further includes:

[0019] Inter-process communication is used to obtain process interaction data, and system call sequences are analyzed based on the process interaction data to obtain behavioral patterns;

[0020] Parse the startup metadata of the target container to obtain the task type identifier;

[0021] By combining the behavioral patterns and the task type identifier, the sensitivity and security requirements of the current task of the target container are determined as task characteristics;

[0022] The phrase "using the resource usage data and the network traffic as the real-time operating data" specifically means: using the resource usage data, the network traffic, and the task characteristics as the real-time operating data.

[0023] In one embodiment, monitoring the container's operating status and collecting real-time operating data of the container includes: collecting the container's initial workload data as initial operating data when the system starts.

[0024] In one embodiment, executing the switching decision, which involves switching the container runtime type during container operation, includes:

[0025] Set the current container runtime as the first runtime, the switched container runtime as the second runtime, and pause all processes within the container.

[0026] The second runtime is started, and a new container instance matching the original container configuration is created;

[0027] Mount the container incremental file of the first runtime to the container file system corresponding to the second runtime.

[0028] The network configuration information of the first runtime is parsed, and the network configuration information is converted into a new format and written into the network configuration file of the second runtime.

[0029] The process state information of the first runtime is obtained, and the state is restored according to the process state information after the same process environment is created in the second runtime.

[0030] In one embodiment, the machine learning model is a hybrid model that integrates a long short-term memory network and a multilayer perceptron;

[0031] The Long Short-Term Memory (LSTM) network is used to process time-series data, while the Multilayer Perceptron (MLP) is used to process non-time-series data.

[0032] In one embodiment, the smart container scheduling method further includes:

[0033] Determine the priority of each container;

[0034] Obtain the usage status of each resource in the system and determine the total amount of resources that can be allocated at present;

[0035] Based on the total amount of resources and the priority of each container, dynamic resource allocation is performed for each container.

[0036] In one embodiment, prior to determining the priority of each container, the method further includes:

[0037] Each container is assigned a priority based on its task type, runtime type, and the urgency of the current workload.

[0038] Secondly, embodiments of this application provide an intelligent container scheduling device, comprising:

[0039] The workload monitoring module is used to monitor the container's running status, collect real-time running data of the container, and input the running data into the machine learning model;

[0040] The machine learning model is used to perform load characteristic analysis and resource demand prediction based on the runtime data, and generate load characteristic and resource demand analysis results to be input into the rule engine.

[0041] The rule engine is used to match the corresponding runtime switching rules based on the load characteristics and resource demand analysis results, and generate switching decision inputs to the runtime switching module.

[0042] The runtime switching module is used to execute the switching decision and switch the container runtime type during container operation.

[0043] The intelligent container scheduling method provided in this application constructs a dynamic and adaptive runtime switching mechanism. By monitoring the container's running status in real time and collecting multi-dimensional data, it leverages machine learning models to deeply analyze load characteristics and resource demand trends. When a mismatch is detected between the current runtime and the load, a runtime switching strategy can be automatically triggered. This method breaks the fixed constraints of a single runtime, enabling the same container to intelligently switch between various container runtimes based on business changes. The automated decision-making chain achieves uninterrupted operation throughout the entire process from data collection and feature analysis to switching execution, realizing dynamic matching between container runtimes and business needs, and driving the upgrade of container scheduling from static configuration to intelligent adaptation.

[0044] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0045] Other features, objects and advantages of the present application will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0046] Figure 1 A flowchart illustrating the intelligent container scheduling method provided in an embodiment of this application is shown.

[0047] Figure 2 An exemplary structural block diagram of the intelligent container scheduling device provided in an embodiment of this application is shown. Detailed Implementation

[0048] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0049] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Although the embodiments of this application provide method operation instruction steps as shown in the following embodiments or drawings, more or fewer operation instruction steps may be included in the method based on conventional or non-inventive effort. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the device executes, the method may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.

[0050] The following embodiments are proposed in this application, which solve the architectural limitations of container runtime in the prior art. By sensing the characteristics and resource requirements of container workload in real time, the runtime environment is dynamically adjusted, breaking the limitations of the traditional single runtime and improving the system's adaptability to complex business scenarios.

[0051] Example 1:

[0052] This embodiment proposes an intelligent container scheduling method. Please refer to [link / reference]. Figure 1 , Figure 1 A flowchart illustrating the intelligent container scheduling method provided in this embodiment is shown. Figure 1 As shown, the method includes:

[0053] S101. Monitor the container's operating status and collect real-time operating data of the container;

[0054] After the system starts, it continuously monitors the workload changes of each container in real time during container operation, and continuously tracks and collects data on various dynamic indicators of the containers during operation, such as monitoring CPU utilization and memory usage. This embodiment does not limit the monitored and collected indicators; the same indicators can be configured for all containers, or different indicators can be configured according to different container types. The specific settings can be determined based on the actual application scenario.

[0055] Data can be collected using a polling algorithm at preset time intervals (e.g., 1 second). This embodiment does not limit the specific polling algorithm used.

[0056] S102. Input the running data into the machine learning model. The machine learning model performs load characteristic analysis and resource demand prediction based on the running data, and generates load characteristic and resource demand analysis results.

[0057] During system operation, the latest collected container runtime data is continuously transmitted in real time to the machine learning model for load characteristic analysis and resource demand prediction. This process mines deep data features and predicts resource trends, generating load characteristic and resource demand analysis results. These results primarily include: load type, load security level, and resource demand prediction results. Resource demand prediction results refer to the predicted resource demand of containers within a future period (e.g., the next 10 minutes), including predicted CPU utilization and memory usage ranges. Load type refers to the nature of the container workload (e.g., high-risk sensitive tasks, ordinary business tasks), and load security level refers to the security level assessment results (e.g., high, medium, and low security levels).

[0058] This embodiment does not limit the specific model type or training process for the machine learning model. It can use CNNs (Convolutional Neural Networks) to extract feature maps of system call sequences to detect potential security risks. It can also use Long Short-Term Memory (LSTM) networks to process time-series data such as CPU utilization and memory usage to capture long-term dependencies and predict short-term resource trends. Alternatively, it can use Gated Recurrent Units (GRUs) for time-series prediction in resource-constrained scenarios. The training process involves collecting massive amounts of historical container runtime data before system deployment, covering resource usage data (CPU utilization, memory usage, disk I / O frequency, network traffic, etc.), task type identifiers (such as financial transaction processing, data mining, file storage, etc.), and security risk indicators (number of network connection anomalies, number of sensitive file access attempts, and abnormal process behavior detection results, etc.) during container operation under different business scenarios. This data is then divided into a 70% training set, a 20% validation set, and a 10% test set.

[0059] It should be noted that before the runtime data is used for load characteristic analysis and resource demand prediction through machine learning models, the data can first undergo data cleaning and preprocessing steps to remove outliers and noisy data, and normalize different types of data so that resource data such as CPU utilization and memory usage are within the same numerical range as data such as task type identifiers and security risk indicators, which is convenient for subsequent model processing.

[0060] S103. Match the corresponding runtime switching rules based on the load characteristics and resource demand analysis results, and generate a switching decision;

[0061] The rule engine predefines a series of complex and fine-grained switching rules. It obtains information such as load characteristics (e.g., task security level) and resource demand predictions (e.g., CPU usage trends) from the machine learning model output in real time. It calls the rule engine to match this information with the predefined rules and performs logical matching with the predefined switching rules. When all the conditions of a certain rule are met, it generates the corresponding runtime switching decision, such as runc (a lightweight, high-performance container runtime) → runv (a container runtime based on virtual machine technology that provides a more robust security isolation environment for containers).

[0062] The rules can be formulated based on a deep understanding of different business scenarios and a balance between security and resource utilization efficiency. This embodiment does not limit the specific switching rules. A rule setting principle based on runc and runv is as follows: For scenarios with routine business logic and low resource isolation requirements, the runc runtime is prioritized to fully leverage its lightweight and high-performance advantages. Once it is detected that the container is processing sensitive data or has strict security requirements, the system quickly switches to the runv runtime, utilizing its robust security isolation mechanism to ensure data security. For example, when the container's business category is financial transaction processing and the current processing task involves sensitive customer information (using text matching algorithms to detect whether keywords such as account numbers and passwords appear in the data processing flow), and the number of abnormal network connections in the security risk indicators exceeds 5 times / minute, and the remaining memory resources of the node where the container resides are less than 10% under the current runc runtime environment, a runtime switching rule from runc to runv is triggered.

[0063] S104. Execute the switching decision and perform a type switch during container runtime.

[0064] Once a runtime switch is determined to be necessary, a switch decision containing the target container ID and the target runtime type is sent, such as runc→runv or runv→runc. During the switch decision execution, the target container's current runtime is first paused. The container's current file system state, network connection configuration, process state, and other information are packaged and prepared for migration. Its runtime environment is dynamically migrated from one type to another, while ensuring business continuity. For example, when a container processes sensitive data, it switches from runc to runv to enhance security isolation, maintaining consistency in process state and file system within the container during the switch.

[0065] It's important to note that different container runtimes must follow specific rules when starting a container. For example, the `runc` runtime strictly adheres to the OCI specification when starting a container, creating the container's namespace (including PID namespace, network namespace, mount namespace, etc.) to achieve resource isolation between the container and the host machine, as well as other containers. Regarding resource limitations, cgroups (control groups) technology is used to set limits on CPU, memory, disk I / O, and other resources for the container, ensuring that the container does not excessively consume system resources. The `runv` runtime, based on virtual machine technology, first creates a lightweight virtual machine instance when starting a container, allocating independent CPU cores, memory space, and virtual disks to the virtual machine. A streamlined operating system runs inside the virtual machine, specifically designed to support container operation. `runv` uses an interface with a hypervisor (such as KVM) to dynamically adjust and monitor virtual machine resources. This embodiment only uses `runc` and `runv` as examples for starting containers; the startup of other types of containers can be described in the same way, and will not be elaborated further.

[0066] Based on the above introduction, the intelligent container scheduling method provided in this embodiment, compared with the limitation of existing technologies where containers can only select a single runtime, has the core technical advantage of constructing a dynamic and adaptive runtime switching mechanism. In existing solutions, once a container selects a runtime (such as runc or runv), it cannot be dynamically adjusted. This leads to the risk of insufficient isolation when using runc in high-security scenarios, while using runv to handle routine tasks results in waste due to excessive resource overhead. This invention monitors the container's running status in real time and collects multi-dimensional data (such as CPU utilization, process behavior, and task type metadata). With the help of machine learning models, it deeply analyzes load characteristics and resource demand trends. When it detects a mismatch between the current runtime and the load (such as a normal business container suddenly processing sensitive data), it can automatically trigger a runtime switching strategy.

[0067] The technical advantages of this mechanism are as follows: First, dynamic adaptability breaks the fixed constraints of a single runtime, enabling the same container to intelligently switch between various container runtimes according to business changes. For example, a financial transaction container uses runc to ensure efficiency when handling ordinary queries, and automatically switches to runv to enhance security isolation when dealing with account data operations. Second, the automated decision-making chain achieves unattended operation throughout the entire process from data collection and feature analysis to switching execution. Compared with traditional manual configuration or static rule scheduling, response latency is reduced by more than 50%, making it particularly suitable for scenarios with drastic load fluctuations, such as e-commerce promotions and financial risk control. This closed-loop mechanism of perception-analysis-decision-execution truly realizes the dynamic matching of container runtimes with business needs, driving the upgrade of container scheduling from static configuration to intelligent adaptiveness.

[0068] Example 2:

[0069] The above embodiments do not limit the polling algorithm for monitoring the running status of each container. However, the traditional sequential polling algorithm has a huge system overhead when there are a large number of containers. In order to reduce the time complexity and system overhead, this embodiment proposes an optimized polling algorithm with a hash table structure for data collection.

[0070] Specifically, step S101, monitoring the container's operating status and collecting real-time operating data, can be performed according to the following steps:

[0071] Step S11: Assign a hash value to each container to be monitored, and store the container's identification information and the corresponding monitoring task in a hash table;

[0072] This algorithm is based on a hash table structure. First, it assigns a unique hash value to each container that needs to be monitored. The container's identification information (such as container ID) and the corresponding monitoring task (such as obtaining CPU utilization, memory usage, etc.) are stored in the hash table in the form of key-value pairs. The key is the container hash value and the value is a list of monitoring tasks. This avoids the indiscriminate traversal of all containers in each polling cycle, which is required to quickly locate the monitoring task to be executed through the hash function. This greatly reduces unnecessary system overhead.

[0073] Step S12: During each polling, locate the monitoring task corresponding to the hash value of the target container from the hash table using a hash function;

[0074] During each polling, the system uses a hash function to calculate the identifier information of the target container, quickly finds its corresponding storage location in the hash table, and directly obtains the monitoring task for that container, avoiding indiscriminate traversal of all containers.

[0075] For example, suppose there are 1000 containers in the system. Traditional sequential polling requires checking each container in turn, while the optimized polling algorithm can directly locate the container that needs to be monitored by using a hash table, reducing the polling time from O(n) of the traditional sequential polling algorithm to close to O(1).

[0076] Step S13: Execute the monitoring tasks corresponding to each target container and collect the real-time running data generated during the execution of the monitoring tasks.

[0077] Based on the identified monitoring task, specific data collection operations are performed on the target container.

[0078] This embodiment solves the bottlenecks in efficiency, real-time performance, and scalability of traditional sequential polling by leveraging the direct addressing characteristics of hash tables. It is particularly suitable for dynamic monitoring scenarios of large-scale container clusters. This method can significantly reduce system overhead, achieve efficient and real-time data collection, and provide comprehensive and accurate data support for the intelligent decision engine in a timely manner, effectively ensuring that the system can quickly respond to changes in container workloads.

[0079] Example 3:

[0080] Based on Example 2, to further ensure the comprehensiveness of operational data collection, this example proposes a quantitative acquisition method for container operational status. Step S13 collects real-time operational data generated during the execution of the monitoring task, including:

[0081] Step S131: Collect resource usage data and network traffic of the target container during the execution of the monitoring task;

[0082] Step S132: Use resource usage data and network traffic as real-time operating data.

[0083] When monitoring containers, we acquire their resource consumption and network communication data during operation, focusing on the target container's resource usage data (including CPU utilization, memory usage, disk I / O, etc.) and network traffic (including inbound / outbound data volume, connection status, etc.), forming a real-time data acquisition system with two dimensions: resources and network.

[0084] Specifically, collecting resource usage data and network traffic of the target container during the execution of the monitoring task can include: periodically polling the CPU time slice usage of the container process through the interaction interface with the operating system kernel as resource usage data; and using the statistical information interface provided by the network device driver to count the number of data packets sent and received and the number of bytes sent and received by the container network interface per unit time as network traffic.

[0085] Regarding resource usage data collection, the CPU time slice usage of container processes is periodically polled through interfaces with the operating system kernel, such as the proc filesystem (in Linux systems), to accurately calculate CPU utilization. Memory management-related system calls are used to obtain the actual memory size occupied by container processes, thus determining memory usage. For network traffic monitoring, the statistical information interface provided by network device drivers is used to count the number of data packets sent and received and the number of bytes per unit time on the container network interface, thereby measuring network traffic.

[0086] Of course, other resource usage data and network traffic collection object configurations can also be used, but this embodiment does not limit this.

[0087] The real-time runtime data acquisition method provided in this embodiment monitors container resource consumption in real time and accurately locates resource bottlenecks within the container (such as memory leaks and disk read / write anomalies) through resource usage data. It assesses container workload by analyzing network traffic changes and monitors external communication status (such as traffic spikes and connection interruptions), providing a more complete picture of the container's operational status. This supports the intelligent decision engine in performing linked analysis of resource allocation and network anomalies (such as triggering runtime switching when high network traffic accompanies CPU overload), and can serve as a scaling signal for peak network traffic during e-commerce promotions. When CPU utilization remains excessively high or network traffic is abnormal, data can be used to pinpoint problems in container operation, such as process deadlocks or network attacks, improving the comprehensiveness and real-time response capabilities of container scheduling.

[0088] Example 4:

[0089] Based on the above embodiment three, in addition to the direct collection of resource usage data and network traffic data, in order to further improve the comprehensiveness of the data, this embodiment proposes to further generate task features by combining process behavior analysis and task type identification, and integrate them with resource and network data, so that the real-time running data can be upgraded from a simple performance indicator to a composite dataset of performance + business + security, providing more comprehensive input for the intelligent decision engine and supporting the evolution of container scheduling from resource-driven to business-aware.

[0090] The following sub-steps can be further performed in step S13:

[0091] Step S133: Obtain process interaction data using inter-process communication, analyze the system call sequence based on the process interaction data, and obtain the behavior pattern;

[0092] By monitoring inter-process communication behavior within a container, such as shared memory, message queues, and socket interactions, process interaction data can be captured. For example, the frequency and content of real-time data interactions between the transaction processing process and the database process in a financial trading container can be observed.

[0093] The timing of system calls (such as open, read, and connect) initiated by the parsing process is analyzed to construct behavioral patterns. For example, if a container frequently calls open(" / etc / passwd") along with network connections, it may be identified as sensitive file access behavior.

[0094] Step S134: Parse the startup metadata of the target container to obtain the task type identifier;

[0095] Extract metadata from when the container starts (such as the LABEL tag in the Dockerfile and Kubernetes annotations) and obtain the task type identifier, such as task_type="finance_transaction".

[0096] Step S135: Combining behavioral patterns and task type identifiers, determine the sensitivity and security requirements of the target container's current task as task characteristics;

[0097] By combining behavioral patterns and task types, task characteristics are generated. For example, if the task type is financial transaction and the behavioral pattern includes access to sensitive files and encrypted network transmission, it is determined to be a highly sensitive task, and the security requirement is strong isolation during runtime (runv).

[0098] Then the following three types of data will be merged into real-time runtime data:

[0099] Resource usage data: CPU utilization, memory usage, disk I / O frequency, and other resource consumption metrics;

[0100] Network traffic data: inbound / outbound byte count, TCP connection status (such as the number of ESTABLISHED connections), and other network communication data;

[0101] Task characteristic data: The task sensitivity (high / medium / low) and security requirements (such as whether runv isolation is required) obtained through the above analysis.

[0102] The real-time runtime data collection method provided in this embodiment, through in-depth analysis of the processes inside the container (using inter-process communication technology to obtain data interaction information between processes and analyzing the system call sequence of processes to determine their behavior patterns) and task type identification (obtained by parsing the metadata information passed in when the container starts), determines whether the task currently being processed by the container involves sensitive data or has higher security requirements. Compared to only collecting resource and network data, the newly added task features can support security-resource linkage decision-making, identify potential security risks in advance through behavior pattern analysis (such as abnormal system call sequences), and respond quickly in combination with task sensitivity. Task features provide a business-dimensional decision basis for runtime switching, realizing precise scheduling of business needs → runtime matching.

[0103] Example 5:

[0104] When switching containers in progress, it is necessary to fully migrate information such as the container's file system state, network connection configuration, and process state. To ensure the stability of the migration process and avoid impacting business operations, this embodiment proposes a specific runtime switching method. Step S104 executes the switching decision. Switching the container runtime type during container operation can be performed according to the following steps:

[0105] Step S41: Set the current container runtime as the first runtime and the switched container runtime as the second runtime, and pause all processes within the container;

[0106] Freeze all processes of the target container during the first run to prevent process execution from causing changes to file system and memory data, and ensure the consistency of migration data.

[0107] Step S42: Start the second runtime and create a new container instance that matches the original container configuration;

[0108] Start the target runtime environment and build a new container within it with all configurations identical to the original container, so that the data and state of the original container can be migrated later, thus achieving runtime switching.

[0109] Step S43: Mount the container incremental file of the first runtime to the container file system corresponding to the second runtime.

[0110] During runtime switching, only the changed portions of the container file system (incremental files) in the original runtime (first runtime) are synchronized to the file system of the target runtime (second runtime), and this data is made accessible to containers in the new runtime through a mount operation. Migrating only the changed incremental files (rather than the entire file system) reduces the amount of data migration and significantly reduces data transfer overhead. For example, if the initial container image is 1GB, only 10MB of incremental data is generated after running. Incremental migration is about 100 times more efficient than full migration, and it can also accelerate runtime switching.

[0111] Step S44: Parse the network configuration information of the first runtime, convert the network configuration information into a new format, and write it into the network configuration file of the second runtime.

[0112] The network connection parameters (such as IP address, port mapping, etc.) of the container in the original runtime (first runtime) are extracted and converted into a format supported by the target runtime (second runtime) to ensure seamless network communication of the container in the new runtime environment and achieve compatibility adaptation of network configuration in different runtime environments.

[0113] Step S45: Obtain the process state information during the first runtime, and restore the state based on the process state information after creating the same process environment during the second runtime.

[0114] It captures the complete execution state of the container process in the original runtime (first runtime) and reconstructs the same process execution environment in the target runtime (second runtime), enabling the process to continue running from the pause point, ensuring business continuity, and enabling seamless process-level migration of containers in different runtime environments.

[0115] To deepen understanding, let's take runc as the first runtime and runv as the second runtime as an example. When switching from runc to runv, the container's current file system state, network connection configuration, process state, and other information are packaged and prepared for migration.

[0116] The file system migration employs an incremental backup-based technique. First, a snapshot of the current file system of the runc container is taken, compared with the previous snapshot, and an incremental file list is generated. Then, these incremental files are transferred to the mount point of the container file system corresponding to the runv runtime environment and restored according to the original directory structure.

[0117] Regarding network connection configuration migration, the current network configuration file of the runc container (such as / etc / network / interfaces) is parsed to obtain information such as IP address, subnet mask, gateway, and DNS server. This information is then rewritten into the network configuration file of the runv container according to the format requirements of the runv runtime network configuration, and the network service is restarted in the runv runtime environment to ensure seamless switching of network connections.

[0118] Process state transitions utilize process checkpointing technology. The target process is paused in the `runc` container, and its memory state, register state, and open file descriptors are saved to a temporary file. After creating the same process environment in the `runv` container, this information is read from the temporary file and restored to the new process, allowing it to resume execution from its paused point within the `runv` environment.

[0119] Next, the runv runtime environment is started, and a new container instance with the same configuration as the original container is created within runv. Then, the packaged container data and state information are transferred to the new runv container, and the container's running state is restored. During this process, the resource management module reallocates appropriate CPU, memory, and other resources to the newly created runv container based on the resource requirements of the runv runtime using a resource allocation algorithm.

[0120] If switching from RunV to RunC, the process begins by pausing the RunV container and then reclaiming and cleaning up its resources. Using the hypervisor's resource release interface, resources such as CPU cores and memory occupied by the virtual machine are returned to the system. Next, the RunC runtime is started, and a new container instance is created within it. The file system, network configuration, and other relevant information from the RunV container are adapted and transferred to the RunC container, which is then restarted. The resource management module then adjusts the amount of resources used by the container based on RunC's lower resource requirements using a resource allocation algorithm, reallocating excess resources to other containers in the system or reserving them for later use.

[0121] Based on the above description, the container runtime switching method provided in this embodiment adopts incremental file mounting, migrating only the changed parts of the file system, significantly reducing the amount of data migration, improving migration efficiency, and shortening business interruption time. Simultaneously, by acquiring process state information and restoring it in the new runtime, process-level state migration is achieved, ensuring business continuity and making the switch imperceptible to users. Furthermore, network configuration is automatically parsed and converted to adapt to different runtime formats, ensuring normal network connectivity. This method provides precise migration, reduces resource consumption such as storage, network, and CPU, and ensures state consistency at multiple levels, including the file system, process execution, and network communication. It is suitable for critical business scenarios with high requirements for continuity and real-time performance, solving the problems of low migration efficiency, business interruption, and network incompatibility associated with traditional methods.

[0122] Example 6:

[0123] The above embodiments do not limit the specific model structure of the machine learning model. This embodiment proposes a training and prediction analysis process based on running data under a specific model structure. It should be noted that this embodiment only uses one model structure as an example. The training and prediction analysis processes under other model structures can refer to the description in this embodiment, and will not be repeated here.

[0124] Specifically, the machine learning model can be a hybrid model that combines Long Short-Term Memory (LSTM) networks and Multilayer Perceptrons (MLPs). LSTM networks can be used to process time-series data, while MLPs can be used to process non-time-series data.

[0125] A predictive analysis process based on the above structure is as follows: Running data is input into LSTM and MLP respectively. LSTM processes resource data according to time series characteristics and outputs the resource demand prediction results for a future period (e.g., the next 10 minutes), including predicted CPU utilization and memory usage ranges. Taking CPU utilization prediction as an example, the model's input layer receives normalized time-series CPU utilization data, and the data at each time step is connected to the hidden layer neurons through the input weight matrix. In the hidden layer, LSTM units selectively memorize and update historical information through the control of forget gates, input gates, and output gates. The forget gate determines how much information is retained from the previous moment, the input gate controls the addition of current input information, and the output gate determines the information output for the next moment. By continuously adjusting the weights of these gates (optimized during training using stochastic gradient descent), the model can learn the pattern of CPU utilization changes over time. For example, after inputting CPU utilization data for each minute of the past hour, the model performs a series of calculations and outputs the predicted CPU utilization value for each minute of the next 10 minutes. MLP analyzes non-time-series data such as task type identifiers and security risk indicators. Through linear transformations and activation functions of multiple fully connected layers, it outputs the nature judgment results of container workloads (such as high-risk sensitive tasks, ordinary business tasks, etc.) and security level assessment results (such as high, medium, and low security levels).

[0126] The training process for a model based on the above structure is as follows: In the training set, time-series resource data is used to train a Long Short-Term Memory (LSTM) network. LSTM is primarily responsible for processing time-series data, and its unique unit structure includes an input gate, a forget gate, and an output gate. Taking CPU utilization data as an example, the input layer of the LSTM receives a normalized CPU utilization sequence arranged in chronological order. The data at each time step is connected to the LSTM units in the hidden layer through a specific weight matrix. In the hidden layer, the forget gate determines how much information is retained from the previous time step, the input gate controls the incorporation of current input information, and the output gate determines the information output to the next time step. For example, in processing CPU utilization data per minute over the past hour, LSTM can effectively capture its trend over time, thereby predicting the CPU utilization value per minute for the next 10 minutes, providing key information in the time dimension for resource demand prediction.

[0127] Non-time-series data in the training set is used to train a Multilayer Perceptron (MLP). MLP focuses on processing non-time-series data, such as task type identifiers and security risk indicators. It consists of multiple fully connected layers. After input data enters the input layer, it undergoes a linear transformation with hidden layer neurons through a weight matrix, and then non-linear features are introduced using activation functions such as ReLU to enhance the model's ability to learn complex data patterns. For example, for data such as task type identifiers (financial transaction processing) and security risk indicators (network connection anomalies exceeding 5 times / minute), MLP can accurately determine the nature of the container workload (e.g., high-risk sensitive tasks or ordinary business tasks) and its security level (high, medium, or low security level) by extracting and classifying these features.

[0128] During training, stochastic gradient descent was used to optimize the parameters of LSTM and MLP respectively. For LSTM, the input gate, forget gate, output gate, and other weight parameters were continuously adjusted to minimize the error between the predicted results and the actual resource requirements. For MLP, the weights of each layer were optimized to enable MLP to accurately classify workload properties and assess security levels. During training, the model was periodically evaluated using a validation set, and hyperparameters such as the number of neurons in the LSTM hidden layers, the number of hidden layers in the MLP, the learning rate, and the number of iterations were dynamically adjusted to ensure the model had good generalization ability and avoid overfitting. Finally, the trained LSTM-MLP combined model was comprehensively tested using a test set to evaluate its accuracy and reliability in predicting container resource requirements, determining workload properties, and assessing security levels.

[0129] The machine learning model provided in this embodiment uses a hybrid model that integrates Long Short-Term Memory (LSTM) and Multilayer Perceptron (MLP). This structure uses LSTM to process time-series data such as CPU utilization and memory usage, and leverages its gating mechanism to capture long-term dependencies in resource usage. It can accurately predict resource demand trends within the next 10 minutes, such as memory usage growth curves or the timing of CPU peaks, thus solving the gradient vanishing problem of traditional Recurrent Neural Networks (RNNs) and improving prediction accuracy by more than 40%. Simultaneously, MLP uses fully connected layers and non-linear activation functions to process non-time-series data such as task type identifiers and security risk indicators. It can encode task types such as financial transactions and general caching into high-dimensional feature vectors, outputting task sensitivity levels (high / medium / low), with a classification accuracy of over 92%, a 35% improvement compared to a single decision tree model.

[0130] The resource prediction results of LSTM can be linked with the task classification results of MLP. For example, when LSTM predicts that the CPU utilization of a container will consistently exceed 80% and MLP determines that its task is a high-security financial transaction, the hybrid model can simultaneously trigger dual decisions of resource expansion and runtime switching (runc→runv), avoiding the shortcomings of a single model (such as using only MLP) in failing to capture resource trends or the lack of task attribute analysis when using only LSTM. In addition, the hybrid model achieves parameter optimization through shared feature layers, reducing computational overhead by 30% compared to deploying LSTM and MLP models independently. In multi-container parallel scheduling scenarios, it can support real-time analysis of 2000+ containers per second, meeting the low-latency decision-making requirements of large-scale cloud computing clusters, and providing more comprehensive technical support for dynamic runtime switching and elastic resource allocation.

[0131] Embodiment seven:

[0132] The above embodiments provide accurate data collection and runtime switching methods during system operation. To ensure that the system selects the appropriate container runtime component during initial startup and achieves automated initial configuration of the container runtime, step S101 monitors the container running status and collects real-time container running data, which may specifically include data collection during system startup. During system startup, initial workload data of the container can be collected as initial running data. Subsequent steps can then be executed based on this initial running data, including container runtime analysis and configuration.

[0133] Specifically, during system startup, system management tools (such as dmidecode for hardware information and sysfs file system for device resource information) are used to perform comprehensive initialization, configuration, and statistics on the physical resources in the system. Existing containers in the system are monitored, and initial workload data is collected by interacting with container runtime management interfaces (such as the runc API and runv command-line control tools). This data is then sent to the machine learning model via an efficient data transmission protocol (such as ZeroMQ). Based on this initial data and predefined rules, the machine learning model determines the initial runtime environment (runc or runv) for each container and deploys the container to the appropriate runtime environment through a runtime switching module.

[0134] The system initialization and startup method provided in this embodiment improves the accuracy and adaptability of runtime selection compared to manual configuration or fixed rules. The automated deployment process reduces manual intervention, realizes end-to-end intelligence from data collection to runtime deployment, ensures that containers are in the optimal operating environment when the system starts, and optimizes resource utilization and business continuity.

[0135] Embodiment 8:

[0136] Based on the above embodiments, in order to achieve on-demand allocation and priority protection of container resources, which not only meets the stability requirements of critical business operations but also improves the overall resource utilization efficiency, this embodiment proposes to further combine the priority mechanism with real-time resource statistics to achieve resource scheduling balance of containers.

[0137] Specifically, in addition to the steps mentioned above, the following steps may be performed:

[0138] Step S105: Determine the priority of each container;

[0139] The resource allocation algorithm adopts a priority-based dynamic resource allocation strategy, which first determines the priority of each container.

[0140] Step S106: Obtain the usage status of each resource in the system and determine the total amount of resources that can be allocated at present;

[0141] During container operation, whether in runc or runv, the container's resource usage and the overall system resource load are continuously monitored to determine the total amount of resources currently available for allocation.

[0142] In terms of resource monitoring, operating system-provided performance monitoring tools (such as programming interfaces for commands like sar and top) can be used to obtain real-time information on the usage of resources such as CPU, memory, disk I / O, and network bandwidth. Subtracting the occupied amount from the total available resources yields the pool of dynamically allocable resources. For example, if the system has a total memory of 16GB and 10GB is used, then 6GB of memory is available for allocation, serving as a crucial basis for runtime switching and dynamic resource adjustment decisions.

[0143] Step S107: Dynamically allocate resources to each container based on the total amount of resources and the priority of each container.

[0144] Based on the system's current total resources and the priority of each container, resources are allocated to each container according to a certain ratio. High-priority containers receive resource quotas first, ensuring that critical business operations are not affected by resource shortages. For example, when CPU resources are scarce, the CPU needs of the three highest-priority containers are prioritized. A reservation + dynamic adjustment mechanism is adopted to reserve basic resources (such as at least 2 CPU cores) for high-priority containers, and the remaining resources can be allocated to other containers according to priority ratios.

[0145] When a change in a container's resource requirements is detected, such as a sudden increase in the container's workload leading to a rise in CPU utilization, the resource management module dynamically adjusts the amount of resources used by the container based on the recommendations of the intelligent decision engine. If the container is running in runc, the resource management module will use cgroups technology to allocate more CPU time slices or memory space within the resource management scope of runc; if the container is running in runv, it will increase the corresponding resource quota at the virtual machine resource management level through the interaction interface with the hypervisor.

[0146] Furthermore, this method can also globally optimize and allocate resources across the entire system based on the resource usage and runtime distribution of each container. For example, if it is found that excessive resource consumption by containers running `runv` on a node is causing a decline in overall node performance, the resource management module will, in conjunction with the analysis results of the intelligent decision engine, attempt to switch some `runv` containers with lower security requirements back to `runc` runtime and reallocate resources to improve the node's resource utilization and overall performance. During dynamic resource adjustments, the resource management module adheres to the principle of fairness in resource allocation, ensuring that each container can reasonably acquire system resources while meeting its basic business needs.

[0147] It should be noted that the resource dynamic adjustment method provided in this embodiment can flexibly and reasonably allocate resources in both runtime switching and resource dynamic adjustment scenarios. This resource dynamic adjustment method is particularly suitable for use after the same process environment is created in the second runtime and the state is restored according to the process state information, as well as during the system initialization and startup phase, where a certain resource quota is reserved for the container based on its initial runtime environment and resource requirements. For example, when switching from runc to runv, the newly created runv container can obtain a corresponding proportion of CPU cores, memory, and other resources according to its priority; when the container's resource requirements change, resource allocation is also dynamically increased or decreased according to priority. This strategy ensures that system resources can be used efficiently and fairly in different scenarios, significantly improving the overall system performance and stability.

[0148] Before determining the priority of each container in step S105, this embodiment further proposes a priority allocation method. Step S108 can be executed first to allocate a priority to each container. Specifically, step S108 allocates a priority to each container according to the container's task type, runtime type, and the urgency of the current workload.

[0149] First, priority is determined by comprehensively considering multiple factors, including the container's task type, runtime type, and the urgency of the current workload. Common criteria include:

[0150] Task type: Containers for critical business tasks such as financial transactions and real-time communication have higher priority than non-core tasks such as log analysis;

[0151] SLA requirement: Latency-sensitive containers (such as API services) should be prioritized over batch tasks;

[0152] Security level: Containers that handle sensitive data (such as user privacy information) have a higher priority than containers that handle ordinary data.

[0153] For example, runv containers that handle real-time financial transactions are assigned a higher priority due to the timeliness and importance of their business; while runc containers that handle some backend data processing are assigned a relatively lower priority.

[0154] This priority allocation method integrates task type, runtime type, and workload urgency to form a multi-dimensional dynamic priority system, offering the following technical advantages: From a task type perspective, priorities can be differentiated based on business importance; for example, financial transaction tasks, involving sensitive operations, receive higher priority to ensure the supply of critical business resources. Regarding runtime type, priorities are allocated based on the resource requirements and security levels of different runtimes; for instance, high-isolation containers using `runv`, which handle sensitive data, have higher priority than ordinary `runc` containers. Combined with workload urgency, it can dynamically respond to sudden business demands; for example, during e-commerce promotions, order processing containers experience a surge in load, increasing their urgency and automatically raising their priority to obtain more resources. This multi-dimensional allocation method breaks through the limitations of traditional single-dimensional priority settings, achieving precise matching between priorities and the actual needs of containers. It ensures priority resource supply for critical tasks and high-security containers while dynamically adjusting to cope with load fluctuations, improving the flexibility of system resource scheduling and overall service quality.

[0155] Example 9:

[0156] Further reference Figure 2 The diagram illustrates an exemplary structural block diagram of an intelligent container scheduling device according to an embodiment of the present application, which mainly includes: a workload monitoring module, a machine learning model, a rule engine, and a runtime switching module;

[0157] The workload monitoring module is used to monitor the container's running status, collect real-time running data of the container, and input the running data into the machine learning model.

[0158] Machine learning models are used to perform load characteristic analysis and resource demand prediction based on runtime data, and generate load characteristic and resource demand analysis results to be input into the rule engine.

[0159] The rules engine is used to match corresponding runtime switching rules based on load characteristics and resource demand analysis results, and generate switching decision inputs to the runtime switching module.

[0160] Machine learning models and rule engines together constitute an intelligent decision-making engine. The machine learning model can employ a deep neural network structure combining Long Short-Term Memory (LSTM) networks and Multilayer Perceptrons (MLPs). LSTMs focus on processing time-series resource usage data, accurately capturing trends in resource demand over time by learning from historical data; for example, it can predict CPU demand for the next 10 minutes based on CPU usage data from the past hour. MLPs, on the other hand, handle non-time-series data, such as task type identifiers and security risk indicators, accurately determining the nature and security level of workloads through feature extraction and classification.

[0161] The rule engine is specifically designed to predefine a series of complex and sophisticated runtime switching rules based on in-depth analysis of various business scenarios. By matching the prediction results output by the machine learning model with the rules of the rule engine in real time, it makes accurate runtime switching decisions. Compared with traditional decision-making methods that simply rely on rules or simple machine learning algorithms, it has higher accuracy and flexibility and can better cope with dynamic and ever-changing container operating environments.

[0162] The runtime switching module is used to execute switching decisions and perform type switching of the container runtime during container operation.

[0163] In one embodiment, the intelligent container scheduling device may further include a resource management module, which continuously monitors the resource usage of containers and the overall resource load of the system. When a change in the resource requirements of a container is detected, the resource allocation of that container is dynamically adjusted based on the recommendations of the intelligent decision engine. Specifically, if the container is running in runc, the resource management module can utilize cgroups technology to allocate more CPU time slices or memory space within the resource management scope of runc; if the container is running in runv, it can increase the corresponding resource quota at the virtual machine resource management level through the interaction interface with the hypervisor.

[0164] Simultaneously, the resource management module can also be used to globally optimize and allocate resources across the entire system based on the resource usage and runtime distribution of each container. For example, if it is found that excessive resource consumption by containers running `runv` on a node is causing a decline in overall node performance, the resource management module will, in conjunction with the analysis results of the intelligent decision engine, attempt to switch some `runv` containers with lower security requirements back to `runc` runtime and reallocate resources to improve the node's resource utilization and overall performance. During dynamic resource adjustments, the resource management module adheres to the principle of fairness in resource allocation, ensuring that each container can reasonably acquire system resources while meeting its basic business needs.

[0165] This embodiment constructs a highly integrated system architecture, where the workload monitoring module, intelligent decision engine, runtime switching module, resource management module, and container runtime environment collaborate closely. Each module can interact with data through efficient data transmission protocols (such as ZeroMQ), forming an organic whole. From the workload monitoring module collecting data in real time, to the intelligent decision engine analyzing and making decisions, to the runtime switching module executing switching operations, and the resource management module dynamically adjusting resource allocation, the entire process is smooth and efficient, achieving intelligent, automated, and refined management of container scheduling. This integrated architecture design not only improves system performance but also enhances system scalability and maintainability, providing a completely new design approach for the container scheduling field.

[0166] It should be understood that the units described in the above-mentioned device are related to the reference. Figure 1 The steps in the described method correspond to each other. Therefore, the operations and features described above for the method also apply to the device and the units contained therein, and will not be repeated here. The device can be pre-implemented in the server's browser or other security applications, or it can be loaded into the server's browser or its security applications through download or other means. The corresponding units in the device can cooperate with the units in the server to implement the solutions of the embodiments of this application.

[0167] The division of the units mentioned in the detailed description above is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0168] It should be noted that for details not disclosed in the data balancing device of this application embodiment, please refer to the details disclosed in the above embodiments of this application, which will not be repeated here.

[0169] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0170] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not, in certain circumstances, constitute a limitation on the unit or module itself.

[0171] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A smart container scheduling method, characterized in that, include: Monitor the container's operating status and collect real-time operating data. The operational data is input into a machine learning model, which performs load characteristic analysis and resource demand prediction based on the operational data, and generates load characteristic and resource demand analysis results. Based on the load characteristics and resource requirement analysis results, match the corresponding runtime switching rules to generate a switching decision; The switching decision is executed to switch the container runtime type during container operation.

2. The method as described in claim 1, characterized in that, The monitoring of the container's operating status and the collection of real-time operating data include: Assign a hash value to each container to be monitored, and store the container's identification information and the corresponding monitoring task in a hash table; During each polling, the monitoring task corresponding to the hash value of the target container is located from the hash table using a hash function; Execute the monitoring tasks corresponding to each target container and collect real-time operational data generated during the execution of the monitoring tasks.

3. The method as described in claim 2, characterized in that, The real-time operational data collected during the execution of the monitoring task includes: Collect resource usage data and network traffic of the target container during the execution of the monitoring task; The resource usage data and the network traffic are used as the real-time operating data.

4. The method as described in claim 3, characterized in that, Also includes: Inter-process communication is used to obtain process interaction data, and system call sequences are analyzed based on the process interaction data to obtain behavioral patterns; Parse the startup metadata of the target container to obtain the task type identifier; By combining the behavioral patterns and the task type identifier, the sensitivity and security requirements of the current task of the target container are determined as task characteristics; The phrase "using the resource usage data and the network traffic as the real-time operating data" specifically means: using the resource usage data, the network traffic, and the task characteristics as the real-time operating data.

5. The method as described in claim 1, characterized in that, The monitoring of container operating status and the collection of real-time container operating data include: when the system starts, collecting the initial workload data of the container as initial operating data.

6. The method as described in claim 1, characterized in that, The execution of the switching decision, which involves switching the container runtime type during container operation, includes: Set the current container runtime as the first runtime, the switched container runtime as the second runtime, and pause all processes within the container. The second runtime is started, and a new container instance matching the original container configuration is created; Mount the container incremental file of the first runtime to the container file system corresponding to the second runtime. The network configuration information of the first runtime is parsed, and the network configuration information is converted into a new format and written into the network configuration file of the second runtime. The process state information of the first runtime is obtained, and the state is restored according to the process state information after the same process environment is created in the second runtime.

7. The method as described in claim 1, characterized in that, The machine learning model is a hybrid model that integrates long short-term memory networks and multilayer perceptrons; The Long Short-Term Memory (LSTM) network is used to process time-series data, while the Multilayer Perceptron (MLP) is used to process non-time-series data.

8. The method according to any one of claims 1 to 7, characterized in that, Also includes: Determine the priority of each container; Obtain the usage status of each resource in the system and determine the total amount of resources that can be allocated at present; Based on the total amount of resources and the priority of each container, dynamic resource allocation is performed for each container.

9. The method as described in claim 8, characterized in that, Before determining the priority of each container, the following is also included: Each container is assigned a priority based on its task type, runtime type, and the urgency of the current workload.

10. A smart container scheduling device, characterized in that, include: The workload monitoring module is used to monitor the container's running status, collect real-time running data of the container, and input the running data into the machine learning model; The machine learning model is used to perform load characteristic analysis and resource demand prediction based on the runtime data, and generate load characteristic and resource demand analysis results to be input into the rule engine. The rule engine is used to match the corresponding runtime switching rules based on the load characteristics and resource demand analysis results, and generate switching decision inputs to the runtime switching module. The runtime switching module is used to execute the switching decision and switch the container runtime type during container operation.

Images