Dynamic containerization deployment device and method based on runtime feature perception

Abstract

The invention belongs to the technical field of cloud computing and containerized deployment, and provides a dynamic containerized deployment device and method based on feature perception during operation, and the technical scheme is as follows: obtaining multi-dimensional dynamic feature data of a container and an operation environment thereof; receiving multi-dimensional dynamic feature data of the container and the operating environment thereof, performing resource prediction based on the multi-dimensional dynamic feature data to obtain a dynamic resource demand prediction vector, judging whether a fault occurs or not based on a constructed fault judgment function, and generating a fault self-healing strategy when the fault occurs; generating an environment deployment optimization decision scheme in combination with the dynamic resource demand prediction vector and the established constraint optimization model; dynamically deploying the container based on the dynamic resource demand prediction vector, a fault self-healing strategy and an environment deployment optimization decision scheme; and constructing an adaptation protocol of container arrangement and heterogeneous hardware facilities, and carrying out data interaction based on the adaptation protocol. And the resource utilization rate, the fault recovery speed and the heterogeneous hardware performance are effectively improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of cloud computing and containerized deployment, and in particular to a dynamic containerized deployment device and method based on runtime feature perception. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] In the field of cloud computing, containerization technology is at the core of cloud-native application deployment. Current technological development focuses on improving the intelligence of resource scheduling (such as using models to predict demand), exploring cloud-edge collaborative deployment (sinking services to the edge to reduce latency), and better adapting to high-performance hardware (such as high-speed networks and AI accelerator cards) to improve efficiency.

[0004] However, existing technologies suffer from significant shortcomings. The primary issue is a disconnect between resource allocation and actual runtime characteristics. Most solutions rely on historical data for predictions, making them ineffective in handling sudden or unforeseen load fluctuations (such as transient peaks or surges in computing demand). The root cause is that prediction models often use fixed weights and cannot dynamically adjust to real-time factors such as I / O load and network conditions during container operation, resulting in insufficient or wasted resource allocation. Secondly, fault recovery is inefficient. For critical events such as availability zone failures, existing recovery processes often require multiple manual steps (modifying service status, adjusting load balancing, and rerouting traffic) and lack automated coordination mechanisms, resulting in long recovery times and impacting business continuity. Third, support for heterogeneous hardware environments is insufficient. With the prevalence of high-speed network technology and specialized hardware such as AI accelerator cards, existing container orchestration systems fail to effectively incorporate the real-time status and performance data of these devices into deployment decisions. The data disconnect between the container orchestration layer and the underlying hardware monitoring layer results in underutilized hardware capabilities and limited performance in critical scenarios such as high-performance computing and low-latency networks. Finally, container image deployment efficiency is low. Traditional monolithic images are bulky, and each update requires transferring the entire image, which consumes a lot of time and bandwidth and becomes a deployment bottleneck. The root cause is that the runtime environment and the application are not separated.

[0005] The core bottleneck of current containerized deployment technology lies in the lack of a closed-loop mechanism for sensing, analyzing, and dynamically deciding on container runtime characteristics (real-time resource load, network status, and hardware performance). Existing solutions often focus on local optimization, failing to build a full-stack, real-time perception system that covers the container application layer, microservices layer, and underlying hardware resources. This disconnect between "static strategies" and the "dynamic environment" leads to low resource efficiency, slow fault recovery, and suboptimal hardware performance. Summary of the Invention

[0006] In order to solve at least one technical problem existing in the above-mentioned background technology, the present invention provides a dynamic containerized deployment device and method based on runtime feature perception, which realizes deep perception and intelligent response to the runtime characteristics of the container, effectively improving resource utilization, fault recovery speed and heterogeneous hardware performance. In order to achieve the above object, the present invention adopts the following technical solutions: A first aspect of the present invention provides a dynamic containerized deployment device based on runtime feature awareness, comprising the following steps: The runtime feature perception module is configured to: obtain multi-dimensional dynamic feature data of the container and its operating environment; The intelligent decision-making module is configured to: receive multi-dimensional dynamic feature data of the container and its operating environment, perform resource prediction based on the multi-dimensional dynamic feature data to obtain a dynamic resource demand prediction vector, determine whether a fault has occurred based on the constructed fault determination function, and generate a fault self-healing strategy in the event of a fault; and generate an environment deployment optimization decision plan by combining the dynamic resource demand prediction vector with the established constraint optimization model; The dynamic deployment execution module is configured to dynamically deploy containers based on dynamic resource demand prediction vectors, fault self-healing strategies, and environment deployment optimization decision-making schemes. The heterogeneous hardware adaptation module is configured to: build an adaptation protocol for container orchestration and heterogeneous hardware facilities, and provide a data interaction interface for the intelligent decision-making module, the dynamic deployment execution module, and the dynamic deployment execution module based on the adaptation protocol.

