Cluster resource scheduling method and device, equipment, medium and product

Abstract

The application provides a cluster resource scheduling method and device, equipment, medium and product, relates to the technical field of cloud computing, and the method comprises the following steps: periodically collecting monitoring indexes of a plurality of nodes in a first cluster, the nodes are used for executing online micro-service business and / or large model training tasks, the monitoring indexes are related to resources used by the nodes and / or services provided by the nodes; according to the monitoring indexes and dynamic heterogeneous graph data of the first cluster, the cluster state of the first cluster is predicted for multiple time steps to obtain a prediction result; the dynamic heterogeneous graph data is used for representing real-time relationships between the nodes in the first cluster; the prediction result is input into a multi-agent collaborative decision-making framework to obtain a joint action; the joint action is used for realizing multi-objective dynamic balance of training task efficiency optimization and SLA guarantee of micro-service of the first cluster; and resource scheduling is performed according to the joint action, so that the resource scheduling meets the high-throughput demand of the training task and the low-latency requirement of the micro-service.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a cluster resource scheduling method, apparatus, equipment, medium and product. Background Technology

[0002] Currently, in cloud-native clusters that support the hybrid deployment of large model training and microservice business, static scheduling strategies or reactive scheduling strategies are generally used to schedule the resources of nodes in the cluster. Specifically, the above scheduling strategies are usually based on the current instantaneous state and lack the ability to predict future resource needs, resulting in delayed scheduling decisions, mismatch between resource allocation and actual business rhythm, and because resource needs change dynamically, the above scheduling strategies are difficult to simultaneously meet the high throughput requirements of training tasks and the low latency requirements of microservices. Summary of the Invention

[0003] This application provides a cluster resource scheduling method, apparatus, device, medium, and product, which solves the problem that the current scheduling strategy is lagging behind, causing a mismatch between resource allocation and the actual business rhythm, and making it difficult to simultaneously meet the high throughput requirements of training tasks and the low latency requirements of microservices.

[0004] Firstly, to achieve the above objectives, embodiments of this application provide a cluster resource scheduling method, comprising:

[0005] Periodically collect monitoring metrics from multiple nodes within the first cluster. These nodes are used to execute online microservice business and / or large model training tasks. The monitoring metrics are related to the resources used by the nodes and / or the services provided by the nodes.

[0006] Based on the monitoring indicators and the dynamic heterogeneous graph data of the first cluster, the cluster state of the first cluster is predicted at multiple time steps to obtain the prediction results; wherein, the dynamic heterogeneous graph data is used to characterize the real-time relationship between the nodes in the first cluster.

[0007] The prediction results are input into a multi-agent collaborative decision-making framework to obtain a joint action output by the multi-agent collaborative decision-making framework; wherein, the joint action is used to achieve a multi-objective dynamic balance between optimizing the training task efficiency of the first cluster and ensuring the service level agreement (SLA) of the microservice.

[0008] Resource scheduling is performed based on the aforementioned joint action.

[0009] The step of predicting the cluster state of the first cluster at multiple time steps based on the monitoring indicators and the dynamic heterogeneous graph data of the first cluster to obtain the prediction result includes:

[0010] Based on the monitoring indicators, the dynamic heterogeneous graph data corresponding to the monitoring indicators are instantiated to obtain the time series graph set of the first cluster;

[0011] For each time series graph in the set of time series graphs, determine the implicit resource competition relationships between different containers associated with the node;

[0012] Based on the implicit resource competition relationship, the time series graph is semantically enhanced to obtain an enhanced time series graph;

[0013] Each of the time series augmentation maps is input into the spatiotemporal intelligent prediction engine to obtain the prediction result output by the spatiotemporal intelligent prediction engine; wherein, the spatiotemporal intelligent prediction engine is used to synchronously learn the spatial topological dependency and temporal evolution law of the first cluster based on the time series augmentation map, and to perform multi-time step prediction of the cluster state of the first cluster.

[0014] Specifically, determining the implicit resource competition relationships between different containers associated with the node for each time series graph in the time series graph set includes:

[0015] Containers located on the same node that share core resources and experience high loads within the same time window are identified as candidate container pairs.

[0016] Perform multidimensional correlation analysis on the candidate container pairs to obtain the correlation score of the candidate container pairs;

[0017] If the correlation score is greater than the correlation threshold, the dynamic competition intensity between containers within the candidate container pair is calculated based on the resource overlap, conflict, and load growth synchronization rate between containers within the candidate container pair; wherein, the implicit resource competition relationship is represented by the correlation score and the dynamic competition intensity.

[0018] The step of inputting each of the time series enhancement maps into the spatiotemporal intelligent prediction engine to obtain the prediction result output by the spatiotemporal intelligent prediction engine includes:

[0019] Data preprocessing is performed on each of the time series enhancement maps to obtain a fusion feature vector of a preset dimension corresponding to the enhancement degree of the time series;

[0020] Based on the fused feature vectors corresponding to each of the time series augmentation maps, the spatial feature vectors of each node are obtained by learning the spatial dependencies of nodes in the first cluster, and the temporal feature vectors of the nodes corresponding to the containers are obtained by learning the changes in the load, resources and competition of the containers over time.

[0021] The spatial feature vector and the temporal feature vector are spatiotemporally fused to obtain a spatiotemporally joint feature vector;

[0022] The spatiotemporal joint feature vector is input into a bidirectional long short-term memory network (LSTM) for recursive prediction to obtain prediction results for multiple time steps of the first cluster. The prediction results for each time step include resource status, business indicators, competitive situation, and risk probability.

[0023] The step of inputting the prediction result into a multi-agent collaborative decision-making framework to obtain the joint action output by the multi-agent collaborative decision-making framework includes:

[0024] For each agent in the multi-agent collaborative decision-making framework, a first intention vector is generated based on the agent's local observation results, the prediction results, and the pre-set original intention items. The first intention vector is then sent to other agents in the multi-agent collaborative decision-making framework, and a second intention vector sent by the other agents is received.

[0025] Based on the local observation results and the second intent vector, a first action is generated through a policy network;

[0026] The joint action is obtained based on the first action generated by each of the aforementioned agents.

[0027] The method further includes:

[0028] For each agent, a global state vector is constructed based on the agent's local observations and the prediction results.

[0029] Based on the global state vector, the long-term benefit of the joint action is evaluated to obtain the evaluation value;

[0030] The risk score of the joint action is determined using an SLA risk sensor.

[0031] Based on the execution effect of the joint action and the risk score, a multi-objective dynamic weighted reward score is determined; wherein, the execution effect includes training progress, microservice latency, resource utilization, and energy efficiency.

[0032] The global state vector, the joint action, the multi-objective dynamic weight scoring, the global state vector of the next time step, the first intention vector, and the second intention vector are stored in the experience replay pool.

[0033] The parameters are updated using the data in the experience replay pool.

[0034] The step of performing resource scheduling based on the joint action includes:

[0035] Based on the combined action, obtain the operation sequence corresponding to the combined action;

[0036] Based on the current state of the cluster and the prediction results, the impact of the operation sequence on preset metrics of the cluster is evaluated in a simulation environment; wherein, the preset metrics include resource utilization, microservice latency, training iteration speed, and SLA violation probability.

[0037] If the evaluation results meet the preset evaluation conditions, the operation sequence is subjected to legality verification, resource feasibility verification, and resource reservation.

[0038] If the operation sequence is valid, resources are feasible, and resource reservation meets preset conditions, the nodes in the first cluster are scheduled to perform resource allocation by executing each operation in the operation sequence according to the priority of the operation sequence.

[0039] The method further includes:

[0040] The multi-agent cooperative decision-making framework is simulated and learned online using at least one of the following methods:

[0041] Simulation pre-verification;

[0042] Shadow mode virtual execution verification;

[0043] Security gray-scale deployment verification;

[0044] Strategy competition validation.

[0045] Secondly, to achieve the above objectives, embodiments of this application provide a cluster resource scheduling apparatus, comprising:

[0046] The data collection module is used to periodically collect monitoring metrics of multiple nodes within the first cluster. These nodes are used to execute online microservice business and / or large model training tasks. The monitoring metrics are related to the resources used by the nodes and / or the services provided by the nodes.

[0047] The prediction module is used to predict the cluster state of the first cluster at multiple time steps based on the monitoring indicators and the dynamic heterogeneous graph data of the first cluster, and obtain the prediction result; wherein, the dynamic heterogeneous graph data is used to characterize the real-time relationship between the nodes in the first cluster.

[0048] The decision module is used to input the prediction results into the multi-agent collaborative decision framework to obtain the joint action output by the multi-agent collaborative decision framework; wherein, the joint action is used to achieve a multi-objective dynamic balance between optimizing the training task efficiency of the first cluster and ensuring the service level agreement (SLA) of the microservice.

[0049] An execution module is used to perform resource scheduling based on the joint action.

[0050] Thirdly, to achieve the above objectives, embodiments of this application provide a cluster resource scheduling device, including a transceiver, a processor, a memory, and a program stored in the memory and executable on the processor. The transceiver is used to send and receive data under the control of the processor, and the processor implements the cluster resource scheduling method as described in the first aspect when executing the program.

[0051] Fourthly, to achieve the above objectives, embodiments of this application provide a readable storage medium having a program or instructions stored thereon, which, when executed by a processor, implement the cluster resource scheduling method as described in the first aspect.

[0052] Fifthly, to achieve the above objectives, embodiments of this application provide a computer program product including computer instructions that, when executed by a processor, implement the cluster resource scheduling method as described in the first aspect.

[0053] The beneficial effects of the above technical solution in this application are as follows:

[0054] In an embodiment of this application, firstly, monitoring metrics of multiple nodes within a first cluster are periodically collected. These nodes are used to execute online microservice business and / or large model training tasks, and the monitoring metrics are related to the resources used by the nodes and / or the services provided by the nodes. Secondly, based on the monitoring metrics and the dynamic heterogeneous graph data of the first cluster, the cluster state of the first cluster is predicted at multiple time steps to obtain prediction results. The dynamic heterogeneous graph data is used to characterize the real-time relationships between the nodes in the first cluster. Thirdly, the prediction results are input into a multi-agent collaborative decision-making framework to obtain joint actions output by the framework. These joint actions are used to achieve a multi-objective dynamic balance between optimizing the training task efficiency of the first cluster and ensuring the service level agreement (SLA) of the microservices. Finally, resource scheduling is performed based on the joint actions. In this way, we can realize decision-making based on forward-looking prediction results and actions related to cluster resource scheduling, which solves the problem of decision lag in decision-making based on the current instantaneous state of the cluster. Furthermore, the joint action decision-making based on the multi-agent system framework ensures that the joint action not only considers the efficiency of the training task, but also the SLA of the microservice, so as to ensure that the resource scheduling based on joint actions can meet the high throughput requirements of the training task and the low latency requirements of the microservice. Attached Figure Description

[0055] Figure 1 This is a flowchart illustrating the cluster resource scheduling method according to an embodiment of this application;

[0056] Figure 2 This is a flowchart illustrating the multi-time-step prediction of the state of the first cluster in an embodiment of this application.

[0057] Figure 3 A schematic diagram illustrating the overall architecture of the cluster resource scheduling method in this application embodiment;

[0058] Figure 4 This is a schematic diagram of the cluster resource scheduling device according to an embodiment of this application;

[0059] Figure 5 This is a schematic diagram of the cluster resource scheduling device according to an embodiment of this application. Detailed Implementation

[0060] To make the technical problems, technical solutions and advantages of this application clearer, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments.

[0061] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0062] In the various embodiments of this application, it should be understood that the sequence number of each process described below does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0063] In addition, the terms "system" and "network" are often used interchangeably in this article.

[0064] In the embodiments provided in this application, it should be understood that "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A, but can also be determined based on A and / or other information.

[0065] Before describing the embodiments of this application, the relevant technical points will first be described by way of example:

[0066] The existing resource scheduling methods have the following problems:

[0067] I. Decoupling of prediction and scheduling, resulting in insufficient forward-looking decision-making: Existing systems typically separate the resource prediction module from the scheduling decision-making module. The scheduling decision-making module only makes reactive decisions based on historical or current instantaneous states, and cannot make forward-looking resource reservations and adjustments based on predictions of future multi-step states. This leads to the inability to optimize resource layout in advance before business peaks or critical training phases.

[0068] Second, there is a lack of explicit modeling for the competitive relationship between mixed loads: Large-scale model training (computationally intensive, long-cycle, elastic demand) and online microservices (latency-sensitive, short-cycle, stable demand) have fundamentally different resource usage patterns and dynamic competitive relationships. Existing methods do not explicitly model this competitive game process, resulting in scheduling strategies lacking theoretical basis when balancing the two types of tasks and easily getting trapped in local optima.

[0069] Third, single-objective optimization makes it difficult to take into account multiple dimensions of Service Level Agreement (SLA): Existing scheduling strategies often aim to maximize resource utilization or minimize the completion time of a single task, failing to systematically incorporate multiple dimensions of SLA indicators such as training task throughput, microservice latency, response time distribution, and resource efficiency into the optimization framework.

[0070] Fourth, the policy update mechanism is rigid and has poor environmental adaptability: the existing solution relies on manual rules or fixed models trained offline, which is difficult to adapt to the dynamically changing cluster environment, the constantly evolving workload characteristics and sudden business scenario switching, and lacks the ability to learn online and iterate security policies.

[0071] In view of this, embodiments of this application provide a cluster resource scheduling method, such as... Figure 1 As shown, the method includes:

[0072] Step 101: Periodically collect monitoring metrics of multiple nodes in the first cluster. The nodes are used to execute online microservice business and / or large model training tasks. The monitoring metrics are related to the resources used by the nodes and / or the services provided by the nodes.

[0073] It should be noted that the first cluster mentioned above is a cloud-native cluster that supports the hybrid deployment of large model training and microservice business.

[0074] It should also be noted that the aforementioned nodes can be understood as resource nodes related to online microservice business and large model training tasks, including physical nodes, container (Pod) nodes, virtual nodes, etc. Among them, virtual nodes can also be referred to as virtual resource pools.

[0075] For example, the resource-related metrics among the monitoring metrics mentioned above include, but are not limited to, at least one of the following: Central Processing Unit (CPU) utilization, Graphics Processing Unit (GPU) utilization, memory utilization, etc.

[0076] Among the monitoring indicators mentioned above, those related to the services provided by the nodes can also be called service-level indicators. Service-level indicators typically refer to the quality of service (QoS) indicators of services, microservice instances, and service call chains, such as latency, throughput, error rate, and P99. These indicators are derived from services.

[0077] It should be noted that the aforementioned periodic collection and monitoring indicators can also be understood as real-time collection of the aforementioned monitoring indicators.

[0078] Step 102: Based on the monitoring indicators and the dynamic heterogeneous graph data of the first cluster, predict the cluster state of the first cluster at multiple time steps to obtain the prediction result; wherein, the dynamic heterogeneous graph data is used to characterize the real-time relationship between the nodes in the first cluster.

[0079] It should be noted that the above monitoring indicators correspond to the dynamic heterogeneity graph data. For example, the above dynamic heterogeneity graph data is the dynamic heterogeneity graph data of the first cluster when the above detection indicators are collected.

[0080] The predicted cluster status of the first cluster can include resource requirements and business status, which can be characterized by resource status, business indicators, competitive landscape, and risk probability. In other words, step 102 above is to predict the resource requirements and business status of the first cluster at multiple time steps based on monitoring indicators and the dynamic heterogeneous graph data corresponding to the monitoring indicators.

[0081] The aforementioned dynamic heterogeneous graph data includes, for example, graph data comprising node sets, edge sets, node attributes, and edge attributes. Taking Kubernetes (K8s) as an example, the construction process of dynamic heterogeneous graph data is illustrated as follows: First, entities such as nodes, Pods, and services are automatically discovered through the K8s Application Programming Interface (API). The cluster state at time t is defined as the dynamic heterogeneous graph, specifically using the formula... It means that, among them:

[0082] Node set Physical nodes (Node), Pod nodes (Pod), and virtual nodes (virtual resource pool);

[0083] edge set Physical connection edges (network topology), logical dependency edges (service call chain), and resource contention edges (dynamic calculation);

[0084] Node attributes : CPU utilization (0-100%), GPU memory usage (GB), memory utilization (0-100%), disk I / O (MB / s), network bandwidth (Gbps), task type (training / microservice), SLA level (high / medium / low);

[0085] edge attributes Network latency (ms), bandwidth usage (Gbps), and resource contention intensity (0-1, quantified value).

[0086] Step 103: Input the prediction result into the multi-agent collaborative decision-making framework to obtain the joint action output by the multi-agent collaborative decision-making framework; wherein, the joint action is used to achieve a multi-objective dynamic balance between optimizing the training task efficiency of the first cluster and ensuring the service level agreement (SLA) of the microservice.

[0087] For example, the above-mentioned multi-agent collaborative decision-making framework includes at least a training task optimization agent. T and Microservices Assurance Agent S This allows for a comprehensive consideration of both the high throughput requirements of the training task and the low latency requirements of the microservice when making decisions.

[0088] It should be noted that the aforementioned joint actions include actions output by multiple agents.

[0089] Step 104: Perform resource scheduling according to the joint action.

[0090] In an embodiment of this application, firstly, monitoring metrics of multiple nodes within a first cluster are periodically collected. These nodes are used to execute online microservice business and / or large model training tasks, and the monitoring metrics are related to the resources used by the nodes and / or the services provided by the nodes. Secondly, based on the monitoring metrics and the dynamic heterogeneous graph data of the first cluster, the cluster state of the first cluster is predicted at multiple time steps to obtain prediction results. The dynamic heterogeneous graph data is used to characterize the real-time relationships between the nodes in the first cluster. Thirdly, the prediction results are input into a multi-agent collaborative decision-making framework to obtain joint actions output by the framework. These joint actions are used to achieve a multi-objective dynamic balance between optimizing the training task efficiency of the first cluster and ensuring the service level agreement (SLA) of the microservices. Finally, resource scheduling is performed based on the joint actions. In this way, we can realize decision-making based on forward-looking prediction results and actions related to cluster resource scheduling, which solves the problem of decision lag in decision-making based on the current instantaneous state of the cluster. Furthermore, the joint action decision-making based on the multi-agent system framework ensures that the joint action not only considers the efficiency of the training task, but also the SLA of the microservice, so as to ensure that the resource scheduling based on joint actions can meet the high throughput requirements of the training task and the low latency requirements of the microservice.

[0091] As an optional implementation, step 102 above, based on the monitoring indicators and the dynamic heterogeneous graph data of the first cluster, performs multi-time-step prediction of the cluster state of the first cluster to obtain the prediction result, including:

[0092] Step A1: Instantiate the dynamic heterogeneous graph data corresponding to the monitoring indicators according to the monitoring indicators to obtain the time series graph set of the first cluster; wherein, the graph instantiation in this step may include: instantiating nodes and edges to calculate derived attributes; and data verification and anomaly recovery.

[0093] For example, step A1 above includes:

[0094] Step A11: Perform local preprocessing on the distributed monitoring data: First, collect multi-dimensional metrics at the node / Pod / service level, where the collection frequency is dynamically configurable; second, implement local preprocessing through an edge proxy.

[0095] Step A12: Instantiate nodes and edges, and calculate derived attributes:

[0096] Static edges (such as network topology) are initially cached, while dynamic edges (such as contested edges) are calculated in real time.

[0097] Derived attribute calculation: Node resource remaining amount (total resources - used resources), edge communication frequency (number of data interactions per unit time).

[0098] Step A13, Data Validation and Anomaly Recovery:

[0099] The 3σ criterion is used to detect outliers, and alarms are triggered when values ​​exceed the threshold continuously.

[0100] Missing values ​​are filled by linear interpolation or prediction using a Long Short-Term Memory (LSTM) network.

[0101] Step A14: Output a set of time series graphs. Each of them It provides a complete snapshot of the cluster state and supports backtracking operations by timestamp.

[0102] Step A2: For each time series graph in the time series graph set, determine the implicit resource competition relationship between different containers related to the node;

[0103] Optionally, step A2 above includes the following sub-steps:

[0104] Step A21: Containers that share core resources and are under high load within the same time window are identified as candidate container pairs.

[0105] In other words, step A21 above is for screening candidate Pod pairs. Specifically, it involves screening candidate Pod pairs based on three dimensions: space (same node / resource pool), resources (shared core resources), and business (high load during the same time period). For example, a sliding window can be managed to screen candidate Pod pairs from these three dimensions. For instance, the window size and step size can be set, data standardization and smoothing can be performed, and candidate Pod pairs can be screened based on the processed data. That is to say, when all three conditions are met—using the same node / resource pool, sharing core resources, and experiencing high load within the same time window—real resource competition will occur between Pods. Therefore, candidate Pod pairs with resource competition can be screened comprehensively from the three dimensions of space, resources, and business.

[0106] Step A22: Perform multidimensional correlation analysis on the candidate container pairs to obtain the correlation score of the candidate container pairs;

[0107] For example, the multidimensional correlation analysis mentioned above can be quantified by using a weighted fusion algorithm (Pearson correlation coefficient 0.4 + Granger causality test 0.3 + mutual information 0.3).

[0108] Step A23: If the correlation score is greater than the correlation threshold, calculate the dynamic competition intensity between containers within the candidate container pair based on the resource overlap, conflict degree, and load growth synchronization rate between containers within the candidate container pair; wherein, the implicit resource competition relationship is represented by the correlation score and the dynamic competition intensity.

[0109] It should be noted that the above dynamic competition intensity calculation can be implemented according to the following formula:

[0110]

[0111] in, 1, and the default values ​​for the three weights are 0.5, 0.3, and 0.2, respectively;

[0112] Resource overlap = Number of shared resource types / Total number of resource types;

[0113] Load growth synchronization rate: ;in, This represents the load growth rate.

[0114] Conflict level: 1 - (low priority task SLA threshold / high priority task SLA threshold).

[0115] Step A3: Based on the implicit resource competition relationship, perform semantic relationship enhancement on the time series graph to obtain a time series enhanced graph;

[0116] It should be noted that the aforementioned semantic relationship enhancement can be achieved through competitive edge construction and topological analysis, for example:

[0117] Competition edge instantiation: S≥ (Constructing competing edges), S< (Remove competing edges) ≤S< (Marked as "potential competing edge").

[0118] Among them, a dynamic update mechanism can be set, such as updating edge attributes every 10 seconds and re-filtering candidate Pod pairs every 60 seconds;

[0119] Dynamic update mechanism:

[0120] Analyze competitive topology and hotspots: Identify competitive hotspot nodes (connected with ≥5 competitive edges and average S ≥0.6), competitive chains (Pod1-Pod2-Pod3 forming a chain of competition), etc.

[0121] It should be noted that the time series augmented graph obtained using the above steps can include dynamic heterogeneous graph data, a set of competing edges, and a competition analysis summary (including hot nodes, competing Pod pairs, and risk warnings). That is: Augmented Graph = Base Graph + Set of Competing Edges + Competition Analysis Summary (including hot nodes, competing Pod pairs, and risk warnings).

[0122] Step A4: Input each of the time series augmentation maps into the spatiotemporal intelligent prediction engine to obtain the prediction results output by the spatiotemporal intelligent prediction engine; wherein, the spatiotemporal intelligent prediction engine is used to synchronously learn the spatial topological dependencies and temporal evolution patterns of the first cluster based on the time series augmentation maps, and to perform multi-time-step prediction of the cluster state of the first cluster. In this way, multi-step forward-looking prediction can be achieved.

[0123] It should be noted that the aforementioned spatiotemporal intelligent prediction engine could, for example, be a Spatio-Temporal Graph Neural Network (ST-GNN) specifically designed for cloud-native hybrid clusters. Its core is to simultaneously learn spatial topological dependencies and temporal evolution patterns on an augmented graph sequence containing competing semantics through an "encode-decode" architecture, enabling forward-looking predictions of the cluster's state over multiple future steps. The model is optimized using composite loss to ensure accurate predictions, temporal stability, and spatial reasonableness, providing forward-looking insights with interpretable motivations.

[0124] It should also be noted that the above-mentioned time evolution pattern refers to the changes in load, resources, and competition of nodes / Pods over time.

[0125] As a specific implementation, step A4 above involves inputting each of the time series enhancement maps into the spatiotemporal intelligent prediction engine to obtain the prediction results output by the spatiotemporal intelligent prediction engine, including:

[0126] Step A41: Perform data preprocessing on each of the time series enhancement maps to obtain a fusion feature vector of a preset dimension corresponding to the time series enhancement degree.

[0127] It should be noted that the above data preprocessing includes:

[0128] Graph sequence alignment and completion: Aligning an enhanced graph across T historical time steps, where missing data is completed using forward padding and graph interpolation;

[0129] Multi-level feature engineering: Integrating original features, temporal features (mean, variance), and interaction features (node-edge feature product), unifying the dimensions to a preset dimension, such as 64 dimensions. Among them, the original features mentioned above are the node attributes and edge attributes in the aforementioned dynamic heterogeneous graph data, the temporal features mentioned above are the mean, variance, etc. of the features in the graphs enhanced for different time series, and the interaction features mentioned above are the node-edge feature product.

[0130] Step A42: Based on the fusion feature vectors corresponding to each of the time series augmentation maps, obtain the spatial feature vector of each node by learning the spatial dependency relationship of the nodes in the first cluster, and obtain the temporal feature vector of the node corresponding to the container by learning the changes in the load, resources and competition of the container over time.

[0131] Specifically, step A42 above can involve performing spatial graph convolution on each fused feature vector using a spatiotemporal intelligent prediction engine to obtain spatial feature vectors, and performing temporal convolution on these fused feature vectors to obtain temporal feature vectors. More specifically, step A42 includes:

[0132] Input: A dynamic graph sequence of T historical time steps { The T fused feature vectors corresponding to} (default T=96).

[0133] Spatial Graph Convolution (R-GAT):

[0134] Capture the spatial dependencies in the cluster topology (connections, dependencies, and resource contention between nodes). Specifically:

[0135] 1) Use relation-aware graph attention to model different edge types (physical edges, dependent edges, competing edges);

[0136] 2) According to the formula Calculate the attention weights of competing edges

[0137] Where S represents the intensity of competition; Here, b is the sigmoid function; W is the weight matrix, and b is the bias term; , These are the feature vectors of source node i and target node j after being transformed by the previous neural network layer.

[0138] 3) The spatial feature output of each node is a weighted sum of the features of its neighboring nodes. The number of attention heads is set to 8, and the output dimension is 64.

[0139] Temporal Convolution (TCN):

[0140] 1) Capture the changing patterns of load, resources, and competition over time.

[0141] 2) Employ causal dilated convolution, with dilation coefficients... ( The number of layers, such as l= The kernel size is 3, the activation function is GELU, and the output dimension is 64.

[0142] Step A43: Perform spatiotemporal fusion on the spatial feature vector and the temporal feature vector to obtain a spatiotemporal joint feature vector.

[0143] It should be noted that the above spatiotemporal fusion can be designed using a gated recurrent unit (GRU), and the spatiotemporal fusion feature (the final output fusion vector) can be represented as:

[0144]

[0145] Where Sfeat is the spatial convolution output and Tfeat is the temporal convolution output. To dynamically balance the spatiotemporal feature weights, This is a bias term used for model fitting and adjusting the activation threshold;

[0146] It should be noted that steps A42 and A43 above are implemented by the ST-GNN encoder, that is, the encoder encodes the preprocessed dynamic graph sequence into unified features rich in spatiotemporal dependencies. The structure of the encoder is: stacking 3 layers of ST-GNN (each layer contains a Graph Attention Network (GAT) and a Temporal Convolutional Network (TCN)).

[0147] Step A44: Input the spatiotemporal joint feature vector into a bidirectional long short-term memory network (LSTM) for recursive prediction to obtain prediction results for multiple time steps of the first cluster. The prediction results for each time step include resource status, business indicators, competitive situation, and risk probability.

[0148] It should be noted that step A44 above is implemented by the ST-GNN decoder, where the decoder structure is: bidirectional LSTM (2 layers, 128-dimensional hidden layer) + fully connected network.

[0149] It should also be noted that the above recursive prediction specifically uses an "encoder-decoder" structure, combined with autoregression and Teacher Forcing mechanisms to generate predictions for the next H steps (default H=12);

[0150] The above prediction results are prediction outputs for multiple tasks, that is, simultaneously predicting four types of indicators: resource status (CPU / GPU / memory utilization), business indicators (training iteration speed, microservice latency), competitive situation (changes in competitive edge intensity, migration of hot nodes), and risk probability (SLA violation probability, resource exhaustion probability).

[0151] Optionally, the uncertainty of the forecast can be quantified, for example, by using Monte Carlo Dropout to calculate the confidence interval and risk level (low / medium / high). In other words, the above forecast results also include confidence intervals and risk levels.

[0152] Further, optionally, to improve prediction accuracy, the spatiotemporal intelligent prediction engine can undergo model training and online adaptive learning. For example, the spatiotemporal intelligent prediction engine can be trained periodically, or it can be trained online adaptively. This can be optimized based on a multi-task loss function, which can be specifically expressed as:

[0153]

[0154] in, : Weighted sum of mean squared errors for each prediction task (resource prediction weights) Business indicators Competitive Landscape Risk probability );

[0155] Smoothness penalty (weight β=0.1);

[0156] ( (Graph adjacency matrix): Graph regularization penalty (weight γ = 0.05);

[0157] : Represents the model's predicted output at time step t.

[0158] The offline pre-training process involved using 3 months of historical cluster data, with a batch size of 32 and an optimizer of AdamW (learning rate = e^(-1 / 2)). -4 Weight decay = e -5 Training rounds = 100;

[0159] Online adaptive training (also known as online incremental learning): triggered when the prediction error exceeds the threshold (0.05) for 5 consecutive steps or the topological change rate is ≥30%, the top-level parameters are updated in mini batches.

[0160] Therefore, the method in this application embodiment further includes:

[0161] The prediction error of the prediction result is calculated, and if the prediction error meets the preset conditions, the spatiotemporal intelligent prediction engine is subjected to online incremental learning.

[0162] The prediction process described in this application embodiment can be applied to the following scenarios:

[0163] Scenario 1: Preventive resource isolation and layout based on competition prediction:

[0164] Mechanism: ST-GNN predicts intense resource contention between Pods that will occur within the next few minutes. The scheduling system can then proactively intervene based on this prediction, scheduling Pods with strong contention predictions to different physical nodes or resource domains before the contention erupts, achieving "preemptive departure before contention."

[0165] Value: Fundamentally avoids performance jitter and SLA violations caused by resource contention.

[0166] Scenario 2: Dynamic resource allocation arbitration under multi-objective constraints:

[0167] Mechanism: ST-GNN provides joint state predictions for multiple future steps (training progress, service latency, resource utilization). Scheduling decisions are based on this panoramic view, with real-time online trade-offs and arbitration.

[0168] Value: When predicting service latency security, resources are allocated to training to optimize efficiency; once an SLA risk is predicted, the strategy is immediately switched to prioritize service protection, achieving dynamic balance and global optimization of multi-dimensional business objectives.

[0169] Intelligent decision-making to guide cluster scaling and Pod migration

[0170] Mechanism: ST-GNN can predict the location, intensity, and duration of future resource bottlenecks. This provides a direct basis for cost-optimal scaling up and down of the cluster (e.g., choosing Pod migration instead of immediate scaling up for short-term bottlenecks).

[0171] Value: The model can recommend the optimal target node for Pods to be migrated, that is, select the node with the least competition and the best match in terms of load and resources in the prediction, thereby improving the success rate and effectiveness of migration decisions.

[0172] Output: Structured prediction results, including node status, competitive hotspots, risk probability and confidence level, which can be exported in JSON format for direct use by decision-makers.

[0173] Below, in conjunction with Figure 2 The above prediction process will be explained.

[0174] like Figure 2 As shown, the prediction process includes the following three steps:

[0175] Step 1: The cluster graph modeling module (structured abstraction engine) performs two stages: cluster topology discovery and pattern definition, and real-time data acquisition and graph instantiation. Cluster topology discovery and pattern definition correspond to the aforementioned automated discovery of entities such as nodes, Pods, and services via the Kubernetes API. The cluster state at time t is defined as a dynamic heterogeneous graph. Real-time data acquisition and graph instantiation correspond to the aforementioned steps of distributed acquisition, instantiating node and edge derived attributes, data verification, and anomaly recovery.

[0176] Step 2: The resource competition edge dynamic calculation module (semantic relation enhancer) performs competition candidate analysis and data preparation (corresponding to the aforementioned step A21), competition relation quantification calculation (corresponding to the aforementioned steps A22 and A23), and competition edge construction and topology analysis (corresponding to the aforementioned step A3).

[0177] Step 3: The ST-GNN predictor (spatiotemporal intelligent prediction engine) performs the following: input data processing (corresponding to step A41 above), forward propagation of the spatiotemporal graph neural network (corresponding to steps A42 and A43 above), multi-step prediction decoding and output (corresponding to step A44 above), and model training and online adaptation (corresponding to the aforementioned model training and online adaptation learning of the spatiotemporal intelligent prediction engine).

[0178] It should be noted that the aforementioned multi-agent collaborative decision-making framework realizes multi-agent collaboration and multi-objective optimization based on a deep reinforcement learning algorithm (Multi-Agent Soft Actor-Critic, MA-SAC). It constructs a framework comprising two specialized agents (the training task optimization agent). T With microservices as a guarantee agent S The collaborative decision-making layer of the multi-agent collaborative decision-making framework achieves a dynamic balance between optimizing training task efficiency and ensuring microservice SLA through a mechanism of division of labor, centralized evaluation, and entropy-driven exploration. To realize the decision-making function of the multi-agent collaborative decision-making framework, it is necessary to pre-design the multi-agent, the core components of the MA-SAC algorithm, and the multi-objective dynamic weight reward function, as detailed below:

[0179] (I) Pre-configuration of multi-agent design:

[0180] 1) The design and configuration of the training task optimization agent are shown in Table 1 below:

[0181] Table 1 Agent T Design and configuration examples

[0182]

[0183] 2) The design and configuration of the microservice guarantee agent are shown in Table 2 below:

[0184] Table 2 Agent S Design and configuration examples

[0185]

[0186] (II) Design of core components of the MA-SAC algorithm

[0187] 1) The network structure and functional design of the MA-SAC algorithm are shown in Table 3 below:

[0188] Table 3 Examples of MA-SAC Algorithm Network Structure and Functional Design

[0189]

[0190] 2) Optimize objectives and update mechanisms:

[0191] Maximum entropy reinforcement learning maximizes policy entropy while maximizing expected reward. Where:

[0192] The policy update objective can be expressed as:

[0193]

[0194] The policy gradient calculation can be expressed as:

[0195]

[0196] Q network update objective: Minimizing the Bellman error can be expressed as:

[0197]

[0198] Temperature parameter updates can be expressed as:

[0199]

[0200] 3) Experience replay mechanism:

[0201] Capacity: 1×10 6 One piece of experience;

[0202] Storage format: quintuple ( ),in This is the intent vector;

[0203] Sampling strategy: Priority sampling (priority = |TD error| + ε, ε = 1 × 10⁻) 6 );

[0204] Experience blending: 70% real-world experience + 30% simulation-world experience, improving strategy generalization;

[0205] Update trigger: Batch update is initiated when the replay pool data volume is ≥10000, with a batch size of 256.

[0206] It should be noted that the key parameters used in the various formulas of the MA-SAC algorithm are shown in Table 4 below:

[0207] Table 4. Examples of the meanings of key parameters in the formulas of the MA-SAC algorithm

[0208]

[0209] (III) Design of Multi-Objective Dynamic Weighted Reward Function:

[0210] 1) Reward function form

[0211] The reward function is designed as a weighted summation to adapt to cluster status and SLA risks in real time, as detailed below:

[0212]

[0213] 2) The calculation methods for each sub-item in the reward function are shown in Table 5 below:

[0214] Table 5 Examples of calculation methods for each item in the reward function

[0215]

[0216] 4) Dynamic weights Adjustment mechanism:

[0217] (1) The input features of the SLA risk sensor include: the SLA violation probability predicted by ST-GNN, the current SLA violation status, the peak business indicator (microservice traffic ≥ 80% of the threshold), and the key stage indicator of the training task (close to convergence in the later stage of iteration).

[0218] (2) The risk score calculation formula is as follows:

[0219]

[0220] in, This indicates the predicted probability of SLA violation; Indicates whether the SLA is currently in violation (yes = 1, no = 0); Indicates whether it is a peak business period (Yes = 1, No = 0); Indicates whether the critical phase has been trained (Yes = 1, No = 0); , , , This represents the risk weight.

[0221] The weighting adjustment rules are shown in Table 6 below:

[0222] Table 6 Examples of Weight Adjustment Rules

[0223]

[0224] The frequency of weight adjustment can be consistent with the ST-GNN prediction update frequency, for example, 10 seconds / time.

[0225] Based on this, as an optional implementation, step 103 above inputs the prediction result into a multi-agent collaborative decision-making framework to obtain the joint action output by the multi-agent collaborative decision-making framework, including:

[0226] Step B1: For each agent in the multi-agent collaborative decision-making framework, generate a first intent vector based on the agent's local observation results, the prediction results, and the pre-set original intent items; send the first intent vector to other agents in the multi-agent collaborative decision-making framework; and receive the second intent vector sent by the other agents.

[0227] It should be noted that the above local observation results are the results of the agent's observation according to the observation space in Tables 1 and 2 above, and the above original intention item corresponds to the original intention in Table 3 above.

[0228] In step B1 above, the agent uses the encoding network in Table 3 (the encoding network in the agent) to generate the corresponding intention vector. That is, the agent inputs its own observation results, the obtained prediction results and the original intention into the encoding network so that the encoding network can generate the intention vector.

[0229] Step B2: Based on the local observation results and the second intention vector, generate a first action through a policy network. Specifically, this step can be based on the policy network in Table 3, that is, input the local observation results and the second intention vector into the policy network so that the policy network can generate the corresponding first action.

[0230] Step B3: Obtain the joint action based on the first action generated by each of the intelligent agents.

[0231] Furthermore, based on the above-mentioned optional implementation methods, the method further includes:

[0232] Step B4: For each agent, construct a global state vector S based on the agent's local observations and predictions; optionally, step B4 can be performed before step B1.

[0233] Step B5 involves evaluating the long-term benefits of the joint action based on the global state vector to obtain an evaluation value; optionally, step B5 can be executed after step B3. This step can be implemented by the shared global critic network integrated into the Q-network as shown in Table 3.

[0234] Step B6: Using the SLA risk sensor, determine the risk score of the joint action; wherein, this step can be performed according to the aforementioned risk score calculation formula.

[0235] Step B7: Determine the multi-objective dynamic weighted reward score based on the execution effect of the joint action and the risk score; wherein, the execution effect includes training progress, microservice latency, resource utilization, and energy efficiency.

[0236] Step B8: Store the global state vector, the joint action, the multi-objective dynamic weight scoring, the global state vector of the next time step, the first intent vector, and the second intent vector into the experience replay pool.

[0237] Step B9: Update the parameters using the data in the experience replay pool.

[0238] The implementation process of an example of collaborative decision-making based on steps B1 to B9 above is as follows:

[0239] a) State awareness: Agent T and Agent S Collect and observe O separately T O S Receive the prediction results from ST-GNN and construct the global state S;

[0240] b) Intent Communication: The agent generates an intent vector M through an encoding network. T M S They send messages to each other and decode each other's intentions through the decoding network;

[0241] c) Action generation: Each agent generates actions based on its own observations. i and the other party's intention M -i Through policy network Generate action A T A S ;

[0242] d) Valuation: Critic Global Based on global state S and joint action (A) T A S Output Q global Value, to assess the long-term benefits of joint actions;

[0243] e) Reward Calculation: Based on the actual effect after the action is executed, and combined with the risk score output by the SLA risk sensor, calculate the dynamic weight. Total Rewards ;

[0244] f) Experience storage: [This will...] Store in the experience replay pool;

[0245] g) Model update: When the amount of data in the replay pool is sufficient, start batch update, and alternately update the policy network, Q network and temperature parameters;

[0246] h) Policy output: Combined action (A) T A S Submitted to the hierarchical execution layer for scheduling operations.

[0247] It should be noted that in practical applications, the results of steps d) and e) can be used to assist in deciding whether to output the final strategy.

[0248] It should also be noted that the above-mentioned multi-agent collaborative decision-making framework can be applied to the following scenarios:

[0249] Scenario 1: Dynamic priority arbitration between training tasks and microservices:

[0250] Scenario: When GPU resources are scarce, critical iterations of training tasks and peak requests for payment services occur simultaneously;

[0251] Collaboration mechanism:

[0252] Agent T (Training task) and Agent S (Microservices) exchange real-time intents through learnable communication mechanisms;

[0253] In Critic Global Guided by global optimization, dynamic priority solutions are collaboratively decided.

[0254] To achieve real-time arbitration with a theoretical basis, avoiding the lag and suboptimal nature of manual rules.

[0255] Scenario 2: Adaptive and coordinated response to sudden traffic surges and abnormal loads:

[0256] Scenario: A surge in microservice traffic is caused by trending events across the internet, and the business model is unknown and changing rapidly.

[0257] Collaboration mechanism:

[0258] Agent S The agent is the first to detect spikes in latency and increases in error rates, and communicates via vector vectors. T Issued a high-intensity "security request";

[0259] Agent T Based on this intention, actions that may exacerbate competition are dynamically suppressed, and degraded operations are proactively executed.

[0260] The maximum entropy framework ensures safe exploration in unknown scenarios and avoids catastrophic decisions.

[0261] Scenario 3: Distributed security exploration and execution of complex scheduling strategies:

[0262] Scenario: Executing complex scheduling involving multiple Pod migrations and resource quota adjustments, requiring the avoidance of cascading failures;

[0263] Collaboration mechanism:

[0264] Each agent performs atomic operations based on local observations and the interpretation of the high-level policy in a distributed manner.

[0265] The maximum entropy reinforcement learning framework encourages the exploration of multiple action combinations;

[0266] Critic Global Provides security value assessments and automatically avoids high-risk coordinated actions that could lead to overall collapse;

[0267] Intent communication mechanisms ensure the coordination and consistency of distributed execution.

[0268] As an optional implementation, step 104 above, which performs resource scheduling based on the joint action, includes:

[0269] Step C1: Obtain the operation sequence corresponding to the joint action based on the joint action;

[0270] The specific implementation of step C1 above can be as follows: First, the joint action output by the collaborative decision-making layer is translated into a "scheduling suggestion" through the policy interpreter. Second, based on the pre-set policy-operation mapping rule base, the high-level actions (such as Agent) output by MA-SAC are translated into a "scheduling suggestion". S The "Guarantee Service A latency < 200ms" is mapped to an ordered combination of K8s native API calls, i.e., an operation sequence.

[0271] Step C2: Based on the current state of the cluster and the prediction results, evaluate the impact of the operation sequence on preset indicators of the cluster in a simulation environment; wherein, the preset indicators include resource utilization, microservice latency, training iteration speed, and SLA violation probability;

[0272] Step C2 above involves rapidly rehearsing the operation sequence in a simulation environment based on a snapshot of the current cluster state and the predicted future state. For example, a lightweight simulator can be used to evaluate its expected impact on metrics such as resource utilization and service latency.

[0273] It should be noted that step C2 above can be implemented based on the constructed operation sandbox. The construction of the operation sandbox includes: creating a lightweight simulation environment consistent with production based on K8s virtual cluster technology; the sandbox data comes from the fusion of production snapshots (updated every 5 seconds) and ST-GNN prediction results.

[0274] Furthermore, the operation simulation and evaluation based on the operation sandbox includes: executing the mapped Kubernetes operation sequence in the sandbox, simulating cluster state changes 1-5 minutes after execution; evaluation metrics include resource utilization, microservice latency, training iteration speed, and SLA violation probability; if the evaluation metrics meet preset thresholds (e.g., latency reduction ≥ If there is no SLA violation, the pre-play will proceed; otherwise, policy backtracking will be triggered, and actions will be regenerated.

[0275] Step C3: If the evaluation results meet the preset evaluation conditions, perform legality verification, resource feasibility verification, and resource reservation on the operation sequence.

[0276] It should be noted that the above-mentioned legality verification can be: calling the API Server through the K8s DryRun mode to verify the syntax legality and permission compliance of the operation; the above-mentioned resource feasibility verification is: checking whether the target node resources meet the requirements and whether they violate the resource quota through a custom admission controller Webhook; resource reservation specifically means: reserving necessary resources through ResourceQuota for critical operations (such as Pod creation and resource adjustment), with a reservation validity period of 30 seconds.

[0277] Step C4: If the operation sequence is valid, resources are feasible, and resource reservation meets preset conditions, the nodes in the first cluster are scheduled to perform resource allocation by executing each operation in the operation sequence according to the priority of the operation sequence.

[0278] In other words, step C4 above will only be executed after the pre-commit is successful and the sandbox evaluation meets the requirements. The operation sequence is executed in batches. Specifically, the operation sequence is divided into core operations (such as resource reservation and replica number adjustment) and non-core operations (such as Pod migration and priority adjustment) according to priority. Core operations are executed first, and non-core operations are executed after successful execution.

[0279] Optionally, a rollback trigger can be bound to each operation sequence. The triggering conditions for the rollback trigger include: the metric does not meet expectations after execution (such as the latency increasing instead of decreasing), SLA violation occurs, and the cluster state is abnormal (such as node crash or Pod startup failure). The rollback operation is executed automatically, restoring the state to the state before the operation.

[0280] It should be noted that steps C3 and C4 above can be understood as a two-phase commit operation sequence, which includes a pre-commit phase and a formal commit phase. Step C3 corresponds to the pre-commit phase, and step C4 corresponds to the formal commit phase. Step C3 can output whether the pre-commit was successful or failed. If the pre-commit fails, it can also return a specific reason, such as insufficient resources or insufficient permissions.

[0281] As an example, the above optional implementation can be specifically implemented by a custom scheduler and controller (Operator), where the custom scheduler and operator include:

[0282] The intelligent scheduler plugin is integrated as follows: based on the Kubernetes scheduling framework, it develops PreFilter, Filter, Score, Reserve, and Permit extension point plugins. The scheduling logic of this plugin is as follows: First, it performs secondary optimization by combining the scheduling suggestions output by the policy interpreter (such as node preference lists and resource binding priorities) with the default Kubernetes scheduling policies (such as node affinity and taint tolerance). Second, it performs weight allocation in the scoring phase: the decision-making layer suggests (…). ) + Default Metrics ( In addition, this intelligent scheduler plugin also supports real-time adjustment of scheduling plugin parameters (such as weight ratio and filtering threshold) without restarting the scheduler.

[0283] The hybrid load coordinator uses the Operator / Custom Resource Definition (CRD) component to transform "scheduling suggestions" into "scheduling instructions" that can be executed in Kubernetes. The hybrid load coordinator is positioned to continuously monitor the cluster status and decision-making instructions, and manage complex scheduling strategies across resource objects (such as dynamic resource switching between training tasks and microservices, and coordination of Pod migration and service degradation).

[0284] The implementation process of one example of using the aforementioned custom scheduler and controller (Operator) to execute the above optional implementation scheme is as follows:

[0285] Listen: Listen for changes in CRD instances (scheduling instructions), resource status changes such as Pod / Node / Deployment;

[0286] Coordination: When scheduling conditions are triggered (such as CRD instruction updates or cluster state anomalies), the policy interpreter is invoked to generate an operation sequence, which is then executed through a two-phase commit.

[0287] Feedback: The results of the operation (success / failure, performance indicators) are fed back to the decision-making level for experience storage and model updates.

[0288] Furthermore, as an optional implementation, the method also includes:

[0289] Step D1 involves performing policy pre-verification and security exploration on the joint actions in a constructed high-fidelity cluster simulation environment to ensure the secure implementation and accuracy of intelligent decision-making.

[0290] Step D2 involves online fine-tuning of the model based on the pre-validation results and resource scheduling results. The model includes a multi-agent collaborative decision-making framework and / or a spatiotemporal intelligent prediction engine that performs multi-time-step prediction of the cluster state of the first cluster. This improves the accuracy of resource scheduling.

[0291] It should be noted that in order to achieve the above-mentioned strategy pre-validation and security exploration, as well as online fine-tuning of the model, a high-fidelity simulation environment needs to be built first.

[0292] The construction principle of the high-fidelity simulation environment is as follows:

[0293] Generative Adversarial Network Simulator (GAN-Sim) constructs a high-fidelity digital twin of a cluster based on adversarial game principles. The generator G learns the state transition patterns of a real cluster, starting with the current state s. t Given random noise z as input, output the simulated next state. The aim is to "deceive the real from the fake." Discriminator D then judges the state transition pair ( Whether the data comes from real data or a generator, the aim is to "distinguish truth from falsehood".

[0294] Both systems are trained adversarially within the framework of the minimax value function V(D,G): the generator continuously optimizes to generate more realistic state transitions to deceive the discriminator, while the discriminator continuously optimizes to more accurately distinguish between real and fake states. When training reaches Nash equilibrium, the data distribution captured by the generator can highly approximate the dynamic patterns of a real cluster, thus forming a realistic simulation environment that can be used for risk-free policy pre-verification, secure exploration, and online learning.

[0295] The high-fidelity simulation environment's simulation model includes a generator G and a discriminator D; where:

[0296] The architecture of generator G is as follows: it adopts a hybrid structure of "LSTM + Transformer". The LSTM layer (number of layers = 3, number of hidden layers = 256) captures the time series dependencies, and the Transformer encoder (number of heads = 8, number of layers = 2) captures the global features.

[0297] The input to generator G is: the current cluster state s t (Dimension=512), random noise z (dimensional=64, follows a Gaussian distribution N(0,1)), conditional vector c (dimensional=16, includes business type, load intensity, and cluster size).

[0298] The output of generator G is: the cluster state at the next time step. (Dimension = 512); where the specific content output by generator G includes the complete state of node attributes, edge attributes, business indicators, and competitive situation.

[0299] The discriminator D has the following architecture: a 3-layer fully connected network (hidden layer dimensions = 512, 256), and the activation function is LeakyReLU;

[0300] The input to discriminator D is: state transition pairs ( );

[0301] The output of discriminator D is: the probability of truth (0-1);

[0302] The discriminator D's discriminative ability: It not only judges the authenticity of the state, but also the rationality of the state transition (such as whether resource changes conform to physical laws, whether changes in business indicators conform to load characteristics, etc.).

[0303] The constraint mechanism of the simulation model is as follows: the condition vector c includes the business type (training / microservice), load intensity (low / medium / high), and cluster size (small / medium / large), enabling the generator to generate state data for specific scenarios.

[0304] The adversarial training process between discriminator D and generator G includes:

[0305] First, data preparation: collect three months of historical data from a real cluster, and perform state transitions (...). Organized in format, divided into training set ( ), Validation set ( );

[0306] Second, training iterations, including:

[0307] 1) Discriminator training:

[0308] With a fixed generator G, sample real data pairs ( ) and generated data pairs ( ), calculate the loss Through the Adam optimizer (learning rate = e -4 Update the D parameter;

[0309] 2) Generator training:

[0310] With discriminator D fixed, calculate the loss. ( , To calculate the mean squared error between the generated state and the true state, the Adam optimizer (learning rate = e^(-1 / 2)) is used. -4 Update the G parameters.

[0311] The training termination condition is: the similarity between the generated data and the real data on the validation set is ≥ (Similarity is calculated by weighting cosine similarity and dynamic time warping (DTW), with ≥100 training rounds.

[0312] Optionally, the simulation environment calibration and update mechanism is as follows: every 24 hours, the state data generated by the simulation environment is compared with the real cluster data, and error indices (MSE, MAE) are calculated; if the error exceeds the threshold (MSE> This triggers incremental training, using the latest real data to fine-tune the GAN model.

[0313] In addition, the simulation environment also supports manually adding custom scenarios (such as sudden traffic, node failure, training task start and stop). The generator adapts to the new scenario through the condition vector c, without the need to retrain the entire model.

[0314] The process of offline training and online fine-tuning in a high-fidelity cluster simulation environment is as follows:

[0315] (I) Offline Training:

[0316] (1) Environment initialization: Construct diverse training scenarios in the GAN simulation environment (including normal load, business peak, resource shortage, node failure, etc.).

[0317] (2) Policy pre-training: The MA-SAC algorithm is used for large-scale training in a simulation environment. The training rounds are 500, the batch size is 256, and the learning rate is e. -4 Simulation evaluation is performed every 50 rounds, and the model with the best evaluation index is retained as the pre-trained model.

[0318] (3) Model export: Export the parameters of the pre-trained model (policy network, Q network, intent encoder / decoder network) in PB format for online deployment.

[0319] (II) Shadow Mode Deployment:

[0320] (1) Deployment method: Deploy the pre-trained model to the production environment and run it in parallel with the existing scheduling system; in shadow mode, the scheduling strategy generated by the model is only recorded and not executed, and the existing strategy is still used in actual execution;

[0321] (2) Data Acquisition: Collect "virtual execution" data in shadow mode, including state s, actions Virtual rewards (Calculated based on the actual cluster state) Next state This creates shadow experience data; the collection period is 7 days to ensure coverage of a sufficient number of real-world scenarios.

[0322] (III) Online Fine-tuning

[0323] (1) Experience Mixing: Mixing shadow experience data (proportion) ) and simulation experience data (percentage) Mix and store in the online experience replay pool (capacity = 5e5);

[0324] (2) Fine-tuning training: Mini-batch incremental training is used, with batch size = 128 and learning rate = 5*e. -5 Training rounds = 10-20;

[0325] (3) Parameter update strategy: Only update the top-level parameters of the model (such as the weights of the fully connected layer), and freeze the parameters of the bottom feature extraction layer to ensure training efficiency;

[0326] (4) Model evaluation: After fine-tuning, evaluate in the GAN simulation environment. If the evaluation indicators (such as SLA satisfaction rate improvement ≥5% and resource utilization rate improvement ≥3%) are better than before fine-tuning, save the new model; otherwise, roll back to the original model.

[0327] (iv) Safe gray-scale rollout:

[0328] Small-scale pilot: Select 10% of cluster nodes or specific business (such as non-core microservices, test environment training tasks) and use the new model for scheduling;

[0329] A / B testing: Comparing the strategy with existing strategies, the test metrics include SLA satisfaction rate, training completion time, resource utilization, and energy efficiency; test period = 3 days;

[0330] Full rollout: If, in A / B testing, the new model outperforms the existing strategy by ≥10% in key metrics, then gradually expand the coverage. After each step is expanded, observe for 24 hours; if any abnormality occurs, immediately roll back to the small-scale pilot state.

[0331] (V) Strategy Evaluation and Evolution:

[0332] (1) The evaluation indicator system includes:

[0333] Business metrics (weight 0.5): Microservice latency SLA satisfaction rate, on-time completion rate of training tasks, microservice throughput, and training iteration speed;

[0334] Technical metrics (weight 0.3): Cluster resource utilization (CPU / GPU / memory), resource fragmentation rate, scheduling decision latency, and policy update frequency;

[0335] Safety metrics (weight 0.2): SLA violation count, scheduling operation rollback rate, cluster stability (number of node crashes / Pod abnormal restarts), energy efficiency ratio (computation load / power consumption).

[0336] (2) The tournament selection mechanism includes:

[0337] Candidate strategy pool: Maintain multiple candidate strategies (including current online strategies, latest fine-tuned strategies, and historical best strategies), with a quantity of 5-10;

[0338] Simulated Competition: Regularly (e.g., weekly), in a GAN simulation environment, all candidate policies are "competed" in the same scenario, and the comprehensive score of each policy is calculated (weighted summation, with business metric weights). Technical Specifications Safety indicators );

[0339] Strategy Update: The strategy with the highest overall score will be selected as the candidate strategy for the next round of gray-scale deployment; if the current online strategy has the lowest score, an emergency rollback will be triggered, and the strategy with the highest score will be switched.

[0340] (3) Safe exploration constraints:

[0341] Action space constraints: During the online learning phase, the agent's actions are restricted to a safe range (e.g., the number of Pod replicas is adjusted by no more than 50% of the current value, and the step size of resource adjustment is no more than 20% of the total resources).

[0342] (4) Risk threshold constraint: If the SLA violation probability predicted by ST-GNN is ≥ If the strategy exploration is frozen, only conservative actions (such as resource reservation and service degradation) will be performed.

[0343] (5) Experience filtering: High-risk experiences (such as those leading to SLA violations or cluster anomalies) in the online experience replay pool are marked, and the sampling probability is reduced during sampling (weight = This helps avoid negative experiences in strategy learning.

[0344] The meanings of the parameters involved in the above optional implementation methods are shown in Table 7 below:

[0345] Table 7 Example of parameter meaning

[0346]

[0347] It should be noted that the above optional implementation methods are applicable to the following scenarios:

[0348] Scenario 1: Security exploration for dealing with unknown load patterns:

[0349] Faced with the launch of new services, major architectural changes, or sudden network-wide hotspots, the cluster load pattern is unknown, and existing strategies may fail. GAN-Sim is used to generate simulated loads that conform to the characteristics of the new services, enabling the scheduling system (MA-SAC decision-maker) to conduct safety exploration and adaptive training in the simulation environment in advance. The system can try various aggressive scheduling actions and observe the consequences, quickly learn and adapt to the new pattern, accumulate "experience," and then apply it to the real environment in a safe mode.

[0350] Scenario 2: Assumption Analysis of Capacity Planning and Architecture Evolution:

[0351] Planning to expand cluster capacity, introduce new hardware (such as new GPU models), or adjust network topology requires assessing their potential impact on overall scheduling performance and service SLAs. Modifying cluster capacity, hardware configuration, or topology models in a simulation environment and extrapolating from historical real-world loads allows for quantitative analysis of long-term changes in resource utilization and service performance under different planning scenarios, providing a basis for data-driven capacity planning and architecture decisions.

[0352] Scenario 3: Synthetic experience generation through continuous learning by the scheduler:

[0353] Online learning requires a large amount of diverse experience (states, actions, outcomes), but production environment data distribution is limited, and acquiring failure experience is costly. GAN-Sim can generate a large amount of realistic and diverse synthetic experience data, which, when mixed with real-world experience, is used to drive the offline training and online fine-tuning of the scheduling policy (MA-SAC model). This greatly enriches the distribution of training data, especially by including "edge cases" and "lessons learned" that are difficult to encounter in real-world environments, thus improving the robustness and generalization ability of the policy.

[0354] It should be noted that the overall architecture of the cluster resource scheduling method described in the embodiments of this application is as follows: Figure 3 As shown, it includes:

[0355] (1) Perception and prediction layer: collect full-dimensional monitoring indicators in real time and predict resource demand and business status in the future.

[0356] The perception and prediction layer includes:

[0357] A unified metrics collector is used to collect metrics data of resource nodes (including physical nodes, Pod nodes, and virtual nodes) related to online microservice business and large model training tasks.

[0358] The spatiotemporal graph construction module is used to abstract a cluster as a dynamic heterogeneous graph. Nodes represent physical machines, virtual resources, or Pods, and edges represent network connections, resource dependencies, or communication relationships. Node and edge attributes change over time.

[0359] A spatiotemporal graph neural network predictor is used to capture both the spatial dependence of topological structure and the dynamics of time series using the ST-GNN model, and output the predicted state of future time nodes.

[0360] The aforementioned perception and prediction layer constructs a three-tiered pipeline processing architecture that integrates data-driven approaches, semantic enhancement, and intelligent prediction. The three core modules (cluster graph modeling, dynamic computation of resource contention edges, and the ST-GNN predictor) work collaboratively with strict dependencies, transforming raw monitoring data into forward-looking predictive insights, providing core decision-making support for intelligent cluster scheduling and optimization.

[0361] (2) Collaborative decision-making layer, which is used to make collaborative decisions for agents with different roles (training task scheduler, microservice guaranteeer) based on the current and predicted states, and output joint scheduling actions.

[0362] The collaborative decision-making layer includes:

[0363] The multi-agent MA-SAC decision engine is used for:

[0364] Role Definition: Define two types of intelligent agents: (Focusing on training task efficiency) and (Focusing on microservice SLAs);

[0365] Centralized training, distributed execution: During training, a centralized critic network is used to grasp global information; during execution, each agent makes independent decisions based on local observations.

[0366] The communication mechanism between agents in the multi-agent MA-SAC decision engine is as follows: agents exchange intentions (such as the urgency of resource needs and the risk of SLA violation) through a lightweight message passing mechanism to promote cooperation.

[0367] Multi-objective reward fusion machine: Design a multi-objective reward function that includes training acceleration rewards, latency penalties, resource utilization rewards, energy efficiency rewards, etc., and fuse them through dynamic weight adjustment.

[0368] The aforementioned collaborative decision-making layer achieves multi-agent collaboration and multi-objective optimization based on MA-SAC. MA-SAC, as the core decision engine, constructs a system comprising two specialized agents (a training task optimization agent). With microservices to ensure intelligent agents The collaborative decision-making layer, through a mechanism of division of labor, centralized evaluation, and entropy-driven exploration, achieves a dynamic balance between optimizing training task efficiency and ensuring microservice SLA.

[0369] (3) Layered execution layer, used to transform high-level scheduling decisions into specific, safe and reversible K8s resource operations.

[0370] The hierarchical actuator includes:

[0371] Policy interpreter: Parses the abstract actions output by MA-SAC into a sequence of K8s resource operations;

[0372] Safe operation actuator: Introduces an "operation sandbox" and a "two-phase commit" mechanism, supporting rollback;

[0373] Custom Scheduler and Controller: Extend the Kubernetes scheduler plugin and Operator to receive and execute safe operation instructions generated by the policy interpreter.

[0374] (4) Simulation verification and online learning layer, used to build a high-fidelity cluster simulation environment for policy pre-verification, security exploration and continuous online learning.

[0375] The simulation verification and online learning layer includes:

[0376] A GAN-driven simulation environment generator that uses Generative Adversarial Networks (GANs) to learn patterns of real cluster workloads and resource interactions to generate realistic simulation environments.

[0377] Offline experience replay and online policy updates are used to store experiences generated in real and simulation environments. Periodic sampling from the replay buffer fine-tunes the MA-SAC decision model.

[0378] The strategy performance evaluation and A / B testing framework is used to simulate or conduct small-scale A / B tests on new and old strategies, quantitatively evaluate their impact on multiple target indicators, and ensure positive benefits from strategy updates.

[0379] The above-described cluster resource scheduling method in this application embodiment proposes a multi-step cluster prediction method based on spatiotemporal graph neural network (ST-GNN). This method abstracts cloud-native clusters into dynamic heterogeneous graphs and designs a dedicated ST-GNN model to simultaneously capture the spatial topological dependencies and temporal evolution patterns of resources and loads, thereby achieving accurate prediction of future multi-step resource states and business indicators. The prediction results serve as the enhanced state input for scheduling decisions, achieving forward-looking scheduling. Secondly, a collaborative decision-making framework based on multi-agent soft actor-critic (MA-SAC) is proposed, innovatively modeling the hybrid resource scheduling problem as a multi-agent collaborative decision-making problem. Agent roles representing training tasks and microservice interests are defined, and the MA-SAC algorithm with centralized training and distributed execution is adopted. Through a learnable intent encoding / decoding communication mechanism and a dynamic weighted multi-objective reward function, efficient collaboration and multi-objective optimization in complex competitive environments are achieved. Thirdly, a closed-loop system architecture and security update mechanism of "prediction-decision-execution-learning" are proposed, constructing a complete four-layer intelligent scheduling closed loop, especially the layered security executor and the GAN-driven simulation verification and online learning layer. This architecture realizes the entire process from intelligent decision-making to secure implementation, and supports policy pre-verification and security exploration through high-fidelity simulation, as well as online policy fine-tuning based on mixed real and simulation experience, thus solving the rigidity problem of traditional solutions. Fourth, it proposes an explicit graph modeling method for hybrid load competition and a competition-based scheduling policy generation method. This method explicitly constructs "competitive edges" representing the resource competition relationship between Pods in the cluster graph, optimizes the competition relationship in scheduling decisions, and uses graph neural networks to learn this competition pattern to generate scheduling policies to avoid resource mismatch and SLA violation.

[0380] Embodiments of this application also provide a cluster resource scheduling device, such as... Figure 4 As shown, the device includes:

[0381] The data acquisition module 401 is used to periodically collect monitoring metrics of multiple nodes in the first cluster. The nodes are used to execute online microservice business and / or large model training tasks. The monitoring metrics are related to the resources used by the nodes and / or the services provided by the nodes.

[0382] The prediction module 402 is used to predict the cluster state of the first cluster at multiple time steps based on the monitoring indicators and the dynamic heterogeneous graph data of the first cluster, and obtain the prediction result; wherein, the dynamic heterogeneous graph data is used to characterize the real-time relationship between the nodes in the first cluster.

[0383] The decision module 403 is used to input the prediction result into the multi-agent collaborative decision framework to obtain the joint action output by the multi-agent collaborative decision framework; wherein, the joint action is used to achieve a multi-objective dynamic balance between optimizing the training task efficiency of the first cluster and ensuring the service level agreement (SLA) of the microservice.

[0384] Execution module 404 is used to perform resource scheduling according to the joint action.

[0385] The prediction module 402 includes:

[0386] An instantiation submodule is used to instantiate the dynamic heterogeneous graph data corresponding to the monitoring indicators according to the monitoring indicators, so as to obtain the time series graph set of the first cluster.

[0387] The determination submodule is used to determine the implicit resource competition relationship between different containers associated with the node for each time series graph in the time series graph set;

[0388] The semantic relationship enhancement submodule is used to enhance the semantic relationship of the time series graph based on the implicit resource competition relationship, so as to obtain a time series enhanced graph;

[0389] The prediction submodule is used to input each of the time series augmentation maps into the spatiotemporal intelligent prediction engine to obtain the prediction results output by the spatiotemporal intelligent prediction engine; wherein, the spatiotemporal intelligent prediction engine is used to synchronously learn the spatial topological dependence and temporal evolution law of the first cluster based on the time series augmentation maps, and to perform multi-time-step prediction of the cluster state of the first cluster.

[0390] The determining submodule includes:

[0391] The determination unit is used to identify containers located on the same node that share core resources and have high loads within the same time window as candidate container pairs.

[0392] The analysis unit is used to perform multidimensional correlation analysis on the candidate container pairs to obtain the correlation score of the candidate container pairs;

[0393] The calculation unit is used to calculate the dynamic competition intensity between containers within the candidate container pair based on the resource overlap, conflict degree, and load growth synchronization rate between containers within the candidate container pair when the correlation score is greater than the correlation threshold; wherein the implicit resource competition relationship is represented by the correlation score and the dynamic competition intensity.

[0394] The prediction submodule includes:

[0395] The processing unit is used to perform data preprocessing on each of the time series enhancement maps to obtain a fusion feature vector of a preset dimension corresponding to the time series enhancement degree;

[0396] The learning unit is configured to obtain the spatial feature vector of each node by learning the spatial dependency relationship of nodes in the first cluster based on the fusion feature vector corresponding to each time series augmentation graph, and to obtain the temporal feature vector of the node corresponding to the container by learning the changes in the load, resources and competition of the container over time.

[0397] The feature fusion unit is used to perform spatiotemporal fusion on the spatial feature vector and the temporal feature vector to obtain a spatiotemporal joint feature vector.

[0398] The prediction unit is used to input the spatiotemporal joint feature vector into a bidirectional long short-term memory network (LSTM) for recursive prediction to obtain prediction results for multiple time steps of the first cluster. The prediction results for each time step include resource status, business indicators, competitive situation, and risk probability.

[0399] The decision module 403 includes:

[0400] The first generation submodule is used to generate a first intent vector for each agent in the multi-agent collaborative decision-making framework based on the agent's local observation results, the prediction results, and the pre-set original intent items, send the first intent vector to other agents in the multi-agent collaborative decision-making framework, and receive a second intent vector sent by the other agents.

[0401] The second generation submodule is used to generate a first action through a policy network based on the local observation results and the second intention vector.

[0402] The first acquisition submodule is used to obtain the joint action based on the first action generated by each of the intelligent agents.

[0403] The device further includes:

[0404] A construction module is used to construct a global state vector for each agent based on the agent's local observations and predictions.

[0405] The evaluation module is used to evaluate the long-term benefits of the joint action based on the global state vector to obtain the evaluation value.

[0406] The first determining module is used to determine the risk score of the joint action using an SLA risk sensor;

[0407] The second determining module is used to determine a multi-objective dynamic weighted reward score based on the execution effect of the joint action and the risk score; wherein the execution effect includes training progress, microservice latency, resource utilization and energy efficiency.

[0408] The replay module is used to store the global state vector, the joint action, the multi-objective dynamic weight scoring, the global state vector of the next time step, the first intent vector, and the second intent vector into the experience replay pool.

[0409] The update module is used to update parameters using data from the experience replay pool.

[0410] The execution module 404 includes:

[0411] The second acquisition submodule is used to obtain the operation sequence corresponding to the joint action based on the joint action;

[0412] An evaluation submodule is used to evaluate the impact of the operation sequence on preset metrics of the cluster in a simulation environment based on the current state of the cluster and the prediction results; wherein the preset metrics include resource utilization, microservice latency, training iteration speed, and SLA violation probability.

[0413] The verification submodule is used to perform legality verification, resource feasibility verification, and resource reservation on the operation sequence when the evaluation result meets the preset evaluation conditions.

[0414] The scheduling submodule is used to schedule resources for the nodes in the first cluster by executing each operation in the operation sequence according to the priority of the operation sequence, provided that the operation sequence is legal, resources are feasible, and resource reservation meets preset conditions.

[0415] The device further includes:

[0416] The processing module is used to perform policy pre-verification and security exploration of the joint actions in a constructed high-fidelity cluster simulation environment;

[0417] The fine-tuning module is used to fine-tune the model online based on the pre-validation results and resource scheduling results. The model includes a multi-agent collaborative decision-making framework and / or a spatiotemporal intelligent prediction engine that performs multi-time-step prediction of the cluster state of the first cluster.

[0418] It should be noted that the cluster resource scheduling device provided in this application embodiment can implement all the method steps implemented in the above cluster resource scheduling method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0419] Embodiments of this application also provide a cluster resource scheduling device, such as... Figure 5 As shown, it includes a transceiver 510, a processor 500, a memory 520, and a program or instruction stored in the memory 520 and executable on the processor 500; when the processor 500 executes the program or instruction, it implements the above-mentioned cluster resource scheduling method.

[0420] The transceiver 510 is used to receive and send data under the control of the processor 500.

[0421] Among them, Figure 5 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 500) and memory (memory 520). The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 510 can be multiple elements, including a transmitter and a receiver, providing a unit for communicating with various other devices over a transmission medium.

[0422] The processor 500 is responsible for managing the bus architecture and general processing, while the memory 520 can store the data used by the processor 500 when performing operations.

[0423] This application provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the steps in the cluster resource scheduling method described above and achieve the same technical effect. To avoid repetition, this will not be repeated here.

[0424] The processor mentioned above is the processor in the cluster resource scheduling device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0425] Through the above description of the implementation methods, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, disk, optical disk) and includes several instructions for executing the methods described in the various embodiments of this application.

[0426] Therefore, embodiments of this application also provide a computer program product, including computer instructions, which, when executed by a processor, implement the cluster resource scheduling method described above and achieve the same technical effect. To avoid repetition, further details are omitted here.

[0427] In this embodiment, the module can be implemented in software so that it can be executed by various types of processors. For example, an identified executable code module may include one or more physical or logical blocks of computer instructions, which may be constructed as objects, procedures, or functions. Nevertheless, the executable code of the identified module does not need to be physically located together, but may include different instructions stored in different locations, which, when logically combined, constitute the module and achieve the module's intended purpose.

[0428] In practice, an executable code module can be a single instruction or many instructions, and can even be distributed across multiple different code segments, different programs, and across multiple memory devices. Similarly, operational data can be identified within the module and can be implemented in any suitable form and organized within any suitable data structure. This operational data can be collected as a single dataset or distributed across different locations (including different storage devices), and can exist, at least in part, solely as electronic signals within the system or network.

[0429] When a module can be implemented using software, considering the current level of hardware technology, modules that can be implemented in software can be implemented using hardware circuits by those skilled in the art to achieve the corresponding functions, without considering cost. These hardware circuits include conventional very-large-scale integrated circuits (VLSI) or gate arrays, as well as existing semiconductors such as logic chips and transistors, or other discrete components. Modules can also be implemented using programmable hardware devices, such as field-programmable gate arrays, programmable array logic, and programmable logic devices.

[0430] The exemplary embodiments described above are illustrated with reference to the accompanying drawings. Many different forms and embodiments are feasible without departing from the spirit and teachings of this application, and therefore, this application should not be construed as limiting the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided to make this application complete and convey the scope of this application to those skilled in the art. In these drawings, component dimensions and relative dimensions may be exaggerated for clarity. The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, unless explicitly stated otherwise, the singular forms “a,” “an,” and “the” are intended to include all such forms. It will be further understood that the terms “comprising” and / or “including”, when used in this specification, indicate the presence of the stated features, integers, steps, operations, components, and / or elements, but do not exclude the presence or addition of one or more other features, integers, steps, operations, components, elements, and / or groups thereof. Unless otherwise indicated, a range of values ​​is stated to include the upper and lower limits of the range and any subranges therebetween.

[0431] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A cluster resource scheduling method, characterized in that, include: Periodically collect monitoring metrics from multiple nodes within the first cluster. These nodes are used to execute online microservice business and / or large model training tasks. The monitoring metrics are related to the resources used by the nodes and / or the services provided by the nodes. Based on the monitoring indicators and the dynamic heterogeneous graph data of the first cluster, the cluster state of the first cluster is predicted at multiple time steps to obtain the prediction results; wherein, the dynamic heterogeneous graph data is used to characterize the real-time relationship between the nodes in the first cluster. The prediction results are input into a multi-agent collaborative decision-making framework to obtain a joint action output by the multi-agent collaborative decision-making framework; wherein, the joint action is used to achieve a multi-objective dynamic balance between optimizing the training task efficiency of the first cluster and ensuring the service level agreement (SLA) of the microservice. Resource scheduling is performed based on the aforementioned joint action.

2. The method according to claim 1, characterized in that, The step of predicting the cluster state of the first cluster at multiple time steps based on the monitoring indicators and the dynamic heterogeneity graph data of the first cluster, and obtaining the prediction result, includes: Based on the monitoring indicators, the dynamic heterogeneous graph data corresponding to the monitoring indicators are instantiated to obtain the time series graph set of the first cluster; For each time series graph in the set of time series graphs, determine the implicit resource competition relationships between different containers associated with the node; Based on the implicit resource competition relationship, the time series graph is semantically enhanced to obtain an enhanced time series graph; Each of the time series augmentation maps is input into the spatiotemporal intelligent prediction engine to obtain the prediction result output by the spatiotemporal intelligent prediction engine; wherein, the spatiotemporal intelligent prediction engine is used to synchronously learn the spatial topological dependency and temporal evolution law of the first cluster based on the time series augmentation map, and to perform multi-time step prediction of the cluster state of the first cluster.

3. The method according to claim 2, characterized in that, The step of determining the implicit resource competition relationships between different containers associated with the node for each time series graph in the time series graph set includes: Containers located on the same node that share core resources and experience high loads within the same time window are identified as candidate container pairs. Perform multidimensional correlation analysis on the candidate container pairs to obtain the correlation score of the candidate container pairs; If the correlation score is greater than the correlation threshold, the dynamic competition intensity between containers within the candidate container pair is calculated based on the resource overlap, conflict, and load growth synchronization rate between containers within the candidate container pair; wherein, the implicit resource competition relationship is represented by the correlation score and the dynamic competition intensity.

4. The method according to claim 2, characterized in that, The step of inputting each of the time series augmentation maps into the spatiotemporal intelligent prediction engine to obtain the prediction results output by the spatiotemporal intelligent prediction engine includes: Data preprocessing is performed on each of the time series enhancement maps to obtain a fusion feature vector of a preset dimension corresponding to the enhancement degree of the time series; Based on the fused feature vectors corresponding to each of the time series augmentation maps, the spatial feature vectors of each node are obtained by learning the spatial dependencies of nodes in the first cluster, and the temporal feature vectors of the nodes corresponding to the containers are obtained by learning the changes in the load, resources and competition of the containers over time. The spatial feature vector and the temporal feature vector are spatiotemporally fused to obtain a spatiotemporally joint feature vector; The spatiotemporal joint feature vector is input into a bidirectional long short-term memory network (LSTM) for recursive prediction to obtain prediction results for multiple time steps of the first cluster. The prediction results for each time step include resource status, business indicators, competitive situation, and risk probability.

5. The method according to claim 1, characterized in that, The step of inputting the prediction result into a multi-agent cooperative decision-making framework to obtain the joint action output by the multi-agent cooperative decision-making framework includes: For each agent in the multi-agent collaborative decision-making framework, a first intention vector is generated based on the agent's local observation results, the prediction results, and the pre-set original intention items. The first intention vector is then sent to other agents in the multi-agent collaborative decision-making framework, and a second intention vector sent by the other agents is received. Based on the local observation results and the second intent vector, a first action is generated through a policy network; The joint action is obtained based on the first action generated by each of the aforementioned agents.

6. The method according to claim 5, characterized in that, The method further includes: For each agent, a global state vector is constructed based on the agent's local observations and the prediction results. Based on the global state vector, the long-term benefit of the joint action is evaluated to obtain the evaluation value; The risk score of the joint action is determined using an SLA risk sensor. Based on the execution effect of the joint action and the risk score, a multi-objective dynamic weighted reward score is determined; wherein, the execution effect includes training progress, microservice latency, resource utilization, and energy efficiency. The global state vector, the joint action, the multi-objective dynamic weight scoring, the global state vector of the next time step, the first intention vector, and the second intention vector are stored in the experience replay pool. The parameters are updated using the data in the experience replay pool.

7. The method according to claim 1, characterized in that, The execution of resource scheduling based on the joint action includes: Based on the combined action, obtain the operation sequence corresponding to the combined action; Based on the current state of the cluster and the prediction results, the impact of the operation sequence on preset metrics of the cluster is evaluated in a simulation environment; wherein, the preset metrics include resource utilization, microservice latency, training iteration speed, and SLA violation probability. If the evaluation results meet the preset evaluation conditions, the operation sequence is subjected to legality verification, resource feasibility verification, and resource reservation. If the operation sequence is valid, resources are feasible, and resource reservation meets preset conditions, the nodes in the first cluster are scheduled to perform resource allocation by executing each operation in the operation sequence according to the priority of the operation sequence.

8. The method according to claim 1, characterized in that, The method further includes: The joint actions were pre-verified in a constructed high-fidelity cluster simulation environment, and security was explored. The model is fine-tuned online based on the pre-validation results and resource scheduling results. The model includes a multi-agent collaborative decision-making framework and / or a spatiotemporal intelligent prediction engine that performs multi-time-step prediction of the cluster state of the first cluster.

9. A cluster resource scheduling device, characterized in that, include: The data collection module is used to periodically collect monitoring metrics of multiple nodes within the first cluster. These nodes are used to execute online microservice business and / or large model training tasks. The monitoring metrics are related to the resources used by the nodes and / or the services provided by the nodes. The prediction module is used to predict the cluster state of the first cluster at multiple time steps based on the monitoring indicators and the dynamic heterogeneous graph data of the first cluster, and obtain the prediction result; wherein, the dynamic heterogeneous graph data is used to characterize the real-time relationship between the nodes in the first cluster. The decision module is used to input the prediction results into the multi-agent collaborative decision framework to obtain the joint action output by the multi-agent collaborative decision framework; wherein, the joint action is used to achieve a multi-objective dynamic balance between optimizing the training task efficiency of the first cluster and ensuring the service level agreement (SLA) of the microservice. An execution module is used to perform resource scheduling based on the joint action.

10. A cluster resource scheduling device, comprising a transceiver, a processor, a memory, and a program stored in the memory and executable on the processor, characterized in that, The transceiver is used to send and receive data under the control of the processor, and the processor implements the cluster resource scheduling method as described in any one of claims 1 to 8 when executing the program.

11. A readable storage medium having a program or instructions stored thereon, characterized in that, When the program or instructions are executed by the processor, they implement the cluster resource scheduling method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the cluster resource scheduling method as described in any one of claims 1 to 8.

Images