A cloud-native multi-architecture scheduling method and system for heterogeneous nodes

Abstract

This invention discloses a cloud-native multi-architecture scheduling method and system for heterogeneous nodes, belonging to the field of cloud-native technology. The method includes: identifying multi-dimensional architectural features of heterogeneous node registration information and marking them as node tags, constructing a multi-dimensional feature system; constructing multi-architecture images and generating a unified image address; responding to multi-architecture deployment and scheduling requests, and determining the optimal scheduling node. This cloud-native multi-architecture scheduling method and system for heterogeneous nodes achieves unified management of heterogeneous nodes, intelligent scheduling of multi-architecture images, and efficient operation and maintenance. It upgrades scheduling decisions from relying on a single architecture tag to a comprehensive judgment based on the actual state and trends of nodes, effectively avoiding resource mismatch, improving resource utilization and load balancing of heterogeneous clusters, and improving scheduling accuracy and resource utilization. It also eliminates manual intervention in multi-architecture adaptation, reduces operational complexity, improves image management efficiency, and simplifies multi-architecture image management and operation and maintenance.

Description

Technical Field

[0001] This invention belongs to the field of cloud-native technology, specifically relating to a cloud-native multi-architecture scheduling method and system for heterogeneous nodes. Background Technology

[0002] With the gradual implementation of information technology innovation, enterprises face diverse hardware platforms and chip architectures, with the coexistence of multiple architecture nodes such as x86, ARM, and SW becoming the norm. As the core carrier for application deployment, cloud-native platforms must simultaneously address the dual challenges of "multi-architecture image adaptation" and "optimized scheduling of heterogeneous node resources." Existing technologies face the following key issues:

[0003] 1. The characteristics of heterogeneous nodes are not fully characterized. Traditional node management only focuses on static characteristics such as CPU architecture and ignores dynamic dimensions such as memory bandwidth and real-time load. This results in scheduling decisions relying on a single feature, which cannot reflect the true state of the nodes and is prone to resource mismatch.

[0004] 2. The cross-architecture scheduling strategy lacks intelligence. Existing scheduling algorithms mostly adopt static affinity rules, which lack the ability to predict future resource states and are difficult to cope with dynamic load scenarios. At the same time, the weight allocation of architecture compatibility and resource balance is fixed and cannot be adjusted in real time according to cluster fragmentation rate, resulting in low resource utilization.

[0005] 3. Lack of multi-architecture image management and scheduling coordination. The construction of multi-architecture images relies on manual maintenance of manifest files, and scheduling is based solely on static architecture tags without linkage with real-time node resource status, resulting in a disconnect between image deployment and resource load, leading to high operational complexity.

[0006] 4. The scheduling optimization search is inefficient. When faced with a large number of heterogeneous nodes, traditional greedy algorithms or genetic algorithms converge slowly in multi-objective optimization (architecture matching, resource balancing, low latency), making it difficult to find near-optimal solutions quickly. The scheduling latency is too high and cannot meet the real-time requirements.

[0007] Therefore, based on the above problems, it is necessary to develop a new cloud-native multi-architecture scheduling method and system for heterogeneous nodes to solve the existing problems. Summary of the Invention

[0008] The purpose of this invention is to provide a cloud-native multi-architecture scheduling method and system for heterogeneous nodes, so as to solve the problems of insufficient unified management accuracy of heterogeneous nodes in cloud-native environments, low intelligence of cross-architecture scheduling, complex multi-architecture image management, and low scheduling optimization efficiency.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a cloud-native multi-architecture scheduling method for heterogeneous nodes, comprising:

[0010] Heterogeneous node registration and multi-dimensional feature system construction;

[0011] Node registration and information collection;

[0012] When a node registers with the container cloud platform, the node management module receives its registration information, including:

[0013] Hardware configuration details: CPU model, number of cores, clock speed, GPU type, memory capacity and bandwidth, storage media, network interface type, etc.;

[0014] System information: operating system version, kernel version, architecture-related parameters; perform network connectivity and basic service availability checks on nodes, and only nodes that pass the checks are included in the scheduling scope;

[0015] Multi-dimensional feature vector construction and labeling:

[0016] Node static feature vectors: It includes information such as CPU architecture, GPU type, memory bandwidth, storage media, and network type;

[0017] Node dynamic state vector: This includes CPU utilization, memory usage, network bandwidth utilization, disk queue usage length, and the number of running pods;

[0018] Dynamic management of node labels: The node management module maps static features to node labels and monitors changes in hardware configuration or system information in real time to trigger dynamic updates of labels, ensuring consistency with the actual state of the nodes.

[0019] Multi-architecture image building; A visual interface is used to combine different architecture sub-images to build manifest files and generate a unified image address. In multi-architecture image deployment scenarios, users can operate through the visual interface provided by the platform.

[0020] Users can select sub-images with different architectures; the sub-images belong to different architecture versions of the same application.

[0021] The system performs a consistency check on the name and version of the selected sub-images to ensure that they belong to the same application and that the versions match.

[0022] After verification, a manifest file is automatically generated, which includes the sub-image address, architecture identifier, and digest value, etc.

[0023] Push the manifest file to the container image repository to generate a unified image address, which supports automatic matching of node architecture during deployment;

[0024] Intelligent Pod Scheduling Based on QPAS-HA Algorithm;

[0025] For multi-architecture deployment scheduling requests, intelligent scheduling is achieved through a three-step process: "resource prediction → feature fusion → quantum optimization." This ensures that Pod replicas are scheduled only to nodes with compatible architectures and optimal resources. Specifically, this includes:

[0026] LSTM resource prediction;

[0027] Transformer hierarchical attention feature fusion;

[0028] Quantum-inspired near-optimal solution search;

[0029] Preferred LSTM resource prediction specifically includes:

[0030] Input sequence construction: The input sequence is constructed by selecting the node dynamic state vector time series from the past 10 minutes. ;

[0031] LSTM model inference: A 3-layer LSTM is used to compute and output the node state sequence for the next 5 minutes. ;

[0032] Resource prediction feature vector generation: Take the predicted value at the 3rd minute in the future as the representative feature vector, and calculate the resource prediction feature vector. .

[0033] Preferably, the Transformer hierarchical attention feature fusion includes:

[0034] Architecture-aware attention layer: This layer is used to enhance the architecture fit between Pods and nodes;

[0035] Resource Balancing Attention Layer: This layer is used to optimize cluster resource load balancing.

[0036] Preferably, the construction of the perceptual attention layer for enhancing the architectural matching degree between Pods and nodes includes:

[0037] The Pod requirements, node static features, and node dynamic features are mapped into high-dimensional query vectors, key vectors, and value vectors through a weight matrix;

[0038] A multi-head attention mechanism is adopted, where each head independently calculates the architecture matching score between the Pod and the node and then... Function normalization yields the head vector; the head vector is calculated from the architecture matching score through normalization and weighting.

[0039] The results are concatenated and converted into architecture matching features.

[0040] Preferred quantum-inspired near-optimal solution search specifically includes:

[0041] Quantum bit encoding: Mapping the candidate node set to qubits and initializing it to a uniform superposition state;

[0042] Revolving door update: based on Calculate the rotation angle of each qubit By iteratively updating the quantum state through the rotation matrix, the probability amplitude of high-scoring nodes is enhanced;

[0043] Measurement and Verification: Measure the quantum state to obtain the node index with the highest probability, verify its compatibility with the pod architecture, and determine the optimal scheduling node.

[0044] Preferably, the calculation and output of the future node state sequence based on a 3-layer LSTM includes:

[0045] Calculating the first layer of the LSTM includes:

[0046] Forgotten Gate: Used to control the retention of historical information, wherein: Represents matrix multiplication. This represents the weight matrix of the first-level forget gate. Represents the set of real numbers. Indicates the hidden layer dimension. Indicates the input layer dimension. Indicates matrix transpose. Represents the time series of the node's past dynamic state vector. This represents the first-level forget gate bias vector. Indicates the first level time step The hidden state vector, initial value , Indicates time step The input feature vector, Indicates the first level time step The output vector of the forget gate, It is an activation function, which is activated when the input... When the input is ≥0, the output is equal to the input itself; when the input is ≥0, the output is equal to the input itself. When <0, the output is directly 0;

[0047] Input gates and candidate cell states: Input gate control Candidate state ,in: and This represents the input gate weight matrix and the candidate cell state weight matrix of the first layer. and This represents the input gate bias vector of layer 1 and the candidate cell state bias vector of layer 1. This represents the output vector of the input gate in the first layer. This represents the state vector of the candidate cells in the first-level forgetting gate.

[0048] Cell state update: Level 1 time step Cell state vector ,in: and These represent the first layer at time step. and The cell state vector, Represents element-wise multiplication;

[0049] Output Gates and Hidden States: Output Gate Control , ,in: This represents the weight matrix of the output gate of the first layer. This represents the bias vector of the output gate of the first layer. This indicates that the first layer is at time step The cell state vector, This indicates that the first layer is at time step The output gate output vector, This indicates that the first layer is at time step The hidden state vector;

[0050] Calculate the second LSTM layer; including: the calculation method for the second LSTM layer is the same as that for the first LSTM layer, using the hidden state vector of the first layer. For input, the parameters are , ,..., The second layer outputs the hidden state vector. ;

[0051] Calculate the third LSTM layer; including: the calculation method for the third LSTM layer is the same as that for the first LSTM layer, using the hidden state vector of the second layer. For input, the parameters are , ,..., The third layer outputs the hidden state vector. ;

[0052] Input the hidden state vector of the last time step of the LSTM layer into the fully connected layer to output the future prediction sequence. ,in: Indicates the future number Minutes Dimensional predictive features This represents the hidden state vector at the last time step of layer 3. Indicates the first The output weight matrix of the 3D feature. Indicates the first The output bias vector of the dimensional feature.

[0053] Preferably, the step of taking the future node state sequence as a representative feature vector to generate the resource prediction feature vector includes:

[0054] The predicted value at the 3rd minute in the future is selected as the representative feature vector. ;

[0055] The weights of key features are enhanced based on the trained weight matrix, and the final resource prediction feature vector is output. ,in: This represents the weight matrix obtained during training. This indicates that the final resource prediction feature vector is output as one of the inputs to the Transformer feature fusion unit.

[0056] Preferably, the step of mapping Pod requirements, node static features, and node dynamic features into high-dimensional query vectors, key vectors, and value vectors through a weight matrix includes: generating query vectors. Key vector Sum value vector : , , in: Represents the Pod architecture requirement vector. Represents the static feature vector of a node. Represents the dynamic feature vector of a node. , , These represent the learnable weight matrix for the query vector, the learnable weight matrix for the key vector, and the learnable weight matrix for the value vector, respectively.

[0057] Preferably, the splicing result and conversion into architecture matching features includes: Where: head1, head2, ..., head8 represent the output vectors of the 8 attention heads. This represents the output transformation matrix. This represents a concatenation function that concatenates the output vectors of all attention heads along the feature dimension. This represents the architecture matching feature vector.

[0058] Preferably, the construction of the resource balancing attention layer for optimizing cluster resource load balancing includes: calculating the comprehensive load of nodes based on a weighted summation of CPU and memory utilization.

[0059] Based on comprehensive load calculation, load probability distribution and equilibrium entropy are used to quantify cluster load uniformity;

[0060] Attention scores are calculated based on the deviation of node load from the cluster average and the equilibrium entropy.

[0061] The final feature vector is calculated by integrating node architecture features, node resource balancing features, and prediction features.

[0062] Preferably, the comprehensive load calculation of the computing node based on the weighted summation of CPU and memory utilization includes: load probability distribution and equilibrium entropy calculation. , ,in: This represents the load probability distribution of the nodes. Represents a node The overall load, Indicates the number of nodes in the cluster. Represents a node The overall load, This represents a value that measures the uniformity of load distribution; Indicates the first CPU utilization per node; Indicates the first Memory usage of each node.

[0063] Preferably, the calculation of the attention score based on the deviation between node load and cluster average and the equilibrium entropy includes: Node attention score calculation: in: Indicates the load sensitivity coefficient. Indicates the entropy penalty weight. Represents a node The overall load, This represents the average overall load of the cluster. This represents an exponential function.

[0064] Preferably, the step of calculating the final feature vector by fusing node architecture features, node resource balancing features, and prediction features includes: dynamic feature fusion. in: Indicates adaptive weights, Indicates the predicted feature weights. Represents the node attention score vector. This indicates the architecture matching feature vector. Represent the resource prediction feature vector; and for the fused feature vector according to Normalization was performed, where, Represents the fused feature vector The One element, Representing vectors No. One element, for The normalized value; This indicates the dimension of the fused feature vector.

[0065] Preferably, the quantum-inspired fast search strategy for near-optimal solutions includes: mapping a set of M candidate nodes to... There are qubits, and each qubit is in a state of . , The initial state is set as uniform superposition, i.e. ;in, and The i-th qubit is respectively in The probability amplitude of the state. Indicates the first A superposition of qubits;

[0066] Based on fused feature vectors Calculate the rotation angle of each qubit The state of the qubit is updated iteratively by rotating the matrix;

[0067] Measuring the qubit state yields the node index with the highest probability. Verify the compatibility of the architecture. Then select the node index. Otherwise, select the node index with the second highest probability and re-verify until the architecture is compatible, where: Represents the Pod architecture requirement vector. Represents node index Transpose of static eigenvectors This represents the threshold.

[0068] This invention also provides a cloud-native multi-architecture scheduling system for heterogeneous nodes, comprising:

[0069] A multi-dimensional feature system construction unit is used to identify the multi-dimensional architectural features of heterogeneous node registration information and mark them as node labels to construct a multi-dimensional feature system.

[0070] The unified image address generation unit is used to build multi-architecture images and generate unified image addresses;

[0071] The optimal scheduling node determination unit is used to respond to multi-architecture deployment and scheduling requests and determine the optimal scheduling node.

[0072] The optimal scheduling node determination unit includes:

[0073] The resource prediction feature vector generation module is used to predict the future resource status of nodes and generate resource prediction feature vectors.

[0074] The feature vector fusion module is used to fuse node features, Pod architecture requirement features, and resource prediction feature vectors; the optimal scheduling node determination module is used to determine the optimal scheduling node from candidate nodes based on the fused feature vectors, according to a quantum-inspired near-optimal solution fast search strategy.

[0075] The technical effects and advantages of this invention are as follows: This cloud-native multi-architecture scheduling method and system for heterogeneous nodes is applicable to cloud-native environments containing multiple architecture nodes such as x86, ARM, and SW. Through the QPAS-HA intelligent scheduling algorithm, it achieves unified management of heterogeneous nodes, intelligent scheduling of multi-architecture images, and efficient operation and maintenance. By constructing a multi-dimensional feature system, the QPAS-HA intelligent scheduling algorithm, and collaborative system modules, it improves resource utilization and reduces operational complexity. The construction of a multi-dimensional node feature system, combined with an LSTM resource prediction model to predict the future state of nodes, upgrades scheduling decisions from relying on a single architecture label to a comprehensive judgment based on the actual state and trends of nodes, effectively avoiding resource mismatch, improving the resource utilization and load balancing of heterogeneous clusters, and enhancing scheduling accuracy and resource utilization. The QPAS-HA algorithm, through a hierarchical attention fusion mechanism, dynamically balances architecture matching and resource balancing weights based on cluster fragmentation rate; combined with a quantum-inspired search strategy, it achieves rapid optimization of large-scale nodes, significantly improving the efficiency of multi-architecture Pods. High scheduling success rate, efficient support for mixed deployment of multi-architecture nodes, adaptability to complex scenarios, and enhanced intelligence and real-time performance of architecture scheduling; the visual image building module automates the entire process of sub-image selection, verification, and manifest generation, simplifies deployment through unified image addresses, eliminates manual intervention for multi-architecture adaptation, reduces operational complexity, improves image management efficiency, and simplifies multi-architecture image management and maintenance; the dynamic node tag update mechanism quickly responds to hardware and system changes, combined with scheduling closed-loop feedback (real-time update of node characteristics after Pod deployment), enabling the system to flexibly adapt to changes in node status, maintain a high scheduling success rate even in scenarios such as sudden failures, enhance anti-interference capabilities and stability, and enhance the system's dynamic adaptability and robustness. Attached Figure Description

[0076] Figure 1 This is a schematic diagram of the method flow in an embodiment of the present invention;

[0077] Figure 2 This is a schematic diagram of the node management process in an embodiment of the present invention;

[0078] Figure 3 This is a schematic diagram of the image construction process in an embodiment of the present invention;

[0079] Figure 4 This is a flowchart illustrating the intelligent scheduling engine in an embodiment of the present invention. Detailed Implementation

[0080] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0081] This invention provides a cloud-native multi-architecture intelligent scheduling method for heterogeneous nodes, comprising the following steps:

[0082] Step 1: Receive the registration information of cluster nodes, identify their multi-dimensional architectural features and mark them as node tags, and construct a multi-dimensional node feature system;

[0083] The registration information mentioned in step 1 includes node hardware configuration details (including CPU model, number of cores, clock speed, GPU type, etc.), operating system version and kernel information. The above information is used to help verify the accuracy of the node architecture characteristics. When receiving cluster node registration information, the network connectivity and basic service availability of the node are verified. Only nodes that pass the verification will be included in the scheduling scope. The node tag will be dynamically updated as the node hardware configuration or system information changes to ensure that the tag is consistent with the actual state of the node.

[0084] The multi-dimensional node feature system described in step 1 includes node static feature vectors and node dynamic state vectors:

[0085] The node static feature vector is 13-dimensional, including architecture-related features such as CPU architecture, GPU type, memory bandwidth, storage medium, and network type;

[0086] The node dynamic state vector is 5-dimensional, including dynamic metrics such as CPU utilization, memory usage, network bandwidth utilization, disk I / O queue length, and number of running pods, and is updated every 10 seconds;

[0087] Step 2: Build multi-architecture images. Use a visual interface to combine different architecture sub-images to build manifest files and generate a unified image address.

[0088] The construction of multi-architecture images includes:

[0089] Step 2.1: Receive different architecture sub-images selected by the user through the visual interface. The visual interface provides intuitive sub-image selection and management functions.

[0090] Step 2.2: After verifying the consistency of the sub-image name and version, a manifest file is automatically generated. The verification process ensures that the sub-images belong to the same application and are version compatible. The manifest file contains sub-image information and architecture identifier.

[0091] Step 2.3: Push the manifest file to the image repository to generate a unified image address. The unified image address can be used for application deployment in multi-architecture scenarios.

[0092] Step 3: For multi-architecture deployments and scheduling requests, implement intelligent pod scheduling based on the QPAS-HA algorithm, including:

[0093] Step 3.1: Use a resource prediction model based on Long Short-Term Memory (LSTM) network to predict the future resource status of nodes and generate resource prediction feature vectors;

[0094] The resource prediction model based on the Long Short-Term Memory (LSTM) network in step 3.1 includes:

[0095] Step 3.1.1: The input is the dynamic state time series of nodes over the past 10 minutes, with each time step containing 5-dimensional features and a sequence length of 60. Specifically, the dynamic feature sequence of nodes over the past 10 minutes is read from the time series database, and a matrix is ​​constructed. ,in ;

[0096] Step 3.1.2: The model structure uses a 3-layer LSTM network with 128 neurons per layer, outputting a sequence of node state vectors for the next 5 minutes. Specifically, this includes: Model structure: Constructing a 3-layer LSTM network with 128 neurons per layer. The activation function is used, and the output layer is a fully connected layer containing 5 neurons. The general parameters for the LSTM layer are defined as follows: Number of neurons per layer: Activation function: ;No. Layer input: ,in: , indicating the input layer dimension, , ;No. Layer output hidden state: ;No. Layer cell state: The specific steps are as follows:

[0097] Step 3.1.2.1, Calculation of the first layer LSTM:

[0098] Forgotten Gate: Used to control the retention of historical information, wherein: Represents matrix multiplication. This represents the weight matrix of the first-level forget gate. Represents the set of real numbers. Indicates the hidden layer dimension. Indicates the input layer dimension. Indicates matrix transpose. Represents the time series of the node's past dynamic state vector. This represents the first-level forget gate bias vector. Indicates the first level time step The hidden state vector, initial value , Indicates time step The input feature vector, Indicates the first level time step The forget gate output vector; It is an activation function, which is activated when the input... When the input is ≥0, the output is equal to the input itself; when the input is ≥0, the output is equal to the input itself. When <0, the output is directly 0.

[0099] Input gates and candidate cell states: Input gate control Candidate state ,in: and This represents the input gate weight matrix and the candidate cell state weight matrix of the first layer. and This represents the input gate bias vector of layer 1 and the candidate cell state bias vector of layer 1. This represents the output vector of the input gate in the first layer. This represents the state vector of the candidate cells in the first-level forgetting gate.

[0100] Cell state update: Level 1 time step Cell state vector ,in: and These represent the first layer at time step. and The cell state vector, Represents element-wise multiplication;

[0101] Output Gates and Hidden States: Output Gate Control , ,in: This represents the weight matrix of the output gate of the first layer. This represents the bias vector of the output gate of the first layer. This indicates that the first layer is at time step The cell state vector, This indicates that the first layer is at time step The output gate output vector, This indicates that the first layer is at time step The hidden state vector;

[0102] Step 3.1.2.2, Calculation of the second LSTM layer:

[0103] Using the hidden state vector of layer 1 The input is [value], and the calculation process is the same as in layer 1, with the following parameters: , ,..., Output hidden state vector ;

[0104] Step 3.1.2.3, Calculation of the third LSTM layer:

[0105] Using the hidden state vector of layer 2 The input is [value], and the calculation process is the same as in layer 1, with the parameters being [parameters]. , ,..., Output hidden state vector ;

[0106] Step 3.1.2.4, Fully Connected Layer Output: Input the hidden state vector of the last time step of the LSTM layer 3 into the fully connected layer, and output the predicted sequence for the next 5 minutes. , Indicates the future number Minutes The predictive features of dimension, where: Indicates the future number Minutes Dimensional predictive features This represents the hidden state vector at the last time step of layer 3. Indicates the first The output weight matrix of the 3D feature. Indicates the first The output bias vector of the dimensional feature.

[0107] Step 3.1.2.5, Selection of Prediction Results: Select... That is, the predicted value in the 3rd minute is used as the representative feature vector;

[0108] Step 3.1.3: Take the predicted value at the 3rd minute in the future as the resource prediction feature vector, and this vector has the same dimension as the node dynamic state vector, including:

[0109] Weight matrix transformation: Enhances the weights of key features using a trained weight matrix, outputting the final resource prediction feature vector. ,in, It is the weight matrix obtained through training. To output the final resource prediction feature vector, it serves as one of the inputs to the Transformer feature fusion unit;

[0110] Step 3.2: Employ a Transformer-based hierarchical attention feature fusion mechanism to fuse node features, Pod architecture requirement features, and resource prediction feature vectors to obtain a fused feature vector.

[0111] Step 3.2 describes a Transformer-based hierarchical attention feature fusion mechanism that includes an architecture-aware attention layer and a resource-balancing attention layer. The main function of the architecture-aware attention layer is to effectively map and match heterogeneous information, generating core architecture-matching features to support subsequent scheduling decisions. Specifically, it includes:

[0112] Step 3.2.1: The architecture-aware attention layer employs a multi-head attention mechanism. The query vector is a linear transformation of the Pod architecture requirement vector, the key vector is a mapping of the node's static feature vector, and the value vector is the node's dynamic state vector. Architecture-aware attention features are obtained by calculating and concatenating these features through multi-head attention; specifically including:

[0113] Step 3.2.1.1: Map the Pod requirements, node static features, and node dynamic features into a high-dimensional query vector using a weight matrix. Key vector Sum value vector Query vector Key vector Sum value vector generate: , , in: For Pod architecture requirements vector, For the static feature vector of the node, For the node's dynamic feature vector, , , These represent the learnable weight matrix for the query vector, the learnable weight matrix for the key vector, and the learnable weight matrix for the value vector, respectively.

[0114] Step 3.2.1.2: Employ an 8-head multi-head attention mechanism, where each head independently calculates the architecture matching score between the Pod and the node, and then... Function normalization yields the head vector. ;

[0115] Step 3.2.1.3, Multi-head attention calculation: ,in, , , For the first The parameter matrix of the head, Scaling factor ;

[0116] Step 3.2.1.4: Concatenate the 8-head results and convert them into architecture matching features. Output splicing: Where: head1, head2, ..., head8 represent the output vectors of the 8 attention heads. This represents the output transformation matrix. This represents a concatenation function that concatenates the output vectors of all attention heads along the feature dimension. Represents the architecture matching feature vector

[0117] Step 3.2.2: The resource balancing attention layer introduces load balancing entropy as a penalty term to calculate the resource balancing attention score for each node; specifically including:

[0118] Step 3.2.2.1: Calculate the node by weighted summation of CPU and memory utilization. Comprehensive load ;

[0119] Step 3.2.2.2: Calculate the load probability distribution through comprehensive load analysis. With equilibrium entropy Quantifying cluster load uniformity; calculating load probability distribution and equilibrium entropy: , ,in: For nodes The overall load, The number of nodes in the cluster. The smaller the value, the more even the distribution; Indicates the first CPU utilization per node; Indicates the first Memory usage of each node;

[0120] Step 3.2.2.3, through node load balancing Compared with cluster average Deviation, equilibrium entropy Calculate attention score Node attention score calculation: in: For load sensitivity coefficient, Entropy penalty weights, The score represents the average overall load of the cluster; a higher score indicates a more balanced load across the nodes. Represents a node The overall load, This represents the average overall load of the cluster. Represents an exponential function;

[0121] Step 3.2.3: Determine adaptive weights based on cluster fragmentation rate, and fuse architecture-aware attention features, resource balancing attention scores, and resource prediction feature vectors to obtain a fused feature vector. Specifically, this includes fusing node architecture features... Node resource balance characteristics and predictive features Calculate the final feature vector Dynamic feature fusion: in: For adaptive weights, To predict feature weights, Represents the node attention score vector. This indicates the architecture matching feature vector. Represents the resource prediction feature vector, and for according to Normalization is performed. To fuse feature vectors The One element, To integrate the dimensions of the feature vectors, the normalized values ​​are used as input for the quantum-inspired search. Representing vectors No. One element, for The normalized value;

[0122] Step 3.3: Based on the quantum-inspired near-optimal solution fast search strategy, the optimal scheduling node is determined from the candidate nodes based on the fused feature vector, ensuring that each replica is only scheduled to the node that matches its architecture label;

[0123] The quantum-inspired fast search strategy for near-optimal solutions in step 3.3 includes:

[0124] Step 3.3.1: Map the candidate node set to the corresponding number of qubits and initialize it to a uniform superposition state; map the candidate node set of number M to... There are qubits, and each qubit is in a state of . , The initial state is set as uniform superposition, i.e. ;in, and The respective Each quantum bit is in The states correspond to the probability amplitudes of the scheduling outcome of "node not selected" and "node selected", respectively. Indicates the first A superposition of qubits;

[0125] Step 3.3.2: Calculate the rotation angle of the quantum rotation gate based on the fused feature vector, and iteratively update the qubit state; adjust the quantum state based on the fused features to enhance the probability amplitude of high-quality nodes. ,in The first fusion feature dimension, For qubit weights, This is the rotation step size coefficient.

[0126] The rotation matrix is Iterative updates enable high-scoring nodes to... maximize;

[0127] Step 3.3.3: Measure the quantum state to obtain the node index with the highest probability, verify its compatibility with the pod architecture, determine the optimal scheduling node, and measure the quantum state to obtain the node with the highest probability. The pod architecture requirements are verified, and if approved, the pod is bound to the node. Otherwise, measure the suboptimal node, and measure the quantum state to obtain the node index with the highest probability. And verify the compatibility of the architecture, if Selecting nodes , where the threshold Otherwise, select the second-best node, and re-verify it until the architecture is compatible; the second-best node is the node with the second highest probability.

[0128] Step 3.3.4, Closed-loop feedback: After the pod is bound, the dynamic characteristics of the node change due to the new load. The agent program collects and updates the data in real time to the time series database, supplementing the historical feature sequence and providing the latest data for the next prediction.

[0129] Figure 1 It is a complete process from node registration and multi-dimensional feature system construction, automated generation of multi-architecture images to intelligent scheduling based on QPAS-HA algorithm, forming a complete technical link of "node feature collection → image architecture construction → intelligent scheduling decision → feature dynamic update", intuitively presenting the collaborative mechanism of heterogeneous node management, multi-architecture image adaptation and intelligent scheduling.

[0130] The overall process of this invention revolves around three core stages: "heterogeneous node management → multi-architecture image construction → intelligent scheduling closed loop," forming a complete technical chain. The process begins with the registration and feature collection of heterogeneous nodes. After verification, nodes are included in the scheduling pool, and their multi-dimensional features are updated to the feature library in real time. Simultaneously, multi-architecture images complete sub-image selection, verification, and unified address generation through visualization tools, providing basic image resources for scheduling. Finally, the intelligent scheduling engine outputs the optimal scheduling scheme based on node features and image architecture requirements using the QPAS-HA algorithm. After deployment, node status changes are fed back to the feature library, achieving a dynamic optimization closed loop. This process covers the entire lifecycle from node access to application deployment, solving the core problems of chaotic node management, complex image adaptation, and low scheduling efficiency in heterogeneous environments.

[0131] Figure 2 It is the entire process from a node initiating a registration request to being included in the scheduling pool and dynamically updated, including core steps such as legality verification, hardware and system information collection, health check, multi-dimensional feature vector construction, node label generation, and real-time status monitoring and updating;

[0132] Node management is the core component for unified control of heterogeneous nodes. The specific implementation steps are as follows:

[0133] Node registration and legitimacy verification: After a node starts up, it sends a registration request to the management module through a preset API interface. The request includes the node's unique identifier (such as UUID) and identity certificate. First, the certificate's legitimacy is verified (verifying the certificate chain and signature validity), and the node's IP is compared to whether it is in the preset whitelist. If both verifications fail, registration is rejected, and "illegal registration attempt" (including time, IP, and reason for failure) is recorded in the audit log. Nodes that pass the verification proceed to the next step.

[0134] Basic information collection: Two types of information are collected through agent programs deployed on nodes:

[0135] Hardware configuration: CPU (model, number of cores, clock speed, cache size), GPU (brand, model, video memory capacity, computing power level), memory (total capacity, single module capacity, number of channels, bandwidth), storage (media type, total capacity, IOPS, latency), network (interface type, speed, MAC address, whether RDMA is supported);

[0136] System information: operating system version, kernel version and compilation parameters, container runtime (Docker / containerd) version, kubelet version, kernel parameters.

[0137] Health check mechanism:

[0138] Network connectivity: Send ICMP ping packets to verify packet loss rate, and at the same time verify the TCP connection reachability between the node and the control plane APIServer port 6443 and kubelet port 10250;

[0139] Service availability: The systemd checks the running status of kubelet and containerd services and executes container runtime health check commands to ensure that the basic services are free of anomalies.

[0140] Feature system construction and tag management:

[0141] Static feature vector: Maps hardware configuration to CPU architecture, GPU type, memory bandwidth, storage media type, and network type in system information into a 13-dimensional vector. ,in Represents the CPU architecture, using one-hot encoding: 100 for x86, 010 for ARM, and 001 for SW. This represents the GPU type, using one-hot encoding: NVIDIA is 100, AMD is 010, Huawei NPU is 001, and no GPU is 000. Represents memory bandwidth, using ordinal encoding: 100 for high, 010 for medium, and 001 for low. This represents the type of storage medium; 10 represents SSD, and 01 represents HDD. The number represents the network type; Ethernet is represented by 10, and 5G is represented by 01.

[0142] Dynamic Feature Vector: Five dynamic indicators of the node are collected in real time at a frequency of 10 seconds per instance, forming a 5-dimensional vector. Including CPU utilization Memory usage Network bandwidth utilization Disk I / O queue length Number of running Pods Each indicator is based on Normalized to the interval [0,1], where These are the original indicator values. and These are the minimum and maximum values ​​of the indicator in historical observations, respectively. The normalized values ​​are stored in the time series database;

[0143] Tag generation: Static features are mapped to queryable tags (e.g., arch=x86, gpu=nvidia, memory-bandwidth=200GB / s), and the tags are updated in real time as hardware changes;

[0144] Real-time status monitoring: The agent listens for node hardware change events and system configuration modifications in real time, triggering the recalculation of feature vectors and labels; basic information is re-collected every 30 minutes and compared with the currently stored features. If the difference exceeds the threshold, the scheduling pool information is automatically updated to ensure the authenticity of the node status.

[0145] Figure 3 This is the complete process from user selection of multiple architecture sub-images through a visual interface to the generation of a unified image address, including sub-image selection, sub-image verification, automatic manifest file generation, and image repository push. The image build module automates the generation and management of multi-architecture images, with the following specific steps:

[0146] Visual interactive interface: Provides a web interface, including an application list (categorized by name and version), an architecture selection area (x86, arm, sw, etc., with icon labels), a sub-image preview area (displaying image size, last update time, and digest value), and operation buttons (add, delete, verify, generate);

[0147] Sub-mirror selection and verification:

[0148] Selection logic: The user selects the target application from the application list, checks the required architecture in the architecture selection area, and the system automatically pulls metadata from the image repository to list the available sub-image versions for the corresponding architecture of the application. The user selects a specific version and adds it to the build list.

[0149] Triple verification: Checks whether the repository path and application name of all sub-images are consistent to avoid mixed selection across applications;

[0150] Semantic versioning ensures that the version numbers of the selected sub-images are consistent; parsing the manifest metadata of the sub-images verifies their consistency with the selected architecture.

[0151] Manifest file generation and push:

[0152] Automatic generation: After verification, the system generates a manifest list file according to the OCI specification, which includes the name, tag, digest, architecture identifier, platform information (OS, architecture), and size of each sub-image;

[0153] Push mechanism: The manifest file is pushed to the private image repository via the HTTP protocol, the repository access permissions are set to allow only the internal scheduling system to read it, and a unique unified image address is generated (format: repository address / application name: unified version number).

[0154] Metadata synchronization: The unified image address, the list of supported architectures, and the digest values ​​of each sub-image are synchronized to the metadata cache of the intelligent scheduling engine in the etcd library to ensure that the architecture requirements of the image can be quickly resolved during scheduling.

[0155] like Figure 4 It is the entire process from triggering multi-architecture scheduling requests to binding Pods to nodes and forming a closed-loop feedback, including the temporal feature inference of the LSTM resource prediction unit, the hierarchical attention calculation of the Transformer feature fusion unit, the quantum state encoding and optimization search of the quantum-inspired search unit, as well as the closed-loop mechanism of architecture compatibility verification and node dynamic feature update.

[0156] This invention also provides a cloud-native multi-architecture scheduling system for heterogeneous nodes, comprising:

[0157] A multi-dimensional feature system construction unit is used to identify the multi-dimensional architectural features of heterogeneous node registration information and mark them as node labels to construct a multi-dimensional feature system.

[0158] The unified image address generation unit is used to build multi-architecture images and generate unified image addresses;

[0159] The optimal scheduling node determination unit is used to respond to multi-architecture deployment and scheduling requests and determine the optimal scheduling node.

[0160] The optimal scheduling node determination unit includes:

[0161] The resource prediction feature vector generation module is used to predict the future resource status of nodes and generate resource prediction feature vectors.

[0162] The feature vector fusion module is used to fuse node features, Pod architecture requirement features, and resource prediction feature vectors.

[0163] The optimal scheduling node determination module is used to determine the optimal scheduling node from candidate nodes based on a quantum-inspired near-optimal solution fast search strategy and fused feature vectors.

[0164] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cloud-native multi-architecture scheduling method of heterogeneous nodes, characterized in that, The system comprises: Identify the multi-dimensional architecture features of the heterogeneous node registration information and mark them as node labels to build a multi-dimensional feature system; Build a multi-architecture image to generate a unified image address; Determine the optimal scheduling node in response to multi-architecture deployment and scheduling requests; Wherein, the response to multi-architecture deployment and scheduling request, determine the optimal scheduling node includes: Predict the future resource state of the node to generate a resource prediction feature vector; Fuse node features, Pod architecture demand features, and resource prediction feature vectors to obtain a fusion feature vector; According to the near-optimal solution fast search strategy inspired by quantum, determine the optimal scheduling node from the candidate nodes based on the fusion feature vector; The fusion of node features, Pod architecture demand features, and resource prediction feature vectors to obtain a fusion feature vector includes: Build a perception attention layer for strengthening the architecture matching degree of Pod and node; Build a resource balance attention layer for optimizing cluster resource load balancing; The construction of the perception attention layer for strengthening the architecture matching degree of Pod and node includes: Map the Pod demand, node static features, and node dynamic features through a weight matrix to high-dimensional query vectors, key vectors, and value vectors; The multi-head attention mechanism is adopted, each head independently calculates an architecture matching score of a Pod and a node, and the scores are combined through The function is normalized to obtain a head vector. Splice the results and convert them into architecture matching features; The construction of the resource balance attention layer for optimizing cluster resource load balancing includes: calculating the comprehensive load of the node based on the weighted sum of CPU and memory utilization; Quantify the uniformity of cluster load based on the load probability distribution and balance entropy calculated based on the deviation of node load and cluster average value; Calculate the attention score through the node architecture features, node resource balance features, and prediction features; The prediction of the future resource state of the node to generate a resource prediction feature vector includes: The calculating the final feature vector by fusing the node architecture feature, the node resource balancing feature and the prediction feature comprises dynamic feature fusion. wherein, denotes a fusion feature vector, denotes a node attention score vector, denotes an architecture matching feature vector, denotes a resource prediction feature vector; representing an adaptive weight, representing a prediction feature weight; For fused feature vectors according to Normalization was performed, where, Represents the fused feature vector The One element, Representing vectors No. One element, for The normalized value; Indicates the dimension of the fused feature vector; The quantum-inspired near-optimal solution fast search strategy comprises the following steps: mapping a candidate node set with a quantity of into qubits, each qubit state being , , and setting an initial state as a uniform superposition, i.e. ; wherein , is a probability amplitude of the th qubit being in the state , is a superposition state of the th qubit. Fusion feature vector-based Computing a rotation angle for each qubit updating the qubit state by a rotation matrix iteration; Measuring the qubit state to get the node index with the highest probability , verifying the compatibility of the architecture, if , then selecting the node index , otherwise selecting the node index with the second highest probability and re-verifying until the architecture is compatible, where represents the Pod architecture requirement vector, represents the node index transpose of the static feature vector, represents the threshold value.

2. The cloud-native multi-architecture scheduling method of heterogeneous nodes according to claim 1, wherein, Build an input sequence based on the time series of the node dynamic state vector; Calculate and output the future node state sequence based on a 3-layer LSTM; Take the future node state sequence as a representative feature vector to generate a resource prediction feature vector. The calculation and output of the future node state sequence based on a 3-layer LSTM includes:

3. The cloud-native multi-architecture scheduling method of heterogeneous nodes according to claim 2, wherein, The taking of the future node state sequence as a representative feature vector to generate a resource prediction feature vector includes: computing the 1st layer LSTM, comprising: a forget gate: , for controlling the history information retention, wherein, represents matrix multiplication, represents the 1st layer forget gate weight matrix, represents the real set, represents the hidden layer dimension, represents the input layer dimension, T represents the matrix transpose, X hist represents the time series of the node past dynamic state vector, represents the 1st layer forget gate bias vector, represents the 1st layer time step hidden state vector, the initial value , represents the input feature vector of the time step , represents the forget gate output vector of the 1st layer time step , is an activation function, when the input ≥0, the output is equal to the input itself, when the input <0, the output is directly 0; Input gate and candidate cell state: input gate control , candidate state wherein: and denote the first layer input gate weight matrix and the first layer candidate cell state weight matrix, respectively, and denote the first layer input gate bias vector and the first layer candidate cell state bias vector, respectively, denotes the output vector of the first layer input gate at time step , denotes the first layer forget gate candidate cell state vector; Cell state update: Layer 1 time step of the cell state vector where, and denote the cell state vector of Layer 1 at time step and time step respectively, denotes element-wise multiplication; Output gate and hidden state: output gate control , where, represents the weight matrix of the 1st layer output gate, represents the bias vector of the 1st layer output gate, represents the output gate output vector of the 1st layer at time step , represents the hidden state vector of the 1st layer at time step ; Computing the 2nd layer LSTM; includes: the 2nd layer LSTM calculation method is same as the 1st layer LSTM calculation, with the 1st layer hidden state vector For input, parameters are , ,..., , the 2nd layer output hidden state vector ; computing the 3rd layer LSTM; including: the computing method of the 3rd layer LSTM is same as the 1st layer LSTM computing, with the hidden state vector of the 2nd layer for input, parameters are , , the 3rd layer output hidden state vector ; The last time step hidden state vector of the third layer LSTM is input into a fully connected layer, and the future prediction sequence is output wherein, represents the future prediction sequence, represents the prediction feature of the minute, represents the prediction feature of the minute, represents the last time step hidden state vector of the third layer, represents the last time step hidden state vector of the third layer, represents the output weight matrix of the feature, represents the output weight matrix of the feature, represents the output bias vector of the feature.

4. The cloud-native multi-architecture scheduling method of heterogeneous nodes according to claim 2, wherein, The system comprises: Selecting the prediction value of the future 3rd minute as a representative feature vector ; Based on the trained weight matrix, the weight of the key feature is enhanced, and a final resource prediction feature vector is output wherein: denotes the trained weight matrix, denotes outputting a final resource prediction feature vector as one of the inputs of the Transformer feature fusion unit.

5. The cloud-native multi-architecture scheduling method of heterogeneous nodes according to claim 1, wherein, The Pod requirement, the node static feature and the node dynamic feature are mapped into a high-dimensional query vector, a key vector and a value vector through a weight matrix, and the method comprises the following steps of: generating a query vector , a key vector and a value vector . , , In the formula, , represents a Pod architecture requirement vector, , represents a node static feature vector, , represents a node dynamic feature vector, , , respectively represent a query vector learnable weight matrix, a key vector learnable weight matrix and a value vector learnable weight matrix.

6. The cloud-native multi-architecture scheduling method of heterogeneous nodes according to claim 1, wherein, The splicing result is converted into an architecture matching feature, which includes: wherein head1, head2,..., head8 represent output vectors of 8 attention heads, represents an output transformation matrix, represents a splicing function of splicing output vectors of all attention heads in the feature dimension, represents an architecture matching feature vector.

7. The cloud-native multi-architecture scheduling method of heterogeneous nodes according to claim 1, wherein, The comprehensive load of the computing node based on the CPU and memory utilization weighted summation includes: load probability distribution and equilibrium entropy calculation: , , wherein, represents the load probability distribution of the node, represents the comprehensive load of the node , represents the number of nodes of the cluster, represents the comprehensive load of the node , represents a value measuring the uniformity of the load distribution; represents the CPU utilization rate of the i th node; represents the memory occupancy rate of the i th node.

8. The cloud-native multi-architecture scheduling method of heterogeneous nodes according to claim 7, wherein, The calculation of attention scores based on the deviation between node load and cluster average, and the equilibrium entropy, includes: Node attention score calculation: in, Indicates the load sensitivity coefficient. Indicates the entropy penalty weight. Represents a node The overall load, This represents the average overall load of the cluster. This represents an exponential function.

9. The system for implementing the cloud-native multi-architecture scheduling method of the heterogeneous node according to any one of claims 1-8, characterized in that, A multi-dimensional feature system construction unit for identifying the multi-dimensional architecture features of the heterogeneous node registration information and marking them as node labels to build a multi-dimensional feature system; A unified image address generation unit for building a multi-architecture image to generate a unified image address; An optimal scheduling node determination unit for determining the optimal scheduling node in response to multi-architecture deployment and scheduling requests; Wherein, the optimal scheduling node determination unit includes: A resource prediction feature vector generation module for predicting the future resource state of the node to generate a resource prediction feature vector; A fusion feature vector module for fusing node features, Pod architecture demand features, and resource prediction feature vectors; An optimal scheduling node determination module for determining the optimal scheduling node from the candidate nodes based on the fusion feature vector according to the near-optimal solution fast search strategy inspired by quantum. ​

Images