[0007] Furthermore, in the runtime feature perception module, the multi-dimensional dynamic feature data of the container and its operating environment include resource load indicators, network status information and hardware dependency characteristics, among which the resource load indicators include CPU utilization ; Memory working set size and page fault frequency ;Disk read and write throughput and operating frequency ; and network bandwidth utilization , end-to-end delay , packet loss rate ; Network status information including inter-container communication latency , service endpoint health status and network topology status change events ; Hardware dependency features include GPU / NPU compute core utilization and video memory usage ;Effective bandwidth of RDMA devices and congestion index ; and the read and write latency of storage devices .

[0008] Furthermore, the device further includes a feature preprocessing module, which is configured to: preprocess the acquired multi-dimensional dynamic feature data to obtain preprocessed multi-dimensional dynamic feature data.

[0009] Furthermore, in the intelligent decision-making module, resource forecasting is performed based on multi-dimensional dynamic feature data to obtain a dynamic resource demand forecast vector, including: Based on time series model Handle steady loads, based on machine learning models Capturing nonlinear patterns based on heuristic models Based on sliding window statistics; Based on the prediction error of each model in the recent time window, combined with the current load fluctuation , network jitter intensity and hardware saturation Real-time features, dynamically calculating and assigning weights to each model; The resource demand prediction vector is obtained by weighted fusion of the model outputs based on the weights of each model.

[0010] Furthermore, in the intelligent decision module, the fault judgment function constructed is: , in, is the fault judgment function, The health status of the service endpoint. is the inter-container communication delay, is the delay threshold, For continuous determination window, This is a network topology status change event.

[0011] Furthermore, in the intelligent decision-making module, once a fault is determined to have occurred, a fault self-healing strategy is generated to eliminate the fault, including: Based on network topology Calculate the optimal migration target node set ; Generate instructions to isolate fault instances , the faulty node Specific services on Isolate it from network traffic to prevent user requests from being sent to the faulty instance. Build a new traffic routing path to point to the healthy instance , reconfigure traffic routing rules to direct requests to access the service to the load balancer of the target node set; Triggering container migration operations , schedule the failed container or Pod to the target node and restart it.

[0012] Furthermore, in the intelligent decision-making module, the objective function in the constraint optimization model is: , in, is a binary variable, if , which means that the container Deploy to nodes superior; The resource cost of deploying the container; To container Deploy to nodes Network latency on and is the weight coefficient, which is adjusted according to business dynamics; Constraints include: Constraint 1: The sum of the CPU requirements of all containers on a node cannot exceed the available CPU resources of the node; Constraint 2: If a container requires a GPU and a node does not have a GPU, the container cannot be deployed on that node. Constraint 3: A container can only be deployed on one node; Constraint 4: If two containers need to communicate frequently and are extremely sensitive to network latency, they must be deployed on the same node.

[0013] Furthermore, in the dynamic deployment execution module, the dynamic deployment of containers based on the dynamic resource demand prediction vector, the fault self-healing strategy, and the environment deployment optimization decision plan includes: Modify the resource quota of running containers online based on the resource demand prediction vector; Based on the fault recovery strategy, it automatically coordinates container migration, updates service registration status to isolate faults, and configures load balancing in the event of a fault. Based on the deployment mapping relationship, the device selection algorithm is used to determine the optimal device to complete device binding and parameter optimization configuration, as well as perform elastic scaling operations.

[0014] Furthermore, in the heterogeneous hardware adaptation module, the adaptation protocol is used to provide a data interaction interface for the intelligent decision module, the dynamic deployment execution module, and the dynamic deployment execution module, including: Unify the hardware indicators corresponding to multi-dimensional runtime feature data into a standardized vector; Build a global hardware resource pool, query the availability of node hardware based on the built global hardware resource pool, and provide constraints for deployment optimization decisions; Provides atomic hardware binding and configuration capabilities for dynamic deployment of execution modules.

