Industrial cloud platform computing resource dynamic scheduling method and system combined with deep learning

Abstract

The application provides a kind of industrial cloud platform computing resource dynamic scheduling method and system combined with deep learning, it is related to industrial cloud platform technical field, first, the real-time request queue parameter set and real-time container resource parameter set of containerized application instance set in industrial cloud platform are acquired, then correlation coupling analysis is carried out to generate service quality sensitivity descriptor set, then call deep learning request flow prediction network to identify request flow evolution mode, generate predicted request timing distribution set in future prediction time window, according to the node available resource parameter set of the two sets above Resource reservation dynamic programming is carried out to physical computing node cluster, generate dynamic binding relationship mapping set, finally, based on the dynamic binding relationship mapping set Migration scheduling instruction sequence is generated and issued to container orchestration scheduler, to realize the dynamic accurate scheduling of computing resource.

Description

Technical Field

[0001] This application relates to the field of industrial cloud platform technology, and more specifically, to a method and system for dynamic scheduling of computing resources in industrial cloud platforms that combines deep learning. Background Technology

[0002] In the development of industrial cloud platforms, the dynamic scheduling of computing resources is a key factor in ensuring the platform's efficient and stable operation. With the acceleration of digital transformation in the industrial sector, the number of containerized application instances hosted on industrial cloud platforms has increased dramatically, and the types of applications have become increasingly diversified. This has led to highly complex and dynamically changing demands for computing resources.

[0003] Traditional computing resource scheduling methods often rely on fixed rules or simple threshold judgments. For example, some methods determine whether to allocate resources or migrate application instances based solely on current container resource usage, such as CPU and memory utilization. However, these methods have significant limitations. They do not adequately consider the quality of service requirements of containerized application instances. Different applications have vastly different tolerances for request response latency and varying capabilities to handle sudden surges in requests. Ignoring these factors can lead to performance degradation in some latency-sensitive applications due to inappropriate resource allocation, disrupting normal industrial production.

[0004] Meanwhile, traditional methods lack effective prediction of future request traffic. Request traffic in industrial production often exhibits certain regularities and trends, but due to the lack of scientific prediction methods, scheduling systems can only respond passively after requests arrive, making it difficult to reserve and plan resources in advance. This can easily lead to resource waste or shortages, failing to meet the high efficiency and accuracy requirements of industrial cloud platforms for dynamic scheduling of computing resources. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a method and system for dynamic scheduling of computing resources in industrial cloud platforms that combines deep learning.

[0006] According to a first aspect of this application, a method for dynamic scheduling of computing resources in an industrial cloud platform combining deep learning is provided, the method comprising: Obtain the real-time request queue parameter set and the real-time container resource parameter set of the containerized application instance set in the industrial cloud platform. The real-time request queue parameter set includes the request waiting queue length parameter and the instantaneous value of the request arrival rate of each containerized application instance at the time of scheduling trigger. The real-time container resource parameter set includes the container CPU usage parameter and the container memory usage parameter of each containerized application instance at the time of scheduling trigger. A correlation coupling analysis is performed on the real-time request queue parameter set and the real-time container resource parameter set to generate a service quality sensitivity descriptor set for the containerized application instance set. The service quality sensitivity descriptor set includes the request response latency tolerance parameter and the request burst impact absorption capability parameter for each containerized application instance. The deep learning request traffic prediction network is invoked to identify the request traffic evolution pattern of the real-time request queue parameter set, and a predicted request time series distribution set of the containerized application instance set within the future prediction time window is generated. The predicted request time series distribution set includes the predicted parameters of the number of requests arriving at each time and the distribution parameters of the request arrival interval time for each containerized application instance within the future prediction time window. Based on the set of service quality sensitivity descriptors and the set of predicted request time-series distributions, dynamic resource reservation planning is performed on the set of available resource parameters for nodes in the physical computing node cluster to generate a dynamic binding relationship mapping set between the containerized application instance and the physical computing node. The dynamic binding relationship mapping set includes the target physical computing node identifier parameter, the target node CPU reserved share parameter, and the target node memory reserved share parameter for each containerized application instance. Based on the dynamic binding relationship mapping set, a migration scheduling instruction sequence for the containerized application instance is generated, and the migration scheduling instruction sequence is sent to the container orchestration scheduler of the industrial cloud platform. The migration scheduling instruction sequence includes the source physical computing node identifier parameter, the target physical computing node identifier parameter, and the migration execution time parameter for each containerized application instance.

[0007] According to a second aspect of this application, a dynamic scheduling system for computing resources of an industrial cloud platform incorporating deep learning is provided. The system includes a machine-readable storage medium and a processor. The machine-readable storage medium stores machine-executable instructions. When the processor executes the machine-executable instructions, the system implements the aforementioned dynamic scheduling method for computing resources of an industrial cloud platform incorporating deep learning.

[0008] Based on any of the above aspects, the technical effect of this application is as follows: By acquiring the real-time request queue parameter set and real-time container resource parameter set of containerized application instances in the industrial cloud platform, and performing correlation and coupling analysis on these sets, a service quality sensitivity descriptor set is generated. This accurately characterizes the specific service quality requirements of each containerized application instance, enabling the scheduling system to fully consider the personalized needs of applications during decision-making and effectively avoid performance issues caused by ignoring service quality differences. A deep learning request traffic prediction network is invoked to identify request traffic evolution patterns in the real-time request queue parameter set, generating a predicted request time series distribution set within the future prediction time window. This allows the scheduling system to perform dynamic resource reservation planning in advance, rationally allocating resources for physical computing nodes, improving resource utilization efficiency, and reducing cost and performance losses caused by insufficient or wasted resources. Based on the service quality sensitivity descriptor set and the predicted request time series distribution set, a dynamic binding relationship mapping set between containerized application instances and physical computing nodes is generated. Furthermore, a migration scheduling instruction sequence is generated and issued to the container orchestration scheduler, achieving dynamic and precise scheduling of computing resources. The entire approach, from data acquisition and analysis to prediction and scheduling, can adapt to the dynamic changes in computing resource demands in industrial cloud platforms, effectively improving the platform's operational efficiency and service quality. Attached Figure Description

[0009] Figure 1 A flowchart illustrating the dynamic scheduling method for industrial cloud platform computing resources combined with deep learning provided in an embodiment of this application is shown. Figure 2 This illustration shows a schematic diagram of the component structure of a deep learning-integrated industrial cloud platform computing resource dynamic scheduling system for implementing the above-described deep learning-integrated industrial cloud platform computing resource dynamic scheduling method, as provided in an embodiment of this application. Detailed Implementation

[0010] Figure 1 This paper illustrates a flowchart of a method and system for dynamic scheduling of computing resources in an industrial cloud platform that incorporates deep learning, as provided in an embodiment of this application. The detailed steps include: Step S110: Obtain the real-time request queue parameter set and the real-time container resource parameter set of the containerized application instance set in the industrial cloud platform. The real-time request queue parameter set includes the request waiting queue length parameter and the instantaneous value of the request arrival rate of each containerized application instance at the time of scheduling trigger. The real-time container resource parameter set includes the container CPU usage parameter and the container memory usage parameter of each containerized application instance at the time of scheduling trigger.

[0011] In this embodiment, the industrial cloud platform is deployed on an intelligent assembly line scenario for industrial robots, running multiple containerized application instances. For example, one containerized application instance is used to process robot motion control commands from multiple assembly stations, and its unique identifier is denoted as id_A; another containerized application instance is used to process image stream data from machine vision quality inspection cameras, and its unique identifier is denoted as id_B; and yet another containerized application instance is used to handle material traceability and data reporting tasks on the production line, and its unique identifier is denoted as id_C.

[0012] At the preset periodic scheduling trigger time t0, a query request is sent to the application programming interface of the container orchestration scheduler to obtain a list of unique identifiers of all running containerized application instances at the current time, namely id_A, id_B and id_C.

[0013] For the containerized application instance corresponding to id_A, the request waiting queue length parameter L_A of the containerized application instance at the scheduling trigger time t0 is extracted by calling the performance metric monitoring interface provided by the container orchestration scheduler. L_A is obtained by reading the request queue depth value in the runtime metrics of the containerized application instance. At the same time, the instantaneous value parameter R_A of the request arrival rate of the containerized application instance is extracted. R_A is calculated as follows: obtain the total number of requests received by the containerized application instance C_t_start and C_t_end at the start time t_start and end time t_end of the time window, respectively, and R_A = (C_t_end - C_t_start) / T_w, where T_w is the preset very short time window length.

[0014] For the containerized application instances corresponding to id_B and id_C, repeat the above operations to extract their respective L_B and L_C, as well as R_B and R_C. Associate and store id_A, id_B, and id_C with their respective L and R values ​​to form a real-time request queue parameter set.

[0015] Simultaneously, by calling the resource monitoring interface of the container orchestration scheduler, the real-time container resource parameter set for each containerized application instance is obtained in parallel. For the containerized application instance corresponding to id_A, the container CPU usage parameter P_A is extracted, which represents the CPU core computing time currently occupied by the containerized application instance. The container memory usage parameter M_A is also extracted, which represents the physical memory size currently occupied by the containerized application instance. For the containerized application instances corresponding to id_B and id_C, the above operations are repeated to extract their respective P_B and P_C, as well as M_B and M_C. id_A, id_B, and id_C are associated and stored with their respective P and M values ​​to form a real-time container resource parameter set.

[0016] During the acquisition of the aforementioned data, all collection of sensitive operational data was transmitted through a secure socket layer encrypted channel, and a role-based access control mechanism was used for authentication to ensure that only authorized calls could initiate data queries. The collected real-time request queue parameter set and real-time container resource parameter set were hashed using id_A, id_B, and id_C during storage.

[0017] Step S120: Perform correlation and coupling analysis on the real-time request queue parameter set and the real-time container resource parameter set to generate a service quality sensitivity descriptor set for the containerized application instance set. The service quality sensitivity descriptor set includes the request response latency tolerance parameter and the request burst impact absorption capability parameter for each containerized application instance.

[0018] After collecting the set of parameters for the real-time request queue and the set of parameters for the real-time container resources, perform the following processing on each containerized application instance.

[0019] Step S121: Extract the request waiting queue length parameter and the instantaneous value of the request arrival rate for each containerized application instance from the real-time request queue parameter set, and extract the container CPU usage parameter and the container memory usage parameter for each containerized application instance from the real-time container resource parameter set.

[0020] Iterate through the data structure generated in step S110, indexed by the containerized application instance identifier. For id_A, separate and extract L_A, R_A, P_A, and M_A from its corresponding data entry. For id_B and id_C, repeat the above extraction operation to obtain L_B, R_B, P_B, M_B and L_C, R_C, P_C, M_C, respectively.

[0021] Step S122: Perform correlation analysis on the request waiting queue length parameter and the container CPU usage parameter for each containerized application instance to generate the CPU resource stress parameter for each containerized application instance, and perform correlation analysis on the instantaneous value of the request arrival rate parameter and the container memory usage parameter for each containerized application instance to generate the memory resource pressure parameter for each containerized application instance.

[0022] For id_A, the CPU resource stress parameter C_A = L_A / P_A. The memory resource stress parameter U_A = R_A / M_A.

[0023] For id_B, C_B=L_B / P_B, U_B=R_B / M_B.

[0024] For id_C, C_C = L_C / P_C, U_C = R_C / M_C.

[0025] Step S123: Collect the set of request-response time series parameters that have been processed by each containerized application instance within the historical time window.