[0015] A second aspect of the present invention provides a dynamic containerized deployment method based on runtime feature awareness, comprising: Obtain multi-dimensional dynamic feature data of the container and its operating environment; Receive multi-dimensional dynamic feature data of the container and its operating environment, perform resource prediction based on the multi-dimensional dynamic feature data to obtain a dynamic resource demand prediction vector, determine whether a fault has occurred based on the constructed fault determination function, and generate a fault self-healing strategy when a fault occurs; combine the dynamic resource demand prediction vector with the established constraint optimization model to generate an environment deployment optimization decision plan; Dynamically deploy containers based on dynamic resource demand prediction vectors, fault self-healing strategies, and environment deployment optimization decision-making schemes; Build an adaptation protocol for container orchestration and heterogeneous hardware facilities, and conduct data interaction based on the adaptation protocol.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention introduces a dynamic weight adjustment mechanism, which enables the weights of various prediction models (such as time series models, machine learning models, and heuristic models) to adaptively change according to runtime characteristics such as load volatility, network jitter intensity, and hardware saturation collected in real time, thereby achieving accurate prediction of resource demand and dynamically adjusting the resource quota of running containers based on the predicted value, ultimately significantly reducing resource allocation errors.

[0017] 2. The present invention constructs an atomic fault self-healing execution process. It first calls the service registration center interface to immediately isolate the fault instance, then drives the container orchestration platform to migrate the faulty container to the pre-selected optimal target node, and simultaneously configures the load balancer to seamlessly switch the traffic to the healthy instance. The entire process ensures consistency through distributed transactions and ensures zero request loss through traffic mirroring technology, thereby completing fault isolation and traffic rerouting within seconds.

[0018] 3. The present invention has cross-layer hardware perception capabilities and can integrate and utilize real-time data from high-speed network equipment, GPUs and other dedicated hardware, significantly improving the performance of high-demand scenarios such as AI training and edge reasoning.

[0019] Advantages of additional aspects of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0021] Figure 1 This is an architecture diagram of a dynamic containerized deployment device based on runtime feature perception provided by an embodiment of the present invention; Figure 2 This is a flow chart of a dynamic containerized deployment method based on runtime feature perception provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0022] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0023] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention belongs.

[0024] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or combinations thereof.

[0025] There are three key problems with existing technologies: First, resource allocation relies on static or preset strategies, which are difficult to dynamically adjust according to the actual load of the container during runtime (such as CPU, memory fluctuations, and sudden peaks in network traffic), resulting in low resource utilization or service overload; second, fault recovery (such as availability zone failure) is slow to respond and relies on manual operations to switch traffic, resulting in long service interruptions; third, in heterogeneous environments such as integrated high-speed networks and edge computing, there is a lack of collaborative perception capabilities of the underlying hardware characteristics and the operating status of the container, which makes it impossible to fully utilize the hardware performance and form a bottleneck.

[0026] The core of this invention lies in building a closed-loop "perception-decision-execution" framework. The runtime feature perception module is responsible for collecting multi-dimensional dynamic feature data of the container and its operating environment in real time, including resource load metrics (such as CPU, memory, disk I / O, and network performance), network status information, and specialized hardware performance indicators. Data collection is achieved through a unified hardware access interface provided by the integrated container platform interface, operating system tools, and heterogeneous hardware adapter module.

[0027] The collected real-time data is input into the intelligent decision-making module. This module is the core of the present invention, which performs real-time analysis, evaluation and prediction based on the perception data to generate optimized deployment or adjustment decisions. Its key functions include: dynamic resource demand prediction, which significantly improves the prediction accuracy by integrating multiple algorithms and introducing a mechanism to adjust the algorithm weights in real time according to the current runtime feature state; fault detection and self-healing decision-making, when a network interruption, service unreachability or hardware failure is detected, a self-healing strategy including container migration targets, fault isolation range and new traffic paths is automatically generated within seconds; cross-environment deployment optimization decision-making, when scheduling containers, comprehensive resource demand prediction, hardware feature matching constraints, node load, network topology and service rules are used to calculate the optimal or near-optimal container placement and resource allocation plan.

[0028] The generated decision instructions are executed by the dynamic deployment execution module. This module interacts with container orchestration systems (such as Kubernetes) and infrastructure to perform the following core operations: dynamically adjust resource quotas for running containers based on predictions; automatically coordinate container migrations in the event of failures, update service registration status to isolate faults, and configure load balancing for seamless traffic switching; ensure container deployments are bound to nodes that meet specific hardware requirements and configure parameters; and perform elastic scaling operations.

[0029] The heterogeneous hardware adapter module serves as a key bridge, resolving the data disconnect between the container orchestration layer and the hardware monitoring layer. It provides unified hardware status collection, resource query, and binding configuration interfaces for the perception, decision-making, and execution modules, and utilizes a plug-in design to support flexible expansion of new hardware.

[0030] The device interacts with the underlying container platform and physical infrastructure via a standard interface. Through this closed-loop framework, the present invention achieves deep awareness and intelligent response to container runtime characteristics, effectively improving resource utilization, fault recovery speed, and heterogeneous hardware performance.

[0031] The greatest advantages of the present invention are: first, it realizes dynamic and accurate resource scheduling, integrates multiple prediction models and adaptively adjusts their weights according to real-time scenarios, significantly reducing resource allocation errors; second, it realizes millisecond-level fault self-healing, and completes fault isolation and traffic rerouting in an extremely short time (such as seconds) through deep linkage with service discovery and load balancing components; third, it has cross-layer hardware perception capabilities, and can integrate and utilize real-time data from high-speed network equipment, GPUs and other dedicated hardware, significantly improving the performance of high-demand scenarios such as AI training and edge inference.

[0032] Please refer to Figure 1 , as an embodiment of the present invention, as Figure 1 As shown, this embodiment provides a dynamic containerized deployment device based on runtime feature perception, including: The runtime feature perception module is configured to: obtain multi-dimensional dynamic feature data of the container and its operating environment; In this embodiment, in the runtime feature perception module, runtime feature data of three key dimensions are collected through a layered collaboration mechanism.

[0033] The first dimension is the resource load indicator, which uses the Container Runtime Interface (CRI) and operating system performance counters to collect the core resource consumption data of the container at a frequency of seconds, including: CPU utilization ; Memory working set size and page fault frequency ;Disk read and write throughput and operating frequency ; and network bandwidth utilization , end-to-end delay , packet loss rate .

[0034] The second dimension is network status information, which is collected based on the service mesh sidecar agent and network probes, including: inter-container communication delay , service endpoint health status and network topology status change events .

[0035] The third dimension is hardware dependency characteristics, which obtains dedicated device performance data through standardized interfaces provided by heterogeneous hardware adapter modules, such as the computing core utilization of GPU / NPU. and video memory usage ;Effective bandwidth of RDMA devices and congestion index ; and the read and write latency of storage devices .

[0036] In this embodiment, in order to achieve the goal of low-intrusion and high-real-time data collection, an innovative hierarchical fusion strategy is adopted during data collection. At the underlying infrastructure layer, Linux cgroups mechanism and eBPF program are preferentially used to directly intercept resource events in kernel state, significantly reducing the context switching overhead between user state and kernel state. At the abstract layer, a unified standard feature vector is defined and output. This vector integrates the key indicator components of all collection dimensions, effectively shielding the format heterogeneity of different underlying data sources and providing consistent input for upper-level decision-making. At the hardware adaptation layer, relying on the plug-in driver architecture of the heterogeneous hardware adaptation module, the original monitoring data of various dedicated hardware (such as GPUs and RDMA network cards from different manufacturers) is mapped and normalized into the feature vector in real time. The corresponding standard quantity.

[0037] The feature preprocessing module is configured to: preprocess the acquired multi-dimensional dynamic feature data to obtain preprocessed multi-dimensional dynamic feature data.

[0038] The collected raw feature data needs to go through a preprocessing process to improve the effectiveness of subsequent decision-making. This includes a time series aggregation module and an anomaly cleaning module. Among them, the time series aggregation module is configured to: when performing time series aggregation on the acquired multi-dimensional runtime feature data, use a sliding window model to compress high-frequency data. Its calculation formula is: , in, is the feature data after time series aggregation, is the preset sliding window size, is the time decay factor, The raw data value collected at the kth moment is the input, unprocessed high-frequency monitoring data, such as CPU utilization and memory usage collected every second; is a discrete integer representing the current time point and is used to determine the end point of the sliding window; is a discrete integer that changes continuously during the summation process, representing a specific time point within the window; is the time decay factor, which is used to control the speed of historical data weight decay. It is not a fixed value, but is based on the real-time network jitter intensity. Dynamic adjustments are made to increase the sensitivity of the aggregation results to recent sudden load changes.

[0039] The anomaly cleaning module is configured to: perform anomaly cleaning on the multi-dimensional runtime feature data after time series aggregation; In this embodiment, anomaly cleaning is based on the Laida criterion to remove significant outliers, and the retained data points must meet the conditions ,in, is the characteristic component in a specific time window The mean of is the characteristic component in a specific time window The standard deviation of .

[0040] This module effectively avoids the misleading of the decision module by a single acquisition anomaly or instantaneous interference. , which will be pushed to the intelligent decision-making module in real time in the form of a high-throughput, low-latency message queue, providing a solid data foundation for dynamic decision-making.

[0041] The intelligent decision-making module is configured to: receive multi-dimensional dynamic feature data of the container and its operating environment, perform resource prediction based on the multi-dimensional dynamic feature data to obtain a dynamic resource demand prediction vector, determine whether a fault has occurred based on the constructed fault determination function, and generate a fault self-healing strategy in the event of a fault; and generate an environment deployment optimization decision plan by combining the dynamic resource demand prediction vector with the established constraint optimization model; The core of this module is to build a dynamic adaptive, multi-objective collaborative decision engine, which receives the feature vectors preprocessed by the runtime feature perception module. ,generate optimized deployment instructions through a triple innovation mechanism.

[0042] Among them, in the intelligent decision-making module, based on the pre-processed feature vector Perform resource forecasting to obtain a resource demand forecast vector; In this embodiment, in the dynamic resource demand prediction mechanism, a multi-model fusion framework is used to overcome the static prediction defects, and the time series model, machine learning model and heuristic model are run simultaneously; Based on time series model Handle steady loads, based on machine learning models (such as LSTM) to capture nonlinear patterns, based on heuristic models Based on sliding window statistics; Based on the prediction error of each model in the recent time window, combined with the current load fluctuation , network jitter intensity and hardware saturation Real-time features such as dynamic calculation and allocation of weights for each model ; The weight calculation formula is: , in, is the weight index, is the index of the summation formula, Representation Model In the recent window The prediction error within is an adaptive sensitivity coefficient that evolves in real time with runtime characteristics, such as when the load fluctuates. Greater than threshold When, increase To strengthen the weight of low error models.

[0043] The weights assigned to the time series model, machine learning model, and heuristic model are calculated by this formula respectively. 、 and ; Then the weighted fusion of the model output is used to obtain the resource demand prediction vector : , The core innovation of this step lies in its dynamic weight adjustment function, which is based on the prediction error of each model in the recent time window and the current load volatility. , network jitter intensity and hardware saturation The algorithm dynamically calculates and assigns weights to each model based on real-time features such as the CPU, memory, and GPU requirements over the next period of time, significantly improving prediction accuracy in dynamically changing scenarios.

[0044] The intelligent decision-making module determines whether a fault has occurred based on the constructed fault judgment function and generates a fault self-recovery strategy when a fault occurs. Specifically, the strategy includes: In this embodiment, in the fault detection and self-healing decision-making mechanism, a second-level response is achieved based on the joint analysis of multi-source features. The fault judgment function is defined as: , in, is the fault judgment function, The health status of the service endpoint. is the inter-container communication delay, is the delay threshold, For continuous determination window, This event indicates a network topology status change.

[0045] In this embodiment, the basis for determining whether a fault occurs according to the fault determination function is that a function value of 1 indicates that a fault occurs, and a function value of 0 indicates that no fault occurs.

[0046] Furthermore, once a fault is determined to have occurred, a self-healing strategy is generated to eliminate the fault, including the following steps: Based on network topology Calculate the optimal migration target node set, expressed as: , in, For nodes, To calculate the number of network hops from the candidate node to the network core or failure point, the node with the least number of hops is selected to ensure the lowest network latency and the best performance after migration; The current load of the node (such as CPU and memory usage) must be lower than the threshold , to ensure that there are sufficient resources to receive the new load and avoid causing new failures immediately after the migration.

[0047] Generate instructions to isolate fault instances , the faulty node Specific services on Isolate it from network traffic to prevent user requests from being sent to the faulty instance. Build a new traffic routing path to point to the healthy instance , reconfigure traffic routing rules to direct requests to access the service to the load balancer of the target node set; Triggering container migration operations , schedule the failed container or Pod to the target node and restart it.

[0048] The entire closed-loop process from fault diagnosis to strategy generation is completed in a short time without the need for human intervention.

[0049] In the intelligent decision-making module, the dynamic resource demand prediction vector and the established constraint optimization model are combined to generate an environment deployment optimization decision solution, specifically including: The constrained optimization model aims to minimize the overall cost and imposes a series of key constraints: it explicitly includes hardware feature matching requirements, such as requiring that GPU-dependent tasks must be deployed on nodes with GPUs; it introduces a dynamic margin factor, which is dynamically adjusted according to the hardware saturation of the target node. The higher the saturation, the greater the reserved resource safety margin, effectively preventing node overload; and the cost weight can be dynamically adjusted according to the service level agreement of the business.

[0050] The objective function is: , in, is a binary variable, if , which means that the container Deploy to nodes superior; The resource cost of deploying the container; To container Deploy to nodes Network latency on and The weight coefficient is adjusted according to the business dynamics. For example, for services that are sensitive to delay, the system will automatically increase , making the model more inclined to choose a low-latency deployment solution; Constraints include: Constraint 1: The sum of the CPU requirements of all containers on a node cannot exceed the available CPU resources of the node, expressed as: , in, is the dynamic headroom factor, which varies with the node hardware saturation Increase and enhance, For container c The amount of CPU resources required, For nodes n All CPU resources; Constraint 2: If a container requires a GPU and a node does not have a GPU, then the container cannot be deployed on the node, expressed as: , in, Represents a container Required GPU, Node n has GPU resources; Constraint 3: A container can be deployed on only one node, expressed as: , in, For the complete set of containers; Constraint 4: If two containers need to communicate frequently and are extremely sensitive to network latency, they must be deployed on the same node, as follows: , in, is an affinity function that determines whether two containers need to communicate frequently. To container Deploy to nodes superior, To container Deploy to nodes superior.

[0051] In the cross-environment deployment optimization mechanism, a hardware-aware scheduling solution is generated by establishing a constraint optimization model. The model ultimately outputs the optimal or near-optimal mapping relationship between containers and nodes, providing a clear basis for performing precise scheduling.

[0052] The dynamic deployment execution module is configured to dynamically deploy containers based on dynamic resource demand prediction vectors, fault self-healing strategies, and environment deployment optimization decision-making schemes. The dynamic deployment execution module is the operational execution terminal of this invention, responsible for converting instructions from the intelligent decision-making module into specific deployment operations and applying them to the application layer. This module receives resource demand prediction vectors, fault recovery strategies, and deployment mappings, and implements precise resource management and service scheduling through the container orchestration platform interface.

[0053] The specific steps include: Modify the resource quota of the running container online based on the resource demand prediction vector; expressed as: , in, For the new resource quota, is the smoothing factor, which fluctuates with the load Dynamic changes, prediction vector, The current resource quota; Kernel-level resource control enables online adjustments without restarting, and ensures that total resource consumption does not exceed the product of node capacity and safety margin.

[0054] Based on the fault recovery strategy, an atomic operation protocol is used to recover from the fault; In this embodiment, the fault recovery process uses an atomic operation protocol to complete the three stages of service isolation, container migration, and traffic rerouting in a short period of time. Traffic mirroring is enabled to ensure zero request loss, and target node selection follows network topology and load constraints.

[0055] Based on the deployment mapping relationship, the device selection algorithm is used to determine the optimal device to complete device binding and parameter optimization configuration. The calculation formula is: , in, Select the device for the target, is the available video memory, is the maximum video memory, To indicate the degree of hardware resource fragmentation, is the load balancing weight coefficient, is the current utilization rate of the equipment, is the average node utilization; Generate instructions for executing resource allocation based on the results of the intelligent decision-making module; In this embodiment, elastic scaling is used to perform horizontal scaling of the number of container replicas or vertical scaling of single container resources based on decision instructions.

[0056] Horizontal scaling uses a specific algorithm to calculate the new number of replicas. This algorithm takes into account predicted resource demand, available node capacity, and preset utilization thresholds. The calculated results are applied in real time by the container orchestration system's autoscaling controller. Vertical scaling reuses the interface of the resource dynamic adjustment submodule to directly modify the resource quota limits of running containers based on predicted values. This is suitable for services that require persistent state.

[0057] The heterogeneous hardware adaptation module is configured to: build an adaptation protocol for container orchestration and heterogeneous hardware facilities, and provide a data interaction interface for the intelligent decision-making module, the dynamic deployment execution module, and the dynamic deployment execution module based on the adaptation protocol.

[0058] The heterogeneous hardware adaptation module is the hardware abstraction hub of this invention, characterized by the construction of a unified, scalable, and high-performance hardware access layer. This module achieves deep collaboration between the container orchestration system and heterogeneous hardware facilities through standardized data mapping, plug-in driver architecture, and dynamic resource management. The specific technical solution is as follows: The specific steps include: Unify the hardware indicators corresponding to multi-dimensional runtime feature data into a standardized vector; In this embodiment, cross-vendor hardware data is standardized and collected by defining device-independent standardized metrics: hardware utilization is calculated as the ratio of effective working time to total time; the congestion index is defined as the ratio of current queue depth to maximum queue depth; and the 99th percentile latency is used instead of the average to accurately reflect hardware jitter. Dedicated plug-ins are designed for different types of hardware: the GPU plug-in uses the NVML library to parse core utilization and video memory usage and map them to standardized ratios; the RDMA plug-in uses libibverbs to read queue status and calculate a normalized congestion index; and the storage plug-in uses SPDK to obtain high-precision latency data for NVMe storage.

[0059] This design unifies heterogeneous indicators such as GPU memory pressure and RDMA congestion status into standardized vectors, solving the problem of hardware monitoring data fragmentation.

[0060] Build a global hardware resource pool, query the availability of node hardware based on the built global hardware resource pool, and provide constraints for deployment optimization decisions; In this embodiment, building a global hardware resource pool specifically involves automatically registering hardware capability information (such as GPU model, RDMA bandwidth, NVMe IOPS, etc.) when a node starts to form a global hardware resource pool.

[0061] The decision module can query the node hardware availability in real time through a standardized API, and the hardware resource catalog continuously updates hardware status changes (such as device failures or new additions), providing accurate constraints for deployment optimization decisions.

[0062] Provides atomic hardware binding and configuration capabilities for dynamic deployment of execution modules.

[0063] After the dynamic deployment execution module selects a device, it generates specific binding instructions: It declares hardware resource requirements (such as specifying a GPU device index) through the container orchestration system's device plugin interface; automatically injects optimized underlying driver parameters (such as setting RDMA queue depth and enabling compression); and configures pass-through access policies for storage devices. All configuration is implemented through declarative templates, and a built-in parameter optimization library automatically matches best practices based on hardware models.

[0064] Please refer to Figure 2As an embodiment of the present invention, a dynamic containerized deployment method based on runtime feature awareness is disclosed, including: Obtain multi-dimensional dynamic feature data of the container and its operating environment; Receive multi-dimensional dynamic feature data of the container and its operating environment, perform resource prediction based on the multi-dimensional dynamic feature data to obtain a dynamic resource demand prediction vector, determine whether a fault has occurred based on the constructed fault determination function, and generate a fault self-healing strategy when a fault occurs; combine the dynamic resource demand prediction vector with the established constraint optimization model to generate an environment deployment optimization decision plan; Dynamically deploy containers based on dynamic resource demand prediction vectors, fault self-healing strategies, and environment deployment optimization decision-making schemes; Build an adaptation protocol for container orchestration and heterogeneous hardware facilities, and conduct data interaction based on the adaptation protocol.

[0065] It should be noted that the specific implementation method of the dynamic containerized deployment method based on runtime feature perception in an embodiment of the present invention is similar to the specific implementation method of the dynamic containerized deployment device based on runtime feature perception in an embodiment of the present invention. Please refer to the description of the method part for details. In order to reduce redundancy, it will not be repeated here.

[0066] The foregoing description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be within the scope of protection of the present invention.

Claims

1. A dynamic containerized deployment device based on runtime feature perception, characterized in that: include: The runtime feature perception module is configured to: obtain multi-dimensional dynamic feature data of the container and its operating environment; The intelligent decision-making module is configured to: receive multi-dimensional dynamic feature data of the container and its operating environment, perform resource prediction based on the multi-dimensional dynamic feature data to obtain a dynamic resource demand prediction vector, determine whether a fault has occurred based on the constructed fault determination function, and generate a fault self-recovery strategy in the event of a fault; Combine the dynamic resource demand prediction vector and the established constraint optimization model to generate an environment deployment optimization decision plan; The dynamic deployment execution module is configured to dynamically deploy containers based on dynamic resource demand prediction vectors, fault self-healing strategies, and environment deployment optimization decision-making schemes. The heterogeneous hardware adaptation module is configured to: build an adaptation protocol for container orchestration and heterogeneous hardware facilities, and provide a data interaction interface for the intelligent decision-making module, the dynamic deployment execution module, and the dynamic deployment execution module based on the adaptation protocol.

2. The dynamic containerized deployment device based on runtime feature perception according to claim 1, characterized in that: In the runtime feature perception module, the multi-dimensional dynamic feature data of the container and its operating environment include resource load indicators, network status information and hardware dependency characteristics. Among them, the resource load indicators include CPU utilization ; Memory working set size and page fault frequency ;Disk read and write throughput and operating frequency ; and network bandwidth utilization , end-to-end delay , packet loss rate ; Network status information including inter-container communication latency , service endpoint health status and network topology status change events ; Hardware dependency features include GPU / NPU compute core utilization and video memory usage ;Effective bandwidth of RDMA devices and congestion index ; and the read and write latency of storage devices .

3. The dynamic containerized deployment device based on runtime feature perception according to claim 1, characterized in that: The device further includes a feature preprocessing module configured to preprocess the acquired multi-dimensional dynamic feature data to obtain preprocessed multi-dimensional dynamic feature data.

4. The dynamic containerized deployment device based on runtime feature perception according to claim 1, characterized in that: In the intelligent decision-making module, resource forecasting is performed based on multi-dimensional dynamic feature data to obtain a dynamic resource demand forecast vector, including: Based on time series model Handle steady loads, based on machine learning models Capturing nonlinear patterns based on heuristic models Based on sliding window statistics; Based on the prediction error of each model in the recent time window, combined with the current load fluctuation , network jitter intensity and hardware saturation Real-time features, dynamically calculating and assigning weights to each model; The resource demand prediction vector is obtained by weighted fusion of the model outputs based on the weights of each model.

5. The dynamic containerized deployment device based on runtime feature perception according to claim 1, characterized in that: In the intelligent decision module, the fault judgment function constructed is: ， in, is the fault judgment function, The health status of the service endpoint. is the inter-container communication delay, is the delay threshold, For continuous determination window, This event indicates a network topology status change.

6. The dynamic containerized deployment device based on runtime feature perception according to claim 1, characterized in that: In the intelligent decision-making module, once a fault is determined to have occurred, a self-healing strategy is generated to eliminate the fault, including: Based on network topology Calculate the optimal migration target node set ; Generate instructions to isolate fault instances , the faulty node Specific services on Isolate it from network traffic to prevent user requests from being sent to the faulty instance. Build a new traffic routing path to point to the healthy instance , reconfigure traffic routing rules to direct requests to access the service to the load balancer of the target node set; Triggering container migration operations , schedule the failed container or Pod to the target node and restart it.

7. The dynamic containerized deployment device based on runtime feature perception according to claim 1, characterized in that: In the intelligent decision-making module, the objective function in the constrained optimization model is: ， in, is a binary variable, if , which means that the container Deploy to nodes superior; The resource cost of deploying the container; To container Deploy to nodes Network latency on and is the weight coefficient, which is adjusted according to business dynamics; Constraints include: Constraint 1: The sum of the CPU requirements of all containers on a node cannot exceed the available CPU resources of the node; Constraint 2: If a container requires a GPU and a node does not have a GPU, the container cannot be deployed on that node. Constraint 3: A container can only be deployed on one node; Constraint 4: If two containers need to communicate frequently and are extremely sensitive to network latency, they must be deployed on the same node.

8. The dynamic containerized deployment device based on runtime feature perception according to claim 1, characterized in that: In the dynamic deployment execution module, the dynamic deployment of containers based on the dynamic resource demand prediction vector, fault self-healing strategy, and environment deployment optimization decision plan includes: Modify the resource quota of running containers online based on the resource demand prediction vector; Based on the fault recovery strategy, it automatically coordinates container migration, updates service registration status to isolate faults, and configures load balancing in the event of a fault. Based on the deployment mapping relationship, the device selection algorithm is used to determine the optimal device to complete device binding and parameter optimization configuration, as well as perform elastic scaling operations.

9. The dynamic containerized deployment device based on runtime feature perception according to claim 1, characterized in that: In the heterogeneous hardware adaptation module, the adaptation protocol provides a data interaction interface for the intelligent decision module, the dynamic deployment execution module, and the dynamic deployment execution module, including: Unify the hardware indicators corresponding to multi-dimensional runtime feature data into a standardized vector; Build a global hardware resource pool, query the availability of node hardware based on the built global hardware resource pool, and provide constraints for deployment optimization decisions; Provides atomic hardware binding and configuration capabilities for dynamic deployment of execution modules.

10. A dynamic containerized deployment method based on runtime feature perception, characterized in that: include: Obtain multi-dimensional dynamic feature data of the container and its operating environment; Receive multi-dimensional dynamic feature data of the container and its operating environment, perform resource prediction based on the multi-dimensional dynamic feature data to obtain a dynamic resource demand prediction vector, determine whether a fault has occurred based on the constructed fault judgment function, and generate a fault self-healing strategy when a fault occurs; Combining the dynamic resource demand prediction vector and the established constraint optimization model to generate an environment for deploying optimization decision solutions; Dynamically deploy containers based on dynamic resource demand prediction vectors, fault self-healing strategies, and environment deployment optimization decision-making schemes; Build an adaptation protocol for container orchestration and heterogeneous hardware facilities, and conduct data interaction based on the adaptation protocol.

Images