[0026] For id_A, retrieve the response time records of every request processed within a preset historical time window T_h from the log storage system of the industrial cloud platform. Arrange all the retrieved response time records in chronological order to form a request response time sequence parameter set RT_A, RT_A=[rt_A1, rt_A2, ..., rt_An], where n is the total number of requests processed within this time window.

[0027] For id_B and id_C, repeat the above collection operation to generate their respective request-response time series parameter sets RT_B and RT_C.

[0028] Step S124: Perform quantile statistical processing on the request-response time series parameter set of each containerized application instance, and extract the request-response delay boundary parameters of each containerized application instance at a preset quantile.

[0029] For id_A, all request response time parameters in its request response time series parameter set RT_A are sorted in ascending order of numerical value, resulting in the sorted sequence RT_A_sorted. Within the sorted sequence, the position corresponding to the preset quantile p is located. p is the 95th percentile, and the request response time parameter at this position is the 95th percentile request response delay boundary parameter D_A. D_A = RT_A_sorted[floor(n p)], where floor is the floor function.

[0030] For id_B and id_C, repeat the above quantile statistical processing to extract their respective request-response delay boundary parameters D_B and D_C.

[0031] Step S125: Perform correlation calculations between the request response latency boundary parameters and the CPU resource stress parameters of each containerized application instance to generate CPU resource demand gradient parameters under unit latency constraints for each containerized application instance, and perform correlation calculations between the request response latency boundary parameters and the memory resource pressure parameters of each containerized application instance to generate request burst absorption latency compensation parameters for each containerized application instance.

[0032] For id_A, the gradient parameter of CPU resource demand under the unit delay constraint is G_A=D_A. C_A. Request burst absorption delay compensation parameter B_A=D_A U_A.

[0033] For id_B, G_B = D_B C_B, B_B = D_B U_B.

[0034] For id_C, G_C=D_C C_C, B_C = D_C U_C.

[0035] Step S126: Construct a three-dimensional service quality sensitivity vector for each containerized application instance by taking the CPU resource demand gradient parameter under unit latency constraint for each containerized application instance as the first dimension parameter, the request burst absorption latency compensation parameter for each containerized application instance as the second dimension parameter, and the request response latency boundary parameter for each containerized application instance as the third dimension parameter.

[0036] For id_A, the three-dimensional service quality sensitivity vector V_A=(G_A, B_A, D_A).

[0037] For id_B, V_B=(G_B, B_B, D_B).

[0038] For id_C, V_C=(G_C, B_C, D_C).

[0039] Step S127: Normalize the three-dimensional service quality sensitivity vector of each containerized application instance to obtain the normalized service quality sensitivity vector of each containerized application instance. Then, weight and aggregate the normalization parameters in the normalized service quality sensitivity vector of each containerized application instance according to the preset weight coefficient to generate the service quality sensitivity descriptor of each containerized application instance.

[0040] For id_A, find the maximum value component M_A = max(G_A, B_A, D_A) in V_A. Normalize the quality of service sensitivity vector V_A_norm = (G_A / M_A, B_A / M_A, D_A / M_A).

[0041] Set preset weight coefficients w1, w2, and w3 for the first, second, and third components of V_A_norm, respectively. The service quality sensitivity descriptor Q_A = (w1...) (G_A / M_A))+(w2 (B_A / M_A))+(w3 (D_A / M_A)).

[0042] For id_B, M_B=max(G_B, B_B, D_B), V_B_norm=(G_B / M_B, B_B / M_B, D_B / M_B), Q_B=(w1 (G_B / M_B))+(w2 (B_B / M_B))+(w3 (D_B / M_B)).

[0043] For id_C, M_C=max(G_C, B_C, D_C), V_C_norm=(G_C / M_C, B_C / M_C, D_C / M_C), Q_C=(w1 (G_C / M_C))+(w2 (B_C / M_C))+(w3 (D_C / M_C)).

[0044] Associate id_A, id_B, and id_C with their respective Q_A, Q_B, and Q_C to form a set of service quality sensitivity descriptors.

[0045] Step S130: Call the deep learning request traffic prediction network to identify the request traffic evolution pattern of the real-time request queue parameter set, and generate a predicted request time series distribution set of the containerized application instance set within the future prediction time window. The predicted request time series distribution set includes the predicted parameters of the number of requests arriving at each time point of each containerized application instance within the future prediction time window and the distribution parameters of the request arrival interval time.

[0046] After generating the set of service quality sensitivity descriptors, deep learning prediction processing is performed on the data in the set of real-time request queue parameters.

[0047] Step S131: Combine the request waiting queue length parameter and the instantaneous value parameter of the request arrival rate of each containerized application instance in chronological order to construct the current request status feature vector of each containerized application instance.

[0048] For id_A, the current request state feature vector X_A = [L_A, R_A].

[0049] For id_B, X_B = [L_B, R_B].

[0050] For id_C, X_C = [L_C, R_C].

[0051] Step S132: Collect the request state feature vector of each containerized application instance at multiple consecutive historical moments, and construct the historical request state feature sequence of each containerized application instance.

[0052] For id_A, query the request waiting queue length and instantaneous request arrival rate parameters of the containerized application instance from the historical data storage of the industrial cloud platform for the past K consecutive historical scheduling trigger times. For each historical scheduling trigger time t_i, construct a request state feature vector X_A_i=[L_A_i, R_A_i]. Arrange the request state feature vectors of all K historical times in chronological order to form the historical request state feature sequence Seq_A=[X_A_1, X_A_2, ..., X_A_K].

[0053] For id_B and id_C, repeat the above collection and construction operations to generate their respective historical request state feature sequences Seq_B and Seq_C.

[0054] Step S133: Input the historical request state feature sequence of each containerized application instance into the encoder module of the deep learning request traffic prediction network, and extract local temporal patterns from the historical request state feature sequence through the convolutional layer of the encoder module to generate multiple local request pattern feature maps for each containerized application instance.

[0055] The deep learning request traffic prediction network consists of an encoder module and a decoder module. The encoder module is composed of convolutional layers and self-attention layers.

[0056] For id_A, its historical request state feature sequence Seq_A is input into the convolutional layer of the encoder module. This convolutional layer contains F convolutional kernels, each with a preset convolutional window size s. Each convolutional kernel performs a sliding convolution operation along the time dimension of Seq_A. For the f-th convolutional kernel, at each sliding position j, the weight parameter W_f of the convolutional kernel is multiplied element-wise with the s historical request state feature vectors within the covered time window, and then summed to obtain a convolutional response value c_f_j at that position. The convolutional response values ​​at all sliding positions constitute a one-dimensional local request pattern feature map M_f=[c_f_1, c_f_2, ..., c_f_(K-s+1)]. The local request pattern feature maps generated by all F convolutional kernels together form a set of multiple local request pattern feature maps Map_A=[M_1, M_2, ..., M_F].

[0057] For id_B and id_C, repeat the above convolution operation to generate their respective sets of multiple local request pattern feature maps Map_B and Map_C.

[0058] Step S134: Input the multiple local request pattern feature maps of each containerized application instance into the self-attention layer of the encoder module, and calculate the global temporal dependency weight matrix between the multiple local request pattern feature maps through the self-attention layer.

[0059] For id_A, its set of multiple local request pattern feature maps Map_A is input into the self-attention layer. The self-attention layer treats each local request pattern feature map M_f as a feature vector and generates a query vector Q_f, a key vector K_f, and a value vector V_f for each feature vector. Q_f = M_f W_Q, K_f=M_f W_K, V_f=M_f W_V, where W_Q, W_K, and W_V are three different weight matrices.

[0060] For any two local request pattern feature maps corresponding to feature vectors M_f and M_g, the attention score a_fg = (Q_f·K_g) / sqrt(d_k), where d_k is the dimension of the key vector. After calculating the attention score for all feature vector pairs, an attention score matrix A_score is obtained. For each row of the attention score matrix A_score, the softmax function is applied for normalization, so that the sum of the attention scores in each row is 1, resulting in the global temporal dependency weight matrix W_att, where W_att_fg = exp(a_fg) / sum_{h=1}^{F}exp(a_fh).

[0061] For id_B and id_C, repeat the above self-attention calculation operation to generate their respective global temporal dependency weight matrices W_att_B and W_att_C.

[0062] Step S135: Perform weighted fusion processing on the multiple local request pattern feature maps according to the global temporal dependency weight matrix to generate a global request evolution coding vector for each containerized application instance.

[0063] For id_A, the global temporal dependency weight matrix W_att is multiplied by the matrix composed of all local request pattern feature maps. Specifically, for the f-th local request pattern feature map M_f, its weighted fused new feature vector Z_f = sum_{g=1}^{F}(W_att_fg) V_g). Concatenate all F Z_f in order to obtain the global request evolutionary coding vector Enc_A=[Z_1, Z_2, ..., Z_F).

[0064] For id_B and id_C, repeat the above weighted fusion operation to generate their respective global request evolutionary coding vectors Enc_B and Enc_C.

[0065] Step S136: Input the global request evolution encoding vector of each containerized application instance into the decoder module of the deep learning request traffic prediction network, and perform temporal unpacking processing on the global request evolution encoding vector through the long short-term memory network layer of the decoder module to generate a sequence of hidden state vectors for each containerized application instance at each time point within the future prediction time window.

[0066] The decoder module of the deep learning request traffic prediction network consists of a long short-term memory network layer and a linear output layer.

[0067] For id_A, its global request evolutionary coding vector Enc_A is input into the Long Short-Term Memory (LSTM) network layer of the decoder module. The LSTM network layer contains H LSTM units. At the first time step, Enc_A is input into the LSTM network layer as the initial hidden state h_0, along with a preset start symbol vector x_0. The LSTM network layer outputs the hidden state h_1 and the memory unit state c_1 at that time step through its input gate, forget gate, output gate, and candidate memory unit calculations. At each subsequent time step t, the output hidden state h_{t-1} and the predicted output y_{t-1} of the previous time step are used as inputs, combined with the memory unit state c_{t-1} at the current time step, to calculate the hidden state h_t and the memory unit state c_t at the current time step. The above process is repeated T times, where T is the number of time steps within the future prediction time window, resulting in the hidden state vector sequence H_A = [h_1, h_2, ..., h_T].

[0068] For id_B and id_C, repeat the above time-series unrolling process to generate their respective hidden state vector sequences H_B and H_C.

[0069] Step S137: Input the sequence of hidden state vectors of each containerized application instance at each time point within the future prediction time window into the linear output layer of the decoder module, and perform dimensional transformation on the hidden state vector at each time point through the linear output layer to generate the prediction parameters of the number of requests arriving for each containerized application instance at each time point within the future prediction time window.

[0070] For id_A, each hidden state vector h_t in the hidden state vector sequence H_A is input into the linear output layer. The linear output layer contains a fully connected neural network that multiplies h_t by the weight matrix W_out and adds the bias vector b_out to obtain the predicted request arrival quantity parameter y_t at that time step. y_t = W_out h_t+b_out. Perform the above operation for all T time points to obtain the request arrival quantity prediction parameter sequence Y_A=[y_1, y_2, ..., y_T].

[0071] For id_B and id_C, repeat the above dimensional transformation operation to generate their respective request arrival quantity prediction parameter sequences Y_B and Y_C.

[0072] Step S138: Calculate the difference between the request arrival quantity prediction parameters of each containerized application instance at each adjacent time within the future prediction time window, and generate the request arrival interval time distribution parameters of each containerized application instance at each adjacent time within the future prediction time window.

[0073] For id_A, for adjacent times t and t+1, the request arrival interval time distribution parameter I_{t, t+1} = (t+1) - t divided by (a certain relationship between y_t and y_{t+1}). In actual calculation, the request arrival interval time distribution parameter I_{t, t+1} = (T_step) / y_t, where T_step is the time interval length between adjacent times. Performing the above calculation for all adjacent time pairs yields the request arrival interval time distribution parameter sequence I_A = [I_{1, 2}, I_{2, 3}, ..., I_{T-1, T}].

[0074] For id_B and id_C, repeat the above difference calculation to generate their respective request arrival interval time distribution parameter sequences I_B and I_C.

[0075] Step S139: Serialize and organize the predicted request arrival quantity parameters of each containerized application instance at each time point within the future prediction time window to obtain the predicted request time-series distribution set of each containerized application instance. Associate and store the predicted request time-series distribution set of each containerized application instance with the corresponding service quality sensitivity descriptor to generate the predicted request time-series distribution set of the containerized application instance set within the future prediction time window.

[0076] For id_A, its predicted request arrival quantity parameter sequence Y_A and request arrival interval time distribution parameter sequence I_A are serialized and organized to obtain the predicted request time series distribution set Pred_A=(Y_A, I_A). Pred_A is then associated with and stored with Q_A generated in step S127.

[0077] For id_B, Pred_B=(Y_B, I_B), and is stored in association with Q_B.

[0078] For id_C, Pred_C=(Y_C, I_C), and associated with Q_C for storage.

[0079] Aggregate id_A, id_B, and id_C with their respective Pred_A, Pred_B, and Pred_C to generate a set of predicted request time series distributions for a set of containerized application instances within a future prediction time window.

[0080] Step S140: Based on the set of service quality sensitivity descriptors and the set of predicted request time-series distributions, perform dynamic resource reservation planning on the set of available resource parameters for the physical computing node cluster, and generate a dynamic binding relationship mapping set between the containerized application instance and the physical computing node. The dynamic binding relationship mapping set includes the target physical computing node identifier parameter, the target node CPU reserved share parameter, and the target node memory reserved share parameter for each containerized application instance.

[0081] After generating the time-series distribution set of prediction requests, the available resources of the physical computing node cluster are dynamically planned and allocated.

[0082] Step S141: Obtain the set of available resource parameters for each physical computing node in the physical computing node cluster. The set of available resource parameters includes the number of available CPU cores and the available memory capacity of each physical computing node at the time of scheduling trigger.

[0083] The industrial cloud platform's physical computing node cluster comprises multiple physical computing nodes, such as nodes N1, N2, and N3. By calling the node information interface of the container orchestration scheduler, the available CPU core count and available memory capacity parameters for each physical computing node at the scheduling trigger time t0 are obtained. For node N1, the available CPU core count parameter is C_avail_N1, and the available memory capacity parameter is M_avail_N1. For node N2, it is C_avail_N2 and M_avail_N2. For node N3, it is C_avail_N3 and M_avail_N3.

[0084] Step S142: Extract the request arrival quantity prediction parameters for each containerized application instance at each time within the future prediction time window from the predicted request time series distribution set, and sum the request arrival quantity prediction parameters for each containerized application instance at all times within the future prediction time window to generate the predicted total request quantity parameter for each containerized application instance.

[0085] For id_A, extract the request arrival count prediction parameter sequence Y_A=[y_1, y_2, ..., y_T] from Pred_A. Predict the total request count parameter Total_A=y_1+y_2+...+y_T.

[0086] For id_B, Total_B = the sum of all elements in Y_B.

[0087] For id_C, Total_C = the sum of all elements in Y_C.

[0088] Step S143: Based on the predicted total request quantity parameter and the service quality sensitivity descriptor of each containerized application instance, generate a resource reservation weight coefficient for each containerized application instance, sort all containerized application instances in descending order according to the resource reservation weight coefficient of each containerized application instance, and generate a resource reservation priority sequence for the containerized application instances.

[0089] For id_A, the resource reservation weight coefficient W_A = Total_A Q_A. For id_B, W_B = Total_B Q_B. For id_C, W_C = Total_C Q_C. Sort id_A, id_B, and id_C in descending order of their respective W values ​​to obtain the resource reservation priority sequence Priority_List=[id_x, id_y, id_z], where id_x has the largest W value and id_z has the smallest W value.

[0090] Step S144: Select containerized application instances to be allocated sequentially from the resource reservation priority sequence, and perform resource reservation allocation operation on each selected containerized application instance to be allocated.

[0091] The resource reservation and allocation operation includes the following sub-steps.

[0092] Step S1441: Obtain the peak time of the predicted number of requests in the predicted request time-series distribution set of the containerized application instance to be allocated, and use the peak time of the predicted number of requests as the peak time parameter of the resource reservation of the containerized application instance to be allocated.

[0093] For the currently selected id_x in Priority_List, extract the request arrival quantity prediction parameter sequence Y_x=[y_1, y_2, ..., y_T] from Pred_x. Find the maximum value y_peak in this sequence and its corresponding time t_peak, and use t_peak as the resource reservation peak time parameter T_peak_x for id_x.

[0094] Step S1442: Select a set of candidate physical computing nodes from the physical computing node cluster whose available CPU core count parameter is greater than the preset basic CPU requirement parameter of the containerized application instance to be allocated. For each candidate physical computing node in the candidate physical computing node set, calculate the difference between the available CPU core count parameter of the candidate physical computing node and the preset basic CPU requirement parameter of the containerized application instance to be allocated, and obtain the CPU resource surplus parameter of the candidate physical computing node.

[0095] For id_x, its default base CPU requirement parameter is C_base_x. Traverse nodes N1, N2, and N3. For node N1, if C_avail_N1 > C_base_x, then add N1 to the candidate physical computing node set Candidates_x. For each candidate node N_c in Candidates_x, the CPU resource surplus parameter E_N_c = C_avail_N_c - C_base_x.

[0096] Step S1443: For each candidate physical computing node in the candidate physical computing node set, perform a weighted summation based on the CPU resource surplus parameter of the candidate physical computing node and the resource reservation weight coefficient of the containerized application instance to be allocated, to generate a resource allocation fitness score parameter for each candidate physical computing node to the containerized application instance to be allocated.

[0097] For each candidate node N_c in Candidates_x, the resource allocation fitness score parameter F_N_c = E_N_c W_x.

[0098] Step S1444: Select the candidate physical computing node with the highest resource allocation fitness score parameter from the candidate physical computing node set as the target physical computing node for the containerized application instance to be allocated. Subtract the preset basic CPU requirement parameter of the containerized application instance to be allocated from the available CPU core count parameter of the target physical computing node, and update the available CPU core count parameter of the target physical computing node.

[0099] Select the node with the largest F value from Candidates_x as the target physical computing node Target_x for id_x. Update the available CPU core count parameter C_avail_Target_x of Target_x to C_avail_Target_x - C_base_x.

[0100] Step S1445: Associate and bind the containerized application instance identifier parameter of the containerized application instance to be allocated with the physical computing node identifier parameter of the target physical computing node to generate a dynamic binding relationship mapping entry between the containerized application instance to be allocated and the physical computing node. The dynamic binding relationship mapping entry includes the containerized application instance identifier parameter, the target physical computing node identifier parameter, the preset basic CPU requirement parameter of the containerized application instance to be allocated as the CPU reservation share parameter of the target node, and the preset basic memory requirement parameter of the containerized application instance to be allocated as the memory reservation share parameter of the target node.

[0101] Generate a dynamic binding relationship mapping entry for id_x: Entry_x = (id_x, Target_x, C_base_x, M_base_x), where M_base_x is the preset base memory requirement parameter for id_x.

[0102] Step S145: Repeat the resource reservation and allocation operation until all containerized application instances in the resource reservation priority sequence have completed resource reservation and allocation, and aggregate the dynamic binding relationship mapping entries of all containerized application instances to generate the dynamic binding relationship mapping set.

[0103] For id_y and id_z in Priority_List, execute steps S1441 to S1445 in sequence to generate Entry_y and Entry_z respectively. Aggregate Entry_x, Entry_y and Entry_z to form a dynamic binding relationship mapping set Mapping_Set=[Entry_x, Entry_y, Entry_z].

[0104] Step S150: Generate a migration scheduling instruction sequence for the containerized application instance based on the dynamic binding relationship mapping set. The migration scheduling instruction sequence includes the source physical computing node identifier parameter, the target physical computing node identifier parameter, and the migration execution time parameter for each containerized application instance. Then, send the migration scheduling instruction sequence to the container orchestration scheduler of the industrial cloud platform.

[0105] After generating the dynamic binding relationship mapping set, specific migration scheduling instructions are generated and issued for execution.

[0106] Step S151: Extract the source physical computing node identifier parameter and the target physical computing node identifier parameter for each containerized application instance from the dynamic binding relationship mapping set.

[0107] For each entry in the Mapping_Set, the source physical computing node identifier parameter and the target physical computing node identifier parameter are extracted. Specifically, for the dynamic binding relationship mapping entry Entry_A corresponding to id_A, the identifier parameter of the physical computing node where id_A currently resides is queried from the container orchestration scheduler of the industrial cloud platform, denoted as Src_A. The target physical computing node identifier parameter Target_A is extracted from Entry_A. For id_B, Src_B is retrieved, and Target_B is extracted from Entry_B. For id_C, Src_C is retrieved, and Target_C is extracted from Entry_C.

[0108] Step S152: Compare the source physical computing node identifier parameter with the target physical computing node identifier parameter for each containerized application instance, identify containerized application instances whose source physical computing node identifier parameter does not match the target physical computing node identifier parameter as containerized application instances to be migrated, and generate a list of containerized application instances to be migrated.

[0109] For id_A, compare Src_A with Target_A. If Src_A is not equal to Target_A, then mark id_A as a containerized application instance to be migrated. Repeat the above comparison operation for id_B and id_C. Collect the identifiers of all containerized application instances whose source physical compute node identifier parameters do not match the target physical compute node identifier parameters to form a list of containerized application instances to be migrated, Migrate_List.

[0110] Step S153: Select each containerized application instance to be migrated from the list of containerized application instances to be migrated, obtain the minimum time of the predicted number of requests in the predicted request time distribution set of the containerized application instance to be migrated, and use the minimum time of the predicted number of requests as the migration execution time parameter of the containerized application instance to be migrated.

[0111] For each containerized application instance to be migrated in Migrate_List, such as id_A, extract the request arrival quantity prediction parameter sequence Y_A=[y_1, y_2, ..., y_T] from Pred_A. Find the minimum value y_min in this sequence and its corresponding time t_min, and use t_min as the migration execution time parameter T_migrate_A for id_A.

[0112] For other containerized application instances in Migrate_List to be migrated, repeat the above steps to generate their respective migration execution time parameters.

[0113] Step S154: Obtain the request arrival quantity prediction parameter corresponding to the migration execution time parameter for each containerized application instance to be migrated, and determine the migration silent window duration parameter for each containerized application instance to be migrated based on the comparison result between the request arrival quantity prediction parameter of each containerized application instance to be migrated and the preset migration silent threshold parameter.

[0114] For id_A, obtain the predicted request arrival number parameter y_min_A corresponding to parameter T_migrate_A at the migration execution time. The preset migration silent threshold parameter is S_threshold. Compare y_min_A with S_threshold. If y_min_A is less than S_threshold, the migration silent window duration parameter W_silent_A is set to the first preset duration T_silent_short; if y_min_A is greater than or equal to S_threshold, W_silent_A is set to the second preset duration T_silent_long.

[0115] For other containerized application instances in Migrate_List to be migrated, repeat the above operations to generate their respective migration silent window duration parameters.

[0116] Step S155: For each containerized application instance to be migrated, perform a division operation based on the migration silent window duration parameter and the preset container image transmission rate parameter to generate a migration transmission time estimation parameter for each containerized application instance to be migrated. For each containerized application instance to be migrated, sum the migration execution time parameter and the migration transmission time estimation parameter to generate a migration completion time parameter for each containerized application instance to be migrated.

[0117] For id_A, the default container image transfer rate parameter is V_transfer. The total size of the container image file for id_A is S_image_A. The migration transfer time estimate parameter T_transfer_A = S_image_A / V_transfer. The migration completion time parameter T_complete_A = T_migrate_A + T_transfer_A.

[0118] For other containerized application instances in Migrate_List to be migrated, repeat the above calculations to generate their respective migration transport time estimation parameters and migration completion time parameters.

[0119] Step S156: For each containerized application instance to be migrated, extract the target node CPU reserved share parameter and the target node memory reserved share parameter corresponding to the containerized application instance to be migrated from the dynamic binding relationship mapping set, and use the target node CPU reserved share parameter and the target node memory reserved share parameter as the resource quota parameters that the containerized application instance to be migrated needs to be allocated when running on the target physical computing node.

[0120] For id_A, extract the target node's CPU reserved share parameter C_reserve_A and target node's memory reserved share parameter M_reserve_A from Entry_A. Use C_reserve_A and M_reserve_A as the resource quota parameters that id_A needs to be allocated on Target_A when it runs.

[0121] For other containerized application instances in Migrate_List to be migrated, repeat the above extraction operation to obtain their respective resource quota parameters.

[0122] Step S157: Combine the containerized application instance identifier parameters, source physical computing node identifier parameters, target physical computing node identifier parameters, migration execution time parameters, migration transmission time estimation parameters, migration completion time parameters, target node CPU reserved share parameters, and target node memory reserved share parameters of each containerized application instance to be migrated to generate a migration scheduling instruction entry for each containerized application instance to be migrated.

[0123] For id_A, generate migration scheduling instruction entry Cmd_A=(id_A, Src_A, Target_A, T_migrate_A, T_transfer_A, T_complete_A, C_reserve_A, M_reserve_A).

[0124] For other containerized application instances in Migrate_List to be migrated, repeat the above combined operation to generate their respective migration scheduling instruction entries.

[0125] Step S158: Sort the migration scheduling instruction entries of each containerized application instance to be migrated according to the time sequence of the migration execution time parameter, generate the migration scheduling instruction sequence, encapsulate the migration scheduling instruction sequence into an instruction format that can be parsed by the container orchestration scheduler, generate an executable instruction stream for the container orchestration scheduler, and send the executable instruction stream for the container orchestration scheduler to the container orchestration scheduler of the industrial cloud platform.

[0126] All migration scheduling instruction entries are sorted in ascending order according to their respective migration execution time parameter T_migrate to obtain the migration scheduling instruction sequence Cmd_Sequence. Each instruction entry in Cmd_Sequence is encapsulated in the data format specified by the application programming interface of the container orchestration scheduler, such as using JavaScript object notation, to generate an executable instruction stream for the container orchestration scheduler. This instruction stream is then sent to the container orchestration scheduler of the industrial cloud platform through a Secure Sockets Layer (SSL) encrypted channel.

[0127] Step S210: Extract the first migration scheduling instruction entry from the migration scheduling instruction sequence, obtain the migration execution time parameter in the first migration scheduling instruction entry as the initial waiting time parameter, calculate the time difference between the initial waiting time parameter and the scheduling trigger time, generate the initial waiting duration parameter, and start a timer to wait until the initial waiting time parameter is reached.

[0128] After the container orchestration scheduler receives the migration scheduling instruction sequence Cmd_Sequence, it extracts the first migration scheduling instruction entry Cmd_first from Cmd_Sequence. It then obtains the migration execution time parameter T_migrate_first from Cmd_first. The difference between T_migrate_first and the current scheduling trigger time t0 is calculated to obtain the initial waiting duration parameter T_wait_first = T_migrate_first - t0. A timer is started, and the system waits for the duration T_wait_first until the time T_migrate_first is reached.

[0129] Step S220: When the initial waiting time parameter is reached, extract all migration scheduling instruction entries whose migration execution time parameters are consistent with the current time from the migration scheduling instruction sequence, generate the current batch migration instruction set, and for each migration scheduling instruction entry in the current batch migration instruction set, establish a container image data transmission channel from the source physical computing node to the target physical computing node according to the source physical computing node identifier parameter and the target physical computing node identifier parameter in the migration scheduling instruction entry.

[0130] Upon reaching time T_migrate_first, all migration scheduling instruction entries in Cmd_Sequence are traversed, and all instruction entries whose migration execution time parameter is equal to the current time are extracted to form the current batch migration instruction set Batch_Current. For each instruction entry Cmd_i in Batch_Current, the source physical compute node identifier parameter Src_i and the target physical compute node identifier parameter Target_i are extracted from Cmd_i. By calling the network interface of the container orchestration scheduler, a long-lived connection channel based on the Transmission Control Protocol is established between Src_i and Target_i for transmitting container image file data.

[0131] Step S230: Through the container image data transmission channel, the container image file of the containerized application instance corresponding to each migration scheduling instruction entry is transmitted from the source physical computing node to the target physical computing node. During the transmission process, the amount of data transmitted for each containerized application instance corresponding to each migration scheduling instruction entry is recorded.

[0132] For each instruction entry Cmd_i in Batch_Current, the container image file of the containerized application instance corresponding to Cmd_i is transferred from Src_i to Target_i through the transmission channel established in step S220. During the transmission, the number of bytes successfully sent is continuously recorded at the sending end to obtain the transmitted data volume parameter T_bytes_i, and this parameter is updated in real time.

[0133] Step S240: Monitor whether the amount of data transferred for each containerized application instance corresponding to the migration scheduling instruction entry has reached the total size of the container image file of the containerized application instance. When the amount of data transferred reaches the total size of the container image file, mark the containerized application instance corresponding to the migration scheduling instruction entry as having completed the container image transfer operation.

[0134] For each instruction entry Cmd_i in Batch_Current, T_bytes_i is continuously monitored. The total size S_image_i of the container image file for this containerized application instance is obtained from Cmd_i. When T_bytes_i equals S_image_i, the container image file transfer is considered complete, and the migration status corresponding to Cmd_i is marked as transfer complete.

[0135] Step S250: For the migration scheduling instruction entry that completes the container image transfer operation, according to the target node CPU reservation share parameter and the target node memory reservation share parameter in the migration scheduling instruction entry, allocate resource quotas for the corresponding containerized application instance on the target physical computing node and generate a resource allocation confirmation identifier.

[0136] For the instruction entry Cmd_i in Batch_Current that has been marked as completed, extract the target node CPU reserve share parameter C_reserve_i and the target node memory reserve share parameter M_reserve_i from Cmd_i. Call the container orchestration scheduler's resource allocation interface on the Target_i node to allocate the CPU core share of C_reserve_i and the memory capacity of M_reserve_i to the containerized application instance corresponding to Cmd_i. After successful resource allocation, the container orchestration scheduler returns a resource allocation confirmation flag Confirm_i.

[0137] Step S260: After completing the resource quota allocation, according to the migration completion time parameter in the migration scheduling instruction entry, start the process of the corresponding containerized application instance on the target physical computing node, and switch the network traffic entry of the containerized application instance to the network address of the target physical computing node.

[0138] For the instruction entry Cmd_i in Batch_Current that has already obtained Confirm_i, the migration completion time parameter T_complete_i is extracted from Cmd_i. Waiting until T_complete_i, the container orchestration scheduler calls the container startup interface on the Target_i node to start the process of the containerized application instance corresponding to Cmd_i. After successful container startup, the network traffic management interface is called to switch the network traffic entry point, originally pointing to the containerized application instance on the Src_i node, to the network address of the Target_i node.

[0139] Step S270: After starting the process of the containerized application instance, release the resource quota occupied by the corresponding containerized application instance on the source physical computing node, and shut down the process of the corresponding containerized application instance on the source physical computing node to complete the migration operation of a single containerized application instance.

[0140] For instruction entry Cmd_i that has completed network traffic switching, the resource release interface of the container orchestration scheduler on the Src_i node is called to release the resource quota originally occupied by the containerized application instance. Then, the container stop interface is called to shut down the process of the containerized application instance on the Src_i node. At this point, the containerized application instance corresponding to Cmd_i has completed the entire migration operation.

[0141] Step S280: Repeat the migration operation for each migration scheduling instruction entry in the current batch migration instruction set until all containerized application instances corresponding to all migration scheduling instruction entries in the current batch migration instruction set have completed the migration operation, and remove the migration scheduling instruction entries that have completed the migration from the migration scheduling instruction sequence.

[0142] For each instruction entry Cmd_i in Batch_Current, execute steps S230 to S270 sequentially. Once all containerized application instances corresponding to all instruction entries in Batch_Current have completed migration, remove all instruction entries contained in Batch_Current from Cmd_Sequence.

[0143] Step S290: Extract the first new migration scheduling instruction entry from the removed migration scheduling instruction sequence, obtain the migration execution time parameter in the first new migration scheduling instruction entry as the new waiting time parameter, and repeat the waiting, transmission, allocation, start and release operations until the migration scheduling instruction sequence is empty.

[0144] Extract the new first migration scheduling instruction entry Cmd_next from the deleted Cmd_Sequence, and obtain the migration execution time parameter T_migrate_next from Cmd_next. Calculate the difference between T_migrate_next and the current time to obtain the new waiting duration parameter, and start a timer to wait until the T_migrate_next time is reached. Repeat steps S220 to S280 until Cmd_Sequence no longer contains any migration scheduling instruction entries.

[0145] Step S310: After the container orchestration scheduler completes the migration scheduling instruction sequence, it obtains the actual resource usage parameter set of each containerized application instance after it runs on the target physical computing node. The actual resource usage parameter set includes the actual CPU usage parameter and the actual memory usage parameter of each containerized application instance after it runs on the target physical computing node.

[0146] After all migration operations are completed, and after a preset observation window T_obs, the actual CPU usage parameter P_actual and actual memory usage parameter M_actual for each containerized application instance running on the target physical compute node are obtained by calling the resource monitoring interface of the container orchestration scheduler. For id_A, P_actual_A and M_actual_A are obtained. For id_B, P_actual_B and M_actual_B are obtained. For id_C, P_actual_C and M_actual_C are obtained.

[0147] Step S320: Extract the target node CPU reserved share parameter and the target node memory reserved share parameter corresponding to each containerized application instance from the dynamic binding relationship mapping set.

[0148] Extract the target node CPU reservation share parameter and target node memory reservation share parameter for each containerized application instance from the Mapping_Set. For id_A, extract C_reserve_A and M_reserve_A from Entry_A. For id_B, extract C_reserve_B and M_reserve_B. For id_C, extract C_reserve_C and M_reserve_C.

[0149] Step S330: For each containerized application instance, calculate the ratio of the actual CPU usage parameter to the target node CPU reservation share parameter to generate a CPU resource reservation utilization rate parameter for each containerized application instance; calculate the ratio of the actual memory usage parameter to the target node memory reservation share parameter to generate a memory resource reservation utilization rate parameter for each containerized application instance; and generate a comprehensive resource reservation utilization rate parameter for each containerized application instance based on the CPU resource reservation utilization rate parameter and the memory resource reservation utilization rate parameter.

[0150] For id_A, the CPU resource reservation utilization parameter U_cpu_A = P_actual_A / C_reserve_A. The memory resource reservation utilization parameter U_mem_A = M_actual_A / M_reserve_A. The total resource reservation utilization parameter U_total_A = (U_cpu_A + U_mem_A) / 2.

[0151] For id_B, U_cpu_B = P_actual_B / C_reserve_B, U_mem_B = M_actual_B / M_reserve_B, U_total_B = (U_cpu_B + U_mem_B) / 2.

[0152] For id_C, U_cpu_C = P_actual_C / C_reserve_C, U_mem_C = M_actual_C / M_reserve_C, U_total_C = (U_cpu_C + U_mem_C) / 2.

[0153] Step S340: Mark the containerized application instances with the comprehensive resource reservation utilization rate parameter lower than the preset lower threshold of resource utilization efficiency as resource reservation excessive application instances, and generate a list of resource reservation excessive application instance identifiers.

[0154] The preset lower threshold of resource utilization efficiency is L_threshold. Traverse all containerized application instances, and mark the instances with U_total lower than L_threshold as resource reservation excessive application instances. For example, if U_total_A < L_threshold, then add id_A to the list of resource reservation excessive application instance identifiers Over_List.

[0155] Step S350: Mark the containerized application instances with the comprehensive resource reservation utilization rate parameter higher than the preset upper threshold of resource utilization efficiency as resource reservation insufficient application instances, generate a list of resource reservation insufficient application instance identifiers, and for each resource reservation excessive application instance in the list of resource reservation excessive application instance identifiers, reduce the corresponding central processing unit reservation share parameter and the target node memory reservation share parameter of the resource reservation excessive application instance in the dynamic binding relationship mapping set, and generate an adjusted dynamic binding relationship mapping set.

[0156] The preset upper threshold of resource utilization efficiency is H_threshold. Traverse all containerized application instances, and mark the instances with U_total higher than H_threshold as resource reservation insufficient application instances, and generate a list of resource reservation insufficient application instance identifiers Short_List.

[0157] For each resource reservation excessive application instance in Over_List, such as id_A, multiply the corresponding C_reserve_A and M_reserve_A in Mapping_Set by an adjustment coefficient α less than 1, and get the new reservation share parameter C_reserve_A_new = C_reserve_A α,M_reserve_A_new=M_reserve_A α. Update the entry corresponding to id_A in Mapping_Set, and generate the adjusted dynamic binding relationship mapping set Mapping_Set_adj.

[0158] Step S360: For each of the application instances with insufficient resource reservation in the list of application instances with insufficient resource reservation, add the target node CPU reservation share parameter and the target node memory reservation share parameter corresponding to the application instance with insufficient resource reservation in the adjusted dynamic binding relationship mapping set, and generate the second adjusted dynamic binding relationship mapping set.

[0159] For each application instance with insufficient resource reservation in Short_List, such as id_B, multiply its corresponding C_reserve_B and M_reserve_B in Mapping_Set_adj by an adjustment coefficient β greater than 1 to obtain the new reservation share parameter C_reserve_B_new=C_reserve_B β,M_reserve_B_new=M_reserve_B β. Update the entry corresponding to id_B in Mapping_Set_adj, and generate the dynamically bound relationship mapping set Mapping_Set_final after secondary adjustments.

[0160] Step S370: Generate a resource reservation adjustment instruction sequence based on the dynamically bound relationship mapping set after the second adjustment, and send the resource reservation adjustment instruction sequence to the container orchestration scheduler of the industrial cloud platform to update the resource quota configuration of each containerized application instance on the target physical computing node.

[0161] Based on `Mapping_Set_final`, resource reservation adjustment instructions are generated for each containerized application instance. For `id_A`, the adjustment instruction `Cmd_adjust_A=(id_A, C_reserve_A_new, M_reserve_A_new)` is generated. For `id_B`, `Cmd_adjust_B=(id_B, C_reserve_B_new, M_reserve_B_new)` is generated. For `id_C`, `Cmd_adjust_C=(id_C, C_reserve_C_new, M_reserve_C_new)` is generated. All adjustment instructions are organized according to the containerized application instance identifier to form a resource reservation adjustment instruction sequence `Adjust_Sequence`. This sequence is encapsulated into an instruction format that can be parsed by the container orchestration scheduler and sent to the container orchestration scheduler through a Secure Sockets Layer encrypted channel. The container orchestration scheduler then updates the resource quota configuration of each containerized application instance on the target physical compute node.

[0162] Step S410: Obtain the set of actual request response time series parameters for each containerized application instance after resource reservation adjustment.

[0163] After the resource reservation adjustment command is executed, and after a preset observation time window T_obs2, the response time records of requests processed by each containerized application instance are obtained by calling the performance metric monitoring interface of the container orchestration scheduler. For id_A, the above response time records are arranged in chronological order to form the actual request response time sequence parameter set RT_actual_A=[rt_actual_A1, rt_actual_A2, ..., rt_actual_An_A]. For id_B and id_C, the above collection operation is repeated to generate RT_actual_B and RT_actual_C respectively.

[0164] Step S420: Extract the request-response latency boundary parameters for each containerized application instance from the set of service quality sensitivity descriptors.

[0165] From the set of service quality sensitivity descriptors generated in step S127, extract the request-response latency boundary parameters for each containerized application instance. For id_A, extract D_A. For id_B, extract D_B. For id_C, extract D_C.

[0166] Step S430: For each containerized application instance, calculate the average actual request response time parameter in the actual request response time series parameter set to obtain the average request response time parameter for each containerized application instance. Compare the average request response time parameter with the request response latency boundary parameter to generate a latency boundary deviation parameter for each containerized application instance. For containerized application instances whose latency boundary deviation parameter exceeds a preset deviation tolerance threshold, mark them as service quality default application instances and generate a service quality default application instance identifier list.

[0167] For id_A, calculate the sum of all elements in RT_actual_A and divide by the number of elements n_A to obtain the average request response time parameter R_avg_A. The latency boundary deviation parameter Dev_A = R_avg_A - D_A. The preset deviation tolerance threshold is Dev_threshold. If Dev_A > Dev_threshold, then id_A is marked as a service quality breach application instance and added to the service quality breach application instance identifier list Violation_List.

[0168] For id_B and id_C, repeat the above calculation and comparison operations to obtain Dev_B and Dev_C respectively, and decide whether to add them to Violation_List based on the comparison results.

[0169] Step S440: For each service quality default application instance in the service quality default application instance identifier list, obtain the request arrival quantity prediction parameter in the predicted request time-series distribution set and the actual CPU usage parameter in the actual resource usage parameter set for the service quality default application instance, and generate a request resource mapping relationship data pair for the service quality default application instance.

[0170] For each service quality default application instance in Violation_List, such as id_A, extract the request arrival quantity prediction parameter sequence Y_A=[y_1, y_2, ..., y_T] from Pred_A. Extract the actual CPU usage parameter P_actual_A of id_A from the actual resource usage parameter set obtained in step S310. Pair Y_A with P_actual_A to generate a request resource mapping relationship data pair Map_A=(Y_A, P_actual_A).

[0171] For other service quality breach application instances in Violation_List, repeat the above operations to generate their respective request resource mapping relationship data pairs.

[0172] Step S450: Train the deep learning resource demand calibration network with the request resource mapping relationship data of all service quality default application instances in the service quality default application instance identifier list. The deep learning resource demand calibration network updates the network weight parameters of the deep learning resource demand calibration network with the request arrival quantity prediction parameter as input feature and the actual central processing unit usage parameter as output target.

[0173] The deep learning resource demand calibration network employs a multilayer perceptron architecture, comprising an input layer, two hidden layers, and an output layer. The number of neurons in the input layer equals the number of times T within the prediction time window, with each neuron corresponding to a prediction parameter for the number of requests arriving at a given time. The first hidden layer contains 64 neurons, using a linear rectified function as the activation function. The second hidden layer contains 32 neurons, also using a linear rectified function as the activation function. The output layer contains one neuron, outputting the actual CPU usage parameter. The network uses a mean squared error loss function, and the optimizer is an adaptive moment estimation optimizer.

[0174] The request resource mapping pairs of all service quality default application instances in Violation_List are used as training samples. For id_A, Y_A is used as the input feature and P_actual_A as the output target. These are input into a deep learning resource demand calibration network for forward propagation calculation to obtain the predicted output value P_pred_A. The loss value Loss_A = (P_pred_A - P_actual_A)^2 is calculated. The gradients of the parameters in each layer of the network are calculated using the backpropagation algorithm, and the network weight parameters are updated using the adaptive moment estimation optimizer. Multiple rounds of iterative training are performed on all samples in Violation_List until the loss function converges or the preset maximum number of training rounds is reached.

[0175] Step S460: Use the updated deep learning resource demand calibration network to re-predict the request arrival quantity prediction parameters of all containerized application instances in the predicted request time-series distribution set, generate a calibrated predicted CPU demand parameter set, use the calibrated predicted CPU demand parameter set as the basis for updating the preset basic CPU demand parameters in the next scheduling cycle, generate updated preset basic CPU demand parameters, and store them in the configuration database of the industrial cloud platform.

[0176] For all containerized application instances, including those not in the Violation_List, the sequence of predicted request arrival parameters is input into the updated deep learning resource demand calibration network. For id_A, Y_A is input into the network, and the network outputs the calibrated CPU demand parameter P_calibrated_A. For id_B, P_calibrated_B is obtained. For id_C, P_calibrated_C is obtained. All calibrated CPU demand parameters are combined into a calibrated predicted CPU demand parameter set Calibrated_Set. The calibrated CPU demand parameter of each containerized application instance in Calibrated_Set is used as the updated value of the preset basic CPU demand parameter for that containerized application instance in the next scheduling cycle and stored in the configuration database of the industrial cloud platform for use in the resource reservation and allocation operation in step S1442.

[0177] Step S510: Obtain a long-term operation log data set of multiple containerized application instances deployed in the industrial cloud platform. The long-term operation log data set includes the historical request arrival time series parameters, historical CPU usage time series parameters, and historical memory usage time series parameters for each containerized application instance in multiple scheduling cycles.

[0178] Obtain long-term runtime log data of all containerized application instances over multiple past scheduling cycles from the log storage system of the industrial cloud platform. For id_A, extract its historical request arrival time-series parameters Q_hist_A=[Q_A_1, Q_A_2, ..., Q_A_M], historical CPU usage time-series parameters P_hist_A=[P_A_1, P_A_2, ..., P_A_M], and historical memory usage time-series parameters M_hist_A=[M_A_1, M_A_2, ..., M_A_M]. Repeat the above extraction operation for id_B and id_C to obtain Q_hist_B, P_hist_B, M_hist_B and Q_hist_C, P_hist_C, M_hist_C, respectively.

[0179] Step S520: Extract the historical request arrival time series parameters and the historical CPU usage time series parameters for each containerized application instance from the long-term running log data set, and construct a historical association dataset of request resource consumption for each containerized application instance.

[0180] For id_A, align Q_hist_A and P_hist_A according to time and construct a historical association dataset of requested resource consumption, Dataset_A=[(Q_A_1, P_A_1), (Q_A_2, P_A_2), ..., (Q_A_M, P_A_M)]. Repeat the above construction operation for id_B and id_C to generate Dataset_B and Dataset_C respectively.

[0181] Step S530: Perform time-series sliding window segmentation on the historical associated dataset of request resource consumption for each containerized application instance to generate multiple request resource consumption associated subsets corresponding to time-series windows.

[0182] For id_A, set the sliding window size to W_size and the step size to W_step. Starting from the first data point of Dataset_A, sequentially extract W_size consecutive data pairs to form a request resource consumption correlation subset Subset_A_1 corresponding to a time series window. Then slide W_step forward and extract the next W_size consecutive data pairs to form Subset_A_2. Repeat the above operation until the sliding window covers the end of Dataset_A, generating K request resource consumption correlation subsets Subset_A = [Subset_A_1, Subset_A_2, ..., Subset_A_K] corresponding to time series windows.

[0183] For id_B and id_C, repeat the sliding window segmentation process described above to generate their respective request resource consumption associated subsets Subset_B and Subset_C.

[0184] Step S540: For the request resource consumption associated subset corresponding to each time window, calculate the Pearson correlation coefficient parameter between the time sequence parameter of the number of historical requests arriving and the time sequence parameter of the historical CPU usage within that time window, and generate the request resource consumption association strength parameter for each time window.

[0185] For Subset_A_1 of id_A, calculate the Pearson correlation coefficient between all Q values ​​and their corresponding P values ​​in this subset. Specifically, calculate the mean of the Q values ​​μ_Q and the mean of the P values ​​μ_P, and calculate the covariance of the Q and P values ​​Cov(Q, P) = (1 / (W_size-1)). Σ(Q_i-μ_Q) (P_i-μ_P), calculate the standard deviation of Q σ_Q and the standard deviation of P σ_P, and the Pearson correlation coefficient r_1=Cov(Q,P) / (σ_Q) σ_P). For Subset_A_2 to Subset_A_K, repeat the above calculation to obtain the correlation strength parameter sequence R_A=[r_1, r_2, ..., r_K).

[0186] Repeat the above calculation for id_B and id_C to generate R_B and R_C respectively.

[0187] Step S550: Based on the changing trend of the request resource consumption correlation strength parameter in multiple time windows of each containerized application instance, identify the request resource consumption correlation mode type of each containerized application instance. The request resource consumption correlation mode type includes stable correlation type, periodic fluctuation correlation type and sudden impact correlation type.

[0188] For id_A, analyze the characteristics of the R_A sequence. Calculate the mean μ_R and standard deviation σ_R of the R_A sequence. If the difference between all r_i and μ_R is less than the preset stability threshold S_stable, and σ_R is less than the preset fluctuation threshold V_threshold, then the resource consumption association pattern of id_A is identified as a stable association type. If the R_A sequence exhibits a periodic increase or decrease pattern, for example, if a significant periodic component is detected by Fourier transform, then the pattern type of id_A is identified as a periodic fluctuation association type. If there are individual r_i in the R_A sequence that are much larger or much smaller than other values, and the number of requests arriving within the time window corresponding to these outliers shows a sudden spike, then the pattern type of id_A is identified as a sudden shock association type.

[0189] For id_B and id_C, repeat the above pattern recognition operation to determine their respective request resource consumption association pattern types.

[0190] Step S560: For containerized application instances whose request resource consumption association mode type is the stable association type, a linear regression algorithm is used to fit the linear relationship between the historical request arrival time series parameters and the historical CPU usage time series parameters of the containerized application instance, and a stable resource demand function for the containerized application instance is generated.

[0191] For containerized application instances with a stable association pattern, such as id_A, least squares linear regression is used to fit the data points in Dataset_A. Let the linear relationship be P=α. Let α be the slope and β be the intercept. Calculate α = (Σ(Q_i - μ_Q)). (P_i-μ_P)) / Σ(Q_i-μ_Q)^2, β=μ_P-α μ_Q. Generate a stable resource demand function f_A(Q)=α Q+β.

[0192] Step S570: For containerized application instances whose request resource consumption association mode type is the periodic fluctuation association type, use the Fourier series fitting algorithm to decompose the periodic components of the historical request arrival quantity time series parameters and the historical CPU usage time series parameters of the containerized application instance, and generate the periodic resource demand function of the containerized application instance.

[0193] For containerized application instances with a periodic fluctuation correlation pattern, such as id_B, perform Fourier transforms on Q_hist_B and P_hist_B respectively to extract the main frequency components. Let the periodic resource demand function be f_B(Q, t)=a0+Σ_{k=1}^{N}[a_k] sin(2πkt / T)+b_k [cos(2πkt / T)], where t is the time variable, T is the identified main cycle length, a0 is the DC component, and a_k and b_k are Fourier coefficients. The values ​​of a0, a_k, and b_k are determined by fitting historical data to generate a periodic resource demand function.

[0194] Step S580: For containerized application instances whose request resource consumption association mode type is the sudden impact association type, use the quantile regression algorithm to fit the CPU usage parameter conditional distribution of the containerized application instance under different request arrival quantity quantile conditions, and generate the sudden resource demand function of the containerized application instance.

[0195] For containerized application instances with a sudden impact correlation pattern, such as id_C, a quantile regression algorithm is employed. Multiple quantile levels τ are defined, and for each τ, the objective function minΣρ_τ(P_i-f_τ(Q_i)) is solved, where ρ_τ is the skewed absolute value loss function. This yields the conditional quantile function f_τ(Q) at multiple quantile levels. These conditional quantile functions are then combined to form the sudden resource demand function f_C(Q, τ).

[0196] Step S590: Store the stable resource demand function, the periodic resource demand function, and the bursty resource demand function as personalized resource demand prediction models for each containerized application instance in the model library of the industrial cloud platform.

[0197] The stable resource demand function f_A(Q) of id_A, the periodic resource demand function f_B(Q, t) of id_B, and the bursty resource demand function f_C(Q, τ) of id_C are stored in the model library of the industrial cloud platform as their respective personalized resource demand prediction models for use in resource prediction of subsequent scheduling cycles.

[0198] For example, the method may further include: step S610: when a subsequent scheduling cycle is triggered, obtain the instantaneous value parameter of the current request arrival rate and the parameter of the current request waiting queue for each containerized application instance, input the personalized resource demand prediction model corresponding to the containerized application instance, and output the real-time resource demand prediction parameter of the containerized application instance under the current load state, wherein the real-time resource demand prediction parameter includes the real-time CPU demand prediction parameter and the real-time memory demand prediction parameter.

[0199] At the next scheduling cycle trigger time t_next, obtain the instantaneous value of the current request arrival rate and the current request waiting queue length for each containerized application instance. For id_A, obtain L_A_curr and R_A_curr. Based on the stable association type of the request resource consumption association mode for id_A, load f_A(Q) from the model library. Calculate the current request load comprehensive index Q_A_curr = L_A_curr R_A_curr. Substituting Q_A_curr into f_A(Q), we obtain the real-time CPU demand prediction parameter P_pred_A = f_A(Q_A_curr). Simultaneously, a memory demand prediction model is established using a similar method. Based on historical data, the relationship between memory demand and request load g_A(Q) is fitted, and the real-time memory demand prediction parameter M_pred_A = g_A(Q_A_curr) is calculated.

[0200] For id_B and id_C, calculate their respective real-time CPU demand prediction parameters and real-time memory demand prediction parameters based on their respective personalized resource demand prediction models.

[0201] Step S620: For each containerized application instance, compare the real-time resource demand prediction parameters with the current resource quota parameters already allocated to the containerized application instance on the current physical computing node, and generate resource gap parameters or resource redundancy parameters for each containerized application instance.

[0202] For id_A, obtain the current resource quota parameters allocated to id_A on the current physical computing node, including the current CPU quota C_curr_A and the current memory quota M_curr_A. The resource gap parameter or resource redundancy parameter is calculated as follows: ΔC_A = P_pred_A - C_curr_A, ΔM_A = M_pred_A - M_curr_A. If both ΔC_A and ΔM_A are positive, there is a resource gap; if both are negative, there is resource redundancy.

[0203] For id_B and id_C, repeat the above comparison operation to generate their respective ΔC and ΔM.

[0204] Step S630: For containerized application instances whose resource gap parameter is greater than a preset resource gap threshold, mark them as resource-scarce application instances and generate a list of resource-scarce application instances; and for containerized application instances whose resource redundancy parameter is greater than a preset resource redundancy threshold, mark them as resource-idle application instances and generate a list of resource-idle application instances.

[0205] The preset resource gap threshold is Gap_threshold, and the preset resource redundancy threshold is Surplus_threshold. Iterate through all containerized application instances. For id_A, if ΔC_A > Gap_threshold and ΔM_A > Gap_threshold, then id_A is marked as a resource-scarce application instance and added to the resource-scarce application instance list Tight_List. For id_B, if ΔC_B <- Surplus_threshold and ΔM_B <- Surplus_threshold, then id_B is marked as a resource-idle application instance and added to the resource-idle application instance list Idle_List.

[0206] Step S640: Select the containerized application instance with the largest resource redundancy parameter from the list of idle application instances as the resource release source instance, and select the containerized application instance with the largest resource shortage parameter from the list of resource scarce application instances as the resource receiving target instance.

[0207] Select the containerized application instance with the largest sum of absolute values ​​of ΔC and ΔM from Idle_List as the resource release source instance Source_Instance. Select the containerized application instance with the largest sum of ΔC and ΔM from Tight_List as the resource receiving target instance Target_Instance.

[0208] Step S650: Compare the physical computing node identifier parameter of the resource release source instance with the physical computing node identifier parameter of the resource receiving target instance. When the physical computing node identifier parameter of the resource release source instance is the same as that of the resource receiving target instance, reallocate the resource share corresponding to the resource redundancy parameter of the resource release source instance to the resource receiving target instance and generate a same-node resource reallocation instruction.

[0209] Obtain the physical computing node identifier parameter Node_Source where Source_Instance currently resides, and obtain the physical computing node identifier parameter Node_Target where Target_Instance currently resides. Compare Node_Source and Node_Target. If Node_Source equals Node_Target, calculate the resource redundancy shares ΔC_Source and ΔM_Source of Source_Instance, deduct the resources corresponding to these shares from Source_Instance's quota, and add them to Target_Instance's quota. Generate the same-node resource reallocation instruction Cmd_resize=(Source_Instance, Target_Instance, ΔC_Source, ΔM_Source).

[0210] Step S660: When the physical computing node identifier parameter of the resource release source instance is different from the physical computing node identifier parameter of the resource receiving target instance, a cross-node resource scheduling instruction is generated. The cross-node resource scheduling instruction includes the physical computing node identifier parameter of the resource release source instance, the physical computing node identifier parameter of the resource receiving target instance, the resource share parameter to be migrated, and the migration execution time parameter.

[0211] If Node_Source is not equal to Node_Target, then calculate the resource redundancy shares ΔC_Source and ΔM_Source of Source_Instance as the resource share parameters to be migrated. Set the migration execution time parameter to the current time plus a preset scheduling delay time T_delay. Generate the cross-node resource scheduling instruction Cmd_migrate_res=(Source_Instance, Node_Source, Target_Instance, Node_Target, ΔC_Source, ΔM_Source, T_delay).

[0212] Step S670: Send the same-node resource reallocation instruction or the cross-node resource scheduling instruction to the container orchestration scheduler of the industrial cloud platform for execution.

[0213] The generated Cmd_resize or Cmd_migrate_res is encapsulated into an instruction format that can be parsed by the container orchestration scheduler and sent to the container orchestration scheduler of the industrial cloud platform through a secure socket encrypted channel. The container orchestration scheduler then performs the corresponding resource reallocation or container migration operations.

[0214] Figure 2This application illustrates a dynamic scheduling system 100 for industrial cloud platform computing resources incorporating deep learning, comprising a processor 1001 and a memory 1003. The processor 1001 and memory 1003 are connected, for example, via a bus 1002. Optionally, the dynamic scheduling system 100 may further include a transceiver 1004, which can be used for data interaction between this dynamic scheduling system and other dynamic scheduling systems incorporating deep learning, such as sending and / or receiving data. It should be noted that in actual scheduling, the transceiver 1004 is not limited to one, and the structure of this dynamic scheduling system 100 does not constitute a limitation on the embodiments of this application.

[0215] The memory 1003 is used to store program code for executing the embodiments of this application, and its execution is controlled by the processor 1001. The processor 1001 is used to execute the program code stored in the memory 1003 to implement the steps shown in the foregoing method embodiments.

[0216] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application, without departing from the technical concept of this application, also fall within the protection scope of the embodiments of this application.

Claims

1. A method for dynamic scheduling of computing resources in an industrial cloud platform combining deep learning, characterized in that, The method includes: Obtain the real-time request queue parameter set and the real-time container resource parameter set of the containerized application instance set in the industrial cloud platform. The real-time request queue parameter set includes the request waiting queue length parameter and the instantaneous value of the request arrival rate of each containerized application instance at the time of scheduling trigger. The real-time container resource parameter set includes the container CPU usage parameter and the container memory usage parameter of each containerized application instance at the time of scheduling trigger. A correlation coupling analysis is performed on the real-time request queue parameter set and the real-time container resource parameter set to generate a service quality sensitivity descriptor set for the containerized application instance set. The service quality sensitivity descriptor set includes the request response latency tolerance parameter and the request burst impact absorption capability parameter for each containerized application instance. The deep learning request traffic prediction network is invoked to identify the request traffic evolution pattern of the real-time request queue parameter set, and a predicted request time series distribution set of the containerized application instance set within the future prediction time window is generated. The predicted request time series distribution set includes the predicted parameters of the number of requests arriving at each time and the distribution parameters of the request arrival interval time for each containerized application instance within the future prediction time window. Based on the set of service quality sensitivity descriptors and the set of predicted request time-series distributions, dynamic resource reservation planning is performed on the set of available resource parameters for nodes in the physical computing node cluster to generate a dynamic binding relationship mapping set between the containerized application instance and the physical computing node. The dynamic binding relationship mapping set includes the target physical computing node identifier parameter, the target node CPU reserved share parameter, and the target node memory reserved share parameter for each containerized application instance. Based on the dynamic binding relationship mapping set, a migration scheduling instruction sequence for the containerized application instance is generated, and the migration scheduling instruction sequence is sent to the container orchestration scheduler of the industrial cloud platform. The migration scheduling instruction sequence includes the source physical computing node identifier parameter, the target physical computing node identifier parameter, and the migration execution time parameter for each containerized application instance.

2. The method for dynamic scheduling of computing resources in an industrial cloud platform combined with deep learning as described in claim 1, characterized in that, The step of performing correlation and coupling analysis on the real-time request queue parameter set and the real-time container resource parameter set to generate a service quality sensitivity descriptor set for the containerized application instance set includes: Extract the request waiting queue length parameter and the instantaneous value of the request arrival rate for each containerized application instance from the real-time request queue parameter set, and extract the container CPU usage parameter and the container memory usage parameter for each containerized application instance from the real-time container resource parameter set. The request waiting queue length parameter and the container CPU usage parameter of each containerized application instance are correlated and analyzed to generate the CPU resource stress parameter of each containerized application instance. The instantaneous value of the request arrival rate parameter and the container memory usage parameter of each containerized application instance are correlated and analyzed to generate the memory resource pressure parameter of each containerized application instance. Collect a set of request-response time series parameters that have been processed by each containerized application instance within a historical time window; Quantile statistical processing is performed on the request-response time series parameter set of each containerized application instance to extract the request-response delay boundary parameter of each containerized application instance at a preset quantile. The CPU resource demand gradient parameter under unit latency constraint for each containerized application instance is generated by performing correlation calculations between the request response latency boundary parameter and the CPU resource stress parameter for each containerized application instance. The request burst absorption latency compensation parameter for each containerized application instance is generated by performing correlation calculations between the request response latency boundary parameter and the memory resource pressure parameter for each containerized application instance. The three-dimensional service quality sensitivity vector of each containerized application instance is constructed by taking the CPU resource demand gradient parameter under the unit latency constraint of each containerized application instance as the first dimension parameter, the request burst absorption latency compensation parameter of each containerized application instance as the second dimension parameter, and the request response latency boundary parameter of each containerized application instance as the third dimension parameter. The three-dimensional service quality sensitivity vector of each containerized application instance is normalized to obtain a normalized service quality sensitivity vector for each containerized application instance. The normalization parameters in the normalized service quality sensitivity vector of each containerized application instance are weighted and aggregated according to a preset weight coefficient to generate the service quality sensitivity descriptor for each containerized application instance.

3. The method for dynamic scheduling of computing resources in an industrial cloud platform combined with deep learning as described in claim 1, characterized in that, The method involves calling a deep learning request traffic prediction network to identify request traffic evolution patterns in the real-time request queue parameter set, generating a set of predicted request time series distributions for the containerized application instance set within a future prediction time window, including: The request waiting queue length parameter and the instantaneous value parameter of the request arrival rate of each containerized application instance are combined in chronological order to construct the current request status feature vector of each containerized application instance. Collect the request state feature vectors of each containerized application instance at multiple consecutive historical moments to construct the historical request state feature sequence of each containerized application instance; The historical request state feature sequence of each containerized application instance is input into the encoder module of the deep learning request traffic prediction network. The convolutional layer of the encoder module performs local temporal pattern extraction on the historical request state feature sequence to generate multiple local request pattern feature maps for each containerized application instance. The multiple local request pattern feature maps of each containerized application instance are input into the self-attention layer of the encoder module, and the global temporal dependency weight matrix between the multiple local request pattern feature maps is calculated through the self-attention layer. The multiple local request pattern feature maps are weighted and fused according to the global temporal dependency weight matrix to generate a global request evolution coding vector for each containerized application instance. The global request evolution encoding vector of each containerized application instance is input into the decoder module of the deep learning request traffic prediction network. The global request evolution encoding vector is temporally expanded through the long short-term memory network layer of the decoder module to generate a sequence of hidden state vectors for each containerized application instance at each time point within the future prediction time window. The hidden state vector sequence of each containerized application instance at each time point within the future prediction time window is input into the linear output layer of the decoder module. The hidden state vector at each time point is transformed by the linear output layer to generate the request arrival quantity prediction parameter for each containerized application instance at each time point within the future prediction time window. The difference between the request arrival quantity prediction parameters of each containerized application instance at each adjacent time within the future prediction time window is calculated to generate the request arrival interval time distribution parameters of each containerized application instance at each adjacent time within the future prediction time window. The predicted request arrival quantity parameters of each containerized application instance at each time point within the future prediction time window are serialized and organized to obtain the predicted request time series distribution set of each containerized application instance. The predicted request time series distribution set of each containerized application instance is associated and stored with the corresponding service quality sensitivity descriptor to generate the predicted request time series distribution set of the containerized application instance set within the future prediction time window.

4. The method for dynamic scheduling of computing resources in an industrial cloud platform combined with deep learning according to claim 1, characterized in that, The step of performing dynamic resource reservation planning on the set of available resource parameters for nodes in the physical computing node cluster based on the set of service quality sensitivity descriptors and the set of predicted request time-series distributions, and generating a dynamic binding relationship mapping set between the containerized application instance and the physical computing node, includes: Obtain the set of available resource parameters for each physical computing node in the physical computing node cluster. The set of available resource parameters includes the number of available CPU cores and the available memory capacity of each physical computing node at the time of scheduling trigger. Extract the request arrival quantity prediction parameters for each containerized application instance at each time within the future prediction time window from the predicted request time series distribution set, and sum the request arrival quantity prediction parameters for each containerized application instance at all times within the future prediction time window to generate the predicted total request quantity parameter for each containerized application instance. Based on the predicted total request quantity parameter and the service quality sensitivity descriptor for each containerized application instance, a resource reservation weight coefficient for each containerized application instance is generated. All containerized application instances are sorted in descending order based on the resource reservation weight coefficient for each containerized application instance to generate a resource reservation priority sequence for the containerized application instances. Containerized application instances to be allocated are selected sequentially from the resource reservation priority sequence, and a resource reservation allocation operation is performed on each selected containerized application instance to be allocated. The resource reservation allocation operation includes: obtaining the peak time of the predicted number of requests in the predicted request time series distribution set of the containerized application instance to be allocated, and using the peak time of the predicted number of requests as the resource reservation peak time parameter of the containerized application instance to be allocated. From the physical computing node cluster, a set of candidate physical computing nodes is selected where the number of available CPU cores is greater than the preset basic CPU requirement of the containerized application instance to be allocated. For each candidate physical computing node in the set of candidate physical computing nodes, the difference between the number of available CPU cores of the candidate physical computing node and the preset basic CPU requirement of the containerized application instance to be allocated is calculated to obtain the CPU resource surplus parameter of the candidate physical computing node. For each candidate physical computing node in the candidate physical computing node set, a weighted sum is performed based on the CPU resource surplus parameter of the candidate physical computing node and the resource reservation weight coefficient of the containerized application instance to be allocated, to generate a resource allocation fitness score parameter for each candidate physical computing node to the containerized application instance to be allocated. Select the candidate physical computing node with the highest resource allocation fitness score from the candidate physical computing node set as the target physical computing node for the containerized application instance to be allocated; subtract the preset basic CPU requirement parameter of the containerized application instance to be allocated from the available CPU core count parameter of the target physical computing node; and update the available CPU core count parameter of the target physical computing node. The containerized application instance identifier parameter of the containerized application instance to be allocated is associated and bound with the physical computing node identifier parameter of the target physical computing node to generate a dynamic binding relationship mapping entry between the containerized application instance to be allocated and the physical computing node. The dynamic binding relationship mapping entry includes the containerized application instance identifier parameter, the target physical computing node identifier parameter, the preset basic CPU requirement parameter of the containerized application instance to be allocated as the CPU reservation share parameter of the target node, and the preset basic memory requirement parameter of the containerized application instance to be allocated as the memory reservation share parameter of the target node. Repeat the resource reservation and allocation operation until all containerized application instances in the resource reservation priority sequence have completed resource reservation and allocation, and aggregate the dynamic binding relationship mapping entries of all containerized application instances to generate the dynamic binding relationship mapping set.

5. The method for dynamic scheduling of computing resources in an industrial cloud platform combined with deep learning according to claim 1, characterized in that, The step of generating a migration scheduling instruction sequence for the containerized application instance based on the dynamic binding relationship mapping set, and distributing the migration scheduling instruction sequence to the container orchestration scheduler of the industrial cloud platform, includes: Extract the source physical computing node identifier parameter and the target physical computing node identifier parameter for each containerized application instance from the dynamic binding relationship mapping set; For each containerized application instance, the source physical computing node identifier parameter is compared with the target physical computing node identifier parameter. Containerized application instances whose source physical computing node identifier parameters do not match the target physical computing node identifier parameters are identified as containerized application instances to be migrated, and a list of containerized application instances to be migrated is generated. Select each containerized application instance to be migrated from the list of containerized application instances to be migrated, obtain the minimum time of the predicted number of requests in the predicted request time series distribution set of the containerized application instance to be migrated, and use the minimum time of the predicted number of requests as the migration execution time parameter of the containerized application instance to be migrated. Obtain the request arrival quantity prediction parameter corresponding to the migration execution time parameter for each containerized application instance to be migrated; and determine the migration silent window duration parameter for each containerized application instance to be migrated based on the comparison result between the request arrival quantity prediction parameter for each containerized application instance to be migrated and the preset migration silent threshold parameter. For each containerized application instance to be migrated, a division operation is performed between the migration silent window duration parameter and the preset container image transmission rate parameter to generate a migration transmission time estimation parameter for each containerized application instance to be migrated. For each containerized application instance to be migrated, the migration execution time parameter and the migration transmission time estimation parameter are summed to generate a migration completion time parameter for each containerized application instance to be migrated. For each containerized application instance to be migrated, the target node CPU reserved share parameter and the target node memory reserved share parameter corresponding to the containerized application instance to be migrated are extracted from the dynamic binding relationship mapping set, and the target node CPU reserved share parameter and the target node memory reserved share parameter are used as the resource quota parameters that the containerized application instance to be migrated needs to be allocated on the target physical computing node when it runs. The containerized application instance identifier parameter, source physical computing node identifier parameter, target physical computing node identifier parameter, migration execution time parameter, migration transmission time estimation parameter, migration completion time parameter, target node CPU reserved share parameter and target node memory reserved share parameter of each containerized application instance to be migrated are combined to generate a migration scheduling instruction entry for each containerized application instance to be migrated. The migration scheduling instruction entries of each containerized application instance to be migrated are sorted according to the time sequence of the migration execution time parameter to generate the migration scheduling instruction sequence. The migration scheduling instruction sequence is encapsulated into an instruction format that can be parsed by the container orchestration scheduler to generate an executable instruction stream for the container orchestration scheduler. The executable instruction stream for the container orchestration scheduler is then sent to the container orchestration scheduler of the industrial cloud platform.

6. The method for dynamic scheduling of computing resources in an industrial cloud platform combined with deep learning according to claim 5, characterized in that, The method further includes: Extract the first migration scheduling instruction entry from the migration scheduling instruction sequence, obtain the migration execution time parameter in the first migration scheduling instruction entry as the initial waiting time parameter, calculate the time difference between the initial waiting time parameter and the scheduling trigger time, generate the initial waiting duration parameter, and start a timer to wait until the initial waiting time parameter is reached. When the initial waiting time parameter is reached, all migration scheduling instruction entries whose migration execution time parameters are consistent with the current time are extracted from the migration scheduling instruction sequence to generate the current batch migration instruction set. For each migration scheduling instruction entry in the current batch migration instruction set, a container image data transmission channel from the source physical computing node to the target physical computing node is established according to the source physical computing node identifier parameter and the target physical computing node identifier parameter in the migration scheduling instruction entry. Through the container image data transmission channel, the container image file of the containerized application instance corresponding to each migration scheduling instruction entry is transmitted from the source physical computing node to the target physical computing node. During the transmission process, the amount of data transmitted for each containerized application instance corresponding to each migration scheduling instruction entry is recorded. Monitor whether the amount of data already transmitted for each containerized application instance corresponding to the migration scheduling instruction entry reaches the total size of the container image file of the containerized application instance. When the amount of data already transmitted reaches the total size of the container image file, mark the containerized application instance corresponding to the migration scheduling instruction entry as having completed the container image transmission operation. For the migration scheduling instruction entry that completes the container image transfer operation, according to the target node CPU reserved share parameter and the target node memory reserved share parameter in the migration scheduling instruction entry, resource quotas are allocated to the corresponding containerized application instance on the target physical computing node, and a resource allocation confirmation identifier is generated. After the resource quota allocation is completed, according to the migration completion time parameter in the migration scheduling instruction entry, the process of the corresponding containerized application instance is started on the target physical computing node, and the network traffic entry of the containerized application instance is switched to the network address of the target physical computing node. After starting the process of the containerized application instance, release the resource quota occupied by the corresponding containerized application instance on the source physical computing node, and shut down the process of the corresponding containerized application instance on the source physical computing node to complete the migration operation of a single containerized application instance. Repeat the migration operation for each migration scheduling instruction entry in the current batch migration instruction set until all containerized application instances corresponding to all migration scheduling instruction entries in the current batch migration instruction set have completed the migration operation, and remove the migration scheduling instruction entries that have completed the migration from the migration scheduling instruction sequence. Extract the first new migration scheduling instruction entry from the removed migration scheduling instruction sequence, obtain the migration execution time parameter in the first new migration scheduling instruction entry as the new waiting time parameter, and repeat the waiting, transmission, allocation, start and release operations until the migration scheduling instruction sequence is empty.

7. The method for dynamic scheduling of computing resources in an industrial cloud platform combined with deep learning according to claim 1, characterized in that, The method further includes: After the container orchestration scheduler completes the migration scheduling instruction sequence, it obtains the actual resource usage parameter set of each containerized application instance after it runs on the target physical computing node. The actual resource usage parameter set includes the actual CPU usage parameter and the actual memory usage parameter of each containerized application instance after it runs on the target physical computing node. Extract the target node CPU reserved share parameter and the target node memory reserved share parameter corresponding to each containerized application instance from the dynamic binding relationship mapping set; For each containerized application instance, the ratio of the actual CPU usage parameter to the target node CPU reservation share parameter is calculated to generate a CPU resource reservation utilization parameter for each containerized application instance. Additionally, the ratio of the actual memory usage parameter to the target node memory reservation share parameter is calculated to generate a memory resource reservation utilization parameter for each containerized application instance. Finally, based on the CPU resource reservation utilization parameter and the memory resource reservation utilization parameter, a comprehensive resource reservation utilization parameter for each containerized application instance is generated. Containerized application instances whose resource reservation comprehensive utilization rate parameter is lower than the preset lower limit threshold of resource utilization efficiency are marked as resource reservation over-application instances, and a list of resource reservation over-application instance identifiers is generated. Containerized application instances whose resource reservation utilization rate parameter is higher than the preset resource utilization efficiency upper limit threshold are marked as resource-insufficient application instances, and a list of resource-insufficient application instance identifiers is generated. For each resource-insufficient application instance in the list of resource-insufficient application instance identifiers, the target node CPU reservation share parameter and the target node memory reservation share parameter corresponding to the resource-insufficient application instance in the dynamic binding relationship mapping set are reduced, and an adjusted dynamic binding relationship mapping set is generated. For each of the application instances with insufficient resource reservation in the list of application instances with insufficient resource reservation, add the target node CPU reservation share parameter and the target node memory reservation share parameter corresponding to the application instance with insufficient resource reservation in the adjusted dynamic binding relationship mapping set to generate a second-adjusted dynamic binding relationship mapping set. Based on the dynamically bound relationship mapping set after the second adjustment, a resource reservation adjustment instruction sequence is generated, and the resource reservation adjustment instruction sequence is sent to the container orchestration scheduler of the industrial cloud platform to update the resource quota configuration of each containerized application instance on the target physical computing node.

8. The method for dynamic scheduling of computing resources in an industrial cloud platform combined with deep learning according to claim 7, characterized in that, The method further includes: Obtain the set of actual request-response time series parameters for each containerized application instance after resource reservation adjustments are completed; Extract the request-response latency boundary parameters for each containerized application instance from the set of service quality sensitivity descriptors; For each containerized application instance, calculate the average actual request response time parameter in the actual request response time series parameter set to obtain the average request response time parameter for each containerized application instance. Compare the average request response time parameter with the request response latency boundary parameter to generate a latency boundary deviation parameter for each containerized application instance. For containerized application instances whose latency boundary deviation parameter exceeds a preset deviation tolerance threshold, mark them as service quality breach application instances and generate a service quality breach application instance identifier list. For each service quality breach application instance in the service quality breach application instance identifier list, obtain the request arrival quantity prediction parameter in the predicted request time-series distribution set and the actual CPU usage parameter in the actual resource usage parameter set for the service quality breach application instance, and generate a request resource mapping relationship data pair for the service quality breach application instance. The request resource mapping relationship data of all the service quality default application instances in the service quality default application instance identifier list are used to train the input deep learning resource demand calibration network. The deep learning resource demand calibration network takes the request arrival quantity prediction parameter as input feature and the actual central processing unit usage parameter as output target, and updates the network weight parameters of the deep learning resource demand calibration network. The updated deep learning resource demand calibration network is used to re-predict the request arrival quantity prediction parameters for all containerized application instances in the predicted request time-series distribution set, generating a calibrated set of predicted CPU demand parameters. This calibrated set of predicted CPU demand parameters is then used as the basis for updating the preset basic CPU demand parameters in the next scheduling cycle, generating updated preset basic CPU demand parameters, and storing them in the configuration database of the industrial cloud platform.

9. The method for dynamic scheduling of computing resources in an industrial cloud platform combined with deep learning according to claim 1, characterized in that, The method further includes: Obtain a long-term operation log data set of multiple containerized application instances deployed in an industrial cloud platform. The long-term operation log data set includes time-series parameters of the number of historical requests arriving, the number of historical CPU usage, and the number of historical memory usage for each containerized application instance in multiple scheduling cycles. Extract the historical request arrival time series parameters and the historical CPU usage time series parameters for each containerized application instance from the long-term operation log data set, and construct a historical association dataset of request resource consumption for each containerized application instance. The historical data set of request resource consumption for each containerized application instance is segmented by a time-series sliding window to generate multiple request resource consumption sub-datasets corresponding to the time-series windows. For each time series window, the Pearson correlation coefficient between the historical request arrival quantity time series parameter and the historical CPU usage time series parameter is calculated, and the request resource consumption correlation strength parameter for each time series window is generated. Based on the changing trends of the request resource consumption correlation strength parameters in multiple time windows of each containerized application instance, the request resource consumption correlation mode type of each containerized application instance is identified. The request resource consumption correlation mode type includes stable correlation type, periodic fluctuation correlation type and sudden impact correlation type. For containerized application instances whose request resource consumption association mode type is the stable association type, a linear regression algorithm is used to fit the linear relationship between the historical request arrival time series parameters and the historical CPU usage time series parameters of the containerized application instance, thereby generating a stable resource demand function for the containerized application instance. For containerized application instances whose request resource consumption correlation pattern type is the periodic fluctuation correlation type, the Fourier series fitting algorithm is used to decompose the periodic components of the historical request arrival quantity time series parameters and the historical CPU usage time series parameters of the containerized application instance to generate the periodic resource demand function of the containerized application instance. For containerized application instances whose request resource consumption correlation mode type is the sudden impact correlation type, the quantile regression algorithm is used to fit the CPU usage parameter conditional distribution of the containerized application instance under different request arrival quantile conditions, and the sudden resource demand function of the containerized application instance is generated. The stable resource demand function, the periodic resource demand function, and the bursty resource demand function are used as personalized resource demand prediction models for each containerized application instance and stored in the model library of the industrial cloud platform.

10. A dynamic scheduling system for computing resources in an industrial cloud platform that incorporates deep learning, characterized in that, The invention includes a processor and a computer-readable storage medium storing machine-executable instructions, which, when executed by the processor, implement the dynamic scheduling method for industrial cloud platform computing resources incorporating deep learning as described in any one of claims 1-9.

Images