Workload multi-cluster scheduling method and system based on heat perception

Abstract

The present disclosure relates to the technical field of cloud computing, and particularly provides a workload multi-cluster scheduling method and system based on heat perception. The method is applied to a scheduling engine of a multi-cloud management platform, and the scheduling engine comprises a network constructor and a heat calculator, and comprises: obtaining API call information, user portrait data and cluster monitoring indicators; the network constructor constructs a heterogeneous triad network based on the API call information, the user portrait data and the cluster monitoring indicators; the heat calculator obtains heat values corresponding to each cluster by iterative calculation based on the heterogeneous triad network and using a heat calculation model; and based on the heat values corresponding to each cluster respectively, a to-be-scheduled workload is distributed to a target cluster set. The technical solution of the present disclosure makes the scheduling decision not only consider the cluster resource margin, but also take into account the user behavior activity and the application popularity, so as to realize dynamic adaptive adjustment of the number of replicas according to the cluster state and effectively improve the multi-cluster resource utilization.

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing technology, and in particular to a method and system for scheduling multi-cluster workloads based on heat perception. Background Technology

[0002] Kubernetes (hereinafter referred to as K8s), with its powerful container orchestration capabilities, has been widely used in cloud computing, microservices, edge computing, and AI infrastructure, becoming a core platform for modern cloud-native applications. Enterprises typically need to deploy and manage multiple K8s clusters to achieve cross-cluster service scheduling and load balancing. Against this backdrop, how to uniformly manage and schedule computing resources in a multi-cluster environment has become a critical issue that urgently needs to be addressed.

[0003] In related technologies, workload scheduling in multi-cluster environments is commonly achieved using methods such as federated clusters, multi-cluster management tools, or static weight strategies. However, most of these solutions only consider the resource attributes of the cluster itself, failing to incorporate other influencing factors such as user characteristics and business priorities, and lacking global coordination and dynamic adjustment capabilities. Furthermore, these methods largely cannot achieve cross-cluster scheduling of replica counts, making it difficult to dynamically adapt to cluster resource fluctuations or changes in user needs, resulting in insufficient flexibility and adaptability in scheduling decisions. Summary of the Invention

[0004] In view of this, the exemplary embodiments of this disclosure provide a workload multi-cluster scheduling method and system based on heat perception to solve the problems existing in the related technologies.

[0005] One aspect of the exemplary embodiments of this disclosure provides a workload multi-cluster scheduling method based on heat awareness, applied to the scheduling engine of a multi-cloud management platform. The scheduling engine includes a network builder and a heat calculator. The method includes: acquiring API call information, user profile data, and cluster monitoring metrics; the network builder constructing a heterogeneous three-link network based on the API call information, user profile data, and cluster monitoring metrics; the heat calculator iteratively calculating the heat value corresponding to each cluster based on the heterogeneous three-link network using a heat calculation model; and allocating the workload to be scheduled to a target cluster set based on the heat value corresponding to each cluster.

[0006] Another aspect of the exemplary embodiments of this disclosure provides a workload multi-cluster scheduling system based on heat perception. The system includes an API open platform, a scheduling engine, a monitoring engine, a task executor, and a user management module. The API open platform is used to record API call information entering and leaving the control plane. The user management module is used to store user profile data. The monitoring engine is used to collect cluster monitoring metrics for each cluster. The scheduling engine includes a network builder and a heat calculator. The network builder is used to construct a heterogeneous three-link network based on API call information, user profile data, and cluster monitoring metrics. The heat calculator is used to iteratively calculate the heat value corresponding to each cluster based on the heterogeneous three-link network using a heat calculation model. The scheduling engine is also used to allocate the workload to be scheduled to a target cluster set based on the heat value corresponding to each cluster. The task executor is used to distribute the workload to be scheduled to the clusters in the target cluster set according to the allocation results.

[0007] In another aspect of exemplary embodiments of this disclosure, a computer device is provided, including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the methods described in exemplary embodiments of this disclosure.

[0008] In another aspect of exemplary embodiments of this disclosure, a computer-readable storage medium is provided having a computer program / instructions stored thereon that, when executed by a processor, implements the methods described in exemplary embodiments of this disclosure.

[0009] In another aspect of exemplary embodiments of this disclosure, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the methods described in exemplary embodiments of this disclosure.

[0010] As will be described in detail below, a workload multi-cluster scheduling method based on heat perception according to an embodiment of this disclosure constructs a heterogeneous three-way network of users, applications, and clusters by acquiring API call information, user profile data, and cluster monitoring indicators. A heat calculator then iteratively calculates the heat value of each cluster using an improved PageRank algorithm based on the heterogeneous network. Finally, workloads are allocated to a set of target clusters based on the heat values. In addition to considering cluster resources and node matching, this scheme also incorporates characteristics such as cluster read / write speed, network bandwidth, and user attributes. Furthermore, this scheme supports dynamically scheduling workloads to multiple target clusters according to different replica ratios based on the current state of each cluster. This allows for adaptability to changes in business needs such as cluster resource fluctuations and sudden high-priority tasks, overcoming the shortcomings of static weight allocation methods. It also supports parallel deployment across multiple clusters, effectively improving the flexibility and reliability of cross-cluster deployment. Therefore, this scheme achieves multi-dimensional comprehensive perception of cluster heat quantification and dynamic adaptive scheduling based on this assessment, effectively improving resource utilization and load balancing in multi-cluster environments, reducing the risk of single-cluster overload, and fully meeting the actual needs for elastic scheduling in large-scale cloud-native scenarios. Attached Figure Description

[0011] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0012] Figure 1 This is a diagram illustrating the architecture of a heat-aware multi-cluster scheduling system for workloads provided in this embodiment of the disclosure. Figure 2 A flowchart illustrating the workload multi-cluster scheduling method based on heat perception provided in this embodiment of the disclosure; Figure 3 A schematic diagram illustrating the working principle of the scheduling engine provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram of a heterogeneous triplet network of user-application-cluster provided in an embodiment of this disclosure; Figure 5 A flowchart for calculating heat value provided in this embodiment of the disclosure; Figure 6 This is a user-application access relationship diagram provided in the embodiments of this disclosure; Figure 7 This is a user-application access time series diagram provided in the embodiments of this disclosure; Figure 8A flowchart illustrating the calculation of the number of copies provided in this embodiment of the disclosure; Figure 9 A structural block diagram of an electronic device provided in an embodiment of this disclosure; Figure 10 A schematic diagram of a computer program product provided in an embodiment of this disclosure. Detailed Implementation

[0013] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0014] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0015] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first", "second", etc., used in this disclosure are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0016] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0017] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0018] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0019] Kubernetes (hereinafter referred to as K8s), with its powerful container orchestration capabilities, has been widely used in cloud computing, microservices, edge computing, and AI infrastructure, becoming a core platform for modern cloud-native applications. However, as K8s is widely adopted in enterprises, its limitations are gradually becoming apparent. On the one hand, there are hard constraints on the size of a single cluster, which cannot meet the needs of ultra-large-scale businesses. On the other hand, a single cluster has the risk of a single point of failure; once a critical component of the control plane fails, it will cause the cluster to lose connectivity or the scheduling to be interrupted, affecting the normal operation of the business.

[0020] Therefore, enterprises typically need to deploy and manage multiple Kubernetes clusters to achieve cross-cluster service scheduling and load balancing, support disaster recovery and business isolation, and improve business scalability, reliability, and continuity. Against this backdrop, how to uniformly manage and schedule computing resources in a multi-cluster environment, and intelligently select the optimal cluster to complete job scheduling based on user needs, has become a critical issue that urgently needs to be addressed.

[0021] In related technologies, workload scheduling in multi-cluster environments is commonly achieved using methods such as federated clusters, multi-cluster management tools, or static weight strategies. However, most of these solutions only consider the cluster's own resource attributes, such as CPU / GPU, memory, storage, and disk, without incorporating other influencing factors such as user attributes and time windows, thus lacking global coordination and dynamic adjustment capabilities. Furthermore, these methods largely fail to achieve cross-cluster scheduling of replica counts and struggle to dynamically adapt to cluster resource fluctuations or changes in user needs, resulting in insufficient flexibility and adaptability in scheduling decisions.

[0022] Therefore, to address the aforementioned issues, this exemplary embodiment provides a workload multi-cluster scheduling method based on heat perception. It establishes a heterogeneous three-network as the foundation for heat calculation by integrating API call records, user profiles, and real-time cluster monitoring metrics through a network builder. Then, an improved PageRank algorithm is used for iterative calculation via a heat calculator, ensuring that the heat value of each cluster takes into account resource availability, user activity, and application popularity. Finally, the number of replicas of the workload to be scheduled is allocated to selected low-heat clusters according to the inverse normalized ratio of the heat value, and fine-tuned by rounding the residuals to ensure precise consistency in the total number of replicas. This technical solution enables scheduling decisions to consider not only cluster resource availability but also user behavior and time trends, achieving dynamic adaptive adjustment of the number of replicas based on cluster status, effectively improving multi-cluster resource utilization and the flexibility of business deployment.

[0023] For example, Figure 1 The architecture diagram of the heat-aware multi-cluster scheduling system for workloads provided in this disclosure is as follows: Figure 1As shown, the overall architecture includes: API Manager, SchedulerEngine, Monitor, Executor, and User Manager. The functions of each module are as follows: The API open platform receives user requests and is responsible for recording all API call information entering and leaving the control plane, including call path, call time, call volume, caller identity, and the application to which it belongs.

[0024] The scheduling engine consists of two sub-modules: the network builder (NetCreator) and the heat calculator (Heat Calculator). The scheduling engine is responsible for receiving Kubernetes workloads submitted by users, calculating the heat, and then distributing the workload replicas to the target cluster set according to an optimized ratio.

[0025] The monitoring engine collects real-time resources from all managed clusters, and the monitoring metrics include node CPU utilization, memory utilization, Pod running status, disk read / write speed, disk utilization, IO read / write time, and network bandwidth utilization, and reports this data to the scheduling engine on a regular basis.

[0026] The task executor receives scheduling decisions from the scheduling engine, including a list of target clusters and the number of replicas for each cluster. The task executor also calls the APIs of downstream clusters to actually create Pod replicas of the workload in the specified clusters. The task executor also includes a cluster manager, which runs clusters 1 to N, and manages public clouds (such as Alibaba Cloud and Tencent Cloud), dedicated clouds, private clouds, and user-local data centers.

[0027] User management provides functions for adding, deleting, modifying, and querying users, and records detailed user information, including user type and membership level.

[0028] The bottom of the diagram shows a heterogeneous multi-cloud infrastructure layer, including public clouds (such as Alibaba Cloud, Tencent Cloud, etc.), dedicated clouds, private clouds, and user local data centers. Each infrastructure domain runs a managed Kubernetes cluster (labeled as cluster 1 to cluster N in the diagram).

[0029] Based on this, the above scheduling scheme architecture provides a data foundation for subsequent popularity calculation by integrating user profile information, real-time cluster resource information and API call records, and solves the technical problems of existing schemes that rely only on the remaining cluster resources and ignore user behavior and call dynamics.

[0030] For example, Figure 2This is a flowchart illustrating a heat-aware multi-cluster scheduling method for workloads provided in an embodiment of this disclosure. The method is applied to the scheduling engine of a multi-cloud management platform, which includes a network builder and a heat calculator. Figure 2 As shown, the specific steps may include: Step S210: Obtain API call information, user profile data, and cluster monitoring metrics.

[0031] Step S220: The network builder constructs a heterogeneous triple network based on API call information, user profile data, and cluster monitoring metrics.

[0032] Step S230: The popularity calculator is based on a heterogeneous triple network and uses a popularity calculation model to iteratively calculate and obtain the popularity value corresponding to each cluster.

[0033] Step S240: Based on the heat value corresponding to each cluster, the workload to be scheduled is allocated to the target cluster set.

[0034] For example, Figure 3 A schematic diagram of the working principle of the scheduling engine provided in the embodiments of this disclosure, such as... Figure 3 As shown in the diagram, the left side represents the input sources, including call records from the API open platform, user profiles from user management, and cluster metrics from the monitoring engine. This data is input into the network builder, which outputs a heterogeneous tri-network of users, applications, and clusters, represented as a graph. This heterogeneous tri-network is then fed into a popularity calculator, which runs an improved PageRank iterative algorithm, ultimately outputting the popularity value for each cluster. The right side of the diagram indicates that the popularity value will be used as input for calculating the replica count.

[0035] The nodes in the heterogeneous triple network of user-application-cluster are divided into three categories: user nodes, application nodes, and cluster nodes. The edges are established based on the actual access and deployment relationships, and the weight of the edges is determined by the transition probability matrix.

[0036] For example, based on the collected user access information, application deployment information, and cluster status information, the network builder constructs a heterogeneous three-way network of users, applications, and clusters. The heterogeneous three-way network can be represented as a weighted directed graph.

[0037] For example, Figure 4 This is a schematic diagram of a heterogeneous triplet network of user-application-cluster provided in an embodiment of this disclosure, as shown below. Figure 4As shown, the nodes are divided into three columns from left to right: the left column represents cluster nodes, specifically labeled C1, C2, and C3; the middle column represents application nodes, specifically labeled A1, A2, A3, A4, and A5; and the right column represents user nodes, specifically labeled U1, U2, U3, and U4. A one-way directed arrow connects the left and middle columns, pointing from the cluster nodes to the application nodes, indicating that the corresponding application is deployed on each cluster, and popularity propagates from the cluster side to the application side. Similarly, a one-way directed arrow connects the middle and right columns, pointing from the application nodes to the user nodes, indicating that each application is accessed by the corresponding user, and popularity propagates from the application side to the user side.

[0038] In the heterogeneous three-way network of users, applications, and clusters, the three types of nodes have the following logical relationships: applications are deployed in clusters, users call services provided by applications through APIs, and users and clusters are indirectly connected through applications as an intermediary bridge. Based on this network structure, the popularity value follows the following mutual influence mechanisms: applications called by popular users are more popular, applications from popular clusters are more popular, users who call more popular applications are more popular, and clusters that produce more popular applications are more popular.

[0039] Based on the theoretical logic of the mutual influence of the popularity values ​​of the three roles and the constructed relationship network, this embodiment uses a popularity calculator and a popularity calculation model to perform iterative calculations until the popularity values ​​of each node converge, and finally extracts the popularity value corresponding to each cluster.

[0040] In this embodiment, the popularity calculation model can employ an improved PageRank algorithm. During the iteration process, popularity is propagated among the three types of nodes according to the following rules: The popularity value of cluster nodes is updated based on the current popularity value of application nodes and the application-to-cluster migration probability. The popularity value of user nodes is updated based on the current popularity value of application nodes and the user-to-application migration probability. The popularity value of application nodes comes partly from the popularity value of cluster nodes through the propagation of cluster-to-application migration probability, and partly from the popularity value of user nodes through the transpose of user-to-application migration probability.

[0041] The above update steps are iterated repeatedly until convergence occurs when the distance between the cluster popularity vector and the application popularity vector is less than a preset threshold for a predetermined number of consecutive iterations. After convergence, the current popularity value of each cluster is output as the basis for subsequent replica allocation decisions.

[0042] After obtaining the heat value of each cluster, the workload to be scheduled is allocated to the target cluster set. The allocation logic may include: the lower the heat value of a cluster, the more abundant the system resources are, and the lower the heat value of the existing applications on the cluster, making it more suitable to accept new workload replicas; conversely, the higher the heat value of a cluster, the higher the resource utilization and the less available resources are left, and fewer replicas should be allocated to it.

[0043] Based on this, a heterogeneous three-way network of users, applications, and clusters is constructed by acquiring API call information, user profile data, and cluster monitoring metrics. A heat calculator then iteratively calculates the heat value of each cluster using an improved PageRank algorithm based on this heterogeneous network. Finally, workloads are allocated to the target cluster set based on the heat values. In addition to considering cluster resources and node matching, this solution also incorporates characteristics such as cluster read / write speed, network bandwidth, and user attributes. Furthermore, this solution supports dynamically scheduling workloads to multiple target clusters according to different replica ratios based on the current state of each cluster. This allows for adaptability to changes in business needs such as cluster resource fluctuations and sudden high-priority tasks, overcoming the shortcomings of static weight allocation methods. It also supports parallel deployment across multiple clusters, effectively improving the flexibility and reliability of cross-cluster deployment. Therefore, this solution achieves multi-dimensional comprehensive perception of cluster heat quantification and dynamic adaptive scheduling based on this assessment, effectively improving resource utilization and load balancing in multi-cluster environments, reducing the risk of single-cluster overload, and fully meeting the actual needs for elastic scheduling in large-scale cloud-native scenarios.

[0044] Based on the above embodiments, in another embodiment provided in this disclosure, the heat calculator, based on a heterogeneous triple network, uses an iterative calculation model to obtain the heat value corresponding to each cluster, which may include: The initial heat values ​​of application nodes and user nodes are set to be uniformly distributed, while the initial heat values ​​of cluster nodes are calculated by weighting multiple monitoring metrics. Update the cluster popularity value based on the current application node popularity value and the application-cluster transition probability matrix; Update the user popularity value based on the current application node popularity value and the user-application transition probability matrix; The application popularity value is updated together based on the current cluster node popularity value and the cluster-application transition probability matrix, as well as the current user node popularity value and the transpose of the user-application transition probability matrix; The update steps are executed iteratively until convergence occurs when the distance between the cluster popularity value vector and the application popularity value vector is less than a preset threshold for a consecutive preset number of times. The current popularity value of each cluster is then output.

[0045] For example, Figure 5 The flowchart for calculating the heat value provided in the embodiments of this disclosure is as follows: Figure 5As shown, the process begins by inputting user access information, application deployment information, and cluster status information. Then, the network construction phase begins. First, based on the access relationship between users and applications, and considering call time, call volume, and user attributes, edge weights are calculated to construct a user-application subnet. Next, based on the deployment affiliation relationship between applications and clusters, and the proportion of replicas of each application in different clusters, an application-cluster subnet is constructed. After constructing these two subnets, they are merged into a heterogeneous relationship network, and a heat value calculation is performed based on this network. Finally, the calculated heat values ​​for each cluster are output.

[0046] For example, Table 1 shows the pseudocode for the PageRank popularity calculation model: Table 1. Pseudocode for the PageRank popularity calculation model

[0047] The standard PageRank can only handle a single type of node, while the PageRank heat calculation model proposed in this embodiment defines three different sets of transition probability matrices among three types of heterogeneous nodes (user U, application A, and cluster C), and alternately updates the heat values ​​of each type of node until global convergence.

[0048] in: This indicates the initial popularity value of the application. This represents the total number of applications in the system. This represents the user's initial popularity value, where M is the total number of users in the system. This represents the initial heat value of the j-th cluster. i is the i-th monitoring metric for the cluster, which can include CPU utilization, memory utilization, disk read / write speed, disk usage, IO read / write time, and network bandwidth utilization. Let be the weight of the i-th monitoring metric in the cluster, satisfying ; Let be the normalized score of the j-th cluster on the i-th indicator. A higher normalized score indicates lower popularity, so we take . , where x is the normalized score.

[0049] Represents the user-application transition probability matrix; This represents the application-cluster transition probability matrix; This represents the cluster-application transition probability matrix.

[0050] Convergence is determined when the Euclidean distance between the cluster popularity vector and the application popularity vector in two consecutive iterations is less than a threshold. The iteration terminates when the time is reached. In this embodiment, the preset number of iterations is set to two.

[0051] Based on this, by expanding to three types of heterogeneous nodes and three sets of asymmetric transition matrices, this model, for the first time, integrates user activity, application popularity, and cluster load status under the same probabilistic framework for iterative convergence. This enables the final cluster popularity to have dual predictive capabilities for current resource availability and future load growth trends. Compared to solutions that simply compare remaining CPU / memory, this model effectively avoids short-term bursts of high traffic from overwhelming a cluster that has already scheduled all replicas, significantly improving the robustness of scheduling decisions.

[0052] Based on the above embodiments, in another embodiment provided in this disclosure, in the above user-application transition probability matrix, the edge weight from user node to application node is determined based on user influence coefficient, time decay factor and cumulative access quality; wherein, user influence coefficient is determined by user type and membership level, time decay factor is calculated based on the time difference between the current time and the last access time and cooling coefficient, and cumulative access quality is calculated based on the amount of historical call data through time decay recursion.

[0053] For example, Figure 6 This is a user-application access relationship diagram provided in the embodiments of this disclosure. Figure 6 This represents the multiple access records of user U4 to application A5. The five network edges in the graph represent the access sequence number (1 to 5), the time parameter t, and the data volume parameter v. Specifically, the time parameters for the 1st to 5th accesses are denoted as t(1) to t(5), and the corresponding single data volume is denoted as v(1) to v(5). The edge weights are represented by the user-application probability transition matrix. It can be calculated based on the user's API call records.

[0054] There may be multiple call relationships between a single user and a single application. In each call, the time and volume of the user's API calls within the application vary. The greater the volume of calls, the greater the impact of that call on the application's popularity; the closer the call time is to the current moment, the greater the impact of that call on the application's popularity.

[0055] Furthermore, different users have different impacts on the application when calling the same application. Enterprise users have a greater impact on the application than individual users, and higher-level members have a greater impact on the application than lower-level members.

[0056] For example, Figure 7This is a user-application access time series diagram provided in an embodiment of this disclosure. The horizontal axis represents the access sequence number (t1 to t6), and the vertical axis represents the corresponding call data volume. It can be seen that the access data volume fluctuates over time, and there are significant differences in the access data volume at different time points, indicating that the degree of impact of access on application popularity varies at different times.

[0057] Based on the above influence logic, the weight between users and applications is determined by factors such as user attributes, call frequency, call time and call volume, and time series algorithms are used to measure these factors.

[0058] For example, the formula for calculating user-application weight can be expressed as:

[0059]

[0060]

[0061] in, For the current moment and By user The time difference between the last access time; The coefficient of performance is the cooling factor. for The type value indicates that there are three types of users: internal users, enterprise users, and individual users. For users There are four membership levels: regular member, bronze member, silver member, and gold member. For users No. Second visit The mass values ​​of both sides at that time; For users No. Second visit The amount of data at that time; This is the time decay factor; user No. Second visit Compared to the first visit The time difference.

[0062] Based on the above calculations, normalizing all user-application edge weights yields the user-application transition probability matrix. Each element represents the probability of jumping from a user node to an application node.

[0063] Based on this, by introducing user type, membership level, call time cooling coefficient, and call volume time decay recursion, the user-application subnet can accurately reflect the differentiated impact of different user levels' access behavior on application popularity at different time points, avoiding the defect of treating all access records equally, and improving the accuracy and timeliness of popularity calculation.

[0064] Based on the above embodiments, in another embodiment provided in this disclosure, in the above application-cluster transition probability matrix, the edge weight from the application node to the cluster node is determined based on the ratio of the number of replicas of the application in the cluster to the total number of replicas of the application in all clusters.

[0065] In this embodiment, the association between the application and the cluster is created based on the deployment affiliation relationship between the application and the cluster.

[0066] Specifically, when an application is deployed to a cluster and runs a corresponding number of Pod replicas within that cluster, a network relationship edge is established between the application and the cluster. This edge is bidirectional, representing the propagation of application popularity from the cluster and the propagation of cluster popularity from the application, respectively. The edge weights in each direction are calculated using different methods. Specifically, this may include: First, an application-cluster probability transition matrix is ​​constructed based on the affiliation relationship between applications and clusters. .matrix This reflects the fact that, given an application that may be deployed on multiple clusters, the probability of its spread to each cluster when popularity spreads from the application depends on the distribution of the application's replicas across the clusters.

[0067] For example, the probability of an application switching to a particular cluster is the ratio of its number of replicas in the current cluster to the total number of replicas across all clusters, calculated as follows:

[0068] in, To apply the weight values ​​of the edges from k to cluster i, To apply the number of replicas of k in cluster i, Let N be the total number of replicas of application k across all clusters, where N is the total number of clusters.

[0069] Therefore, the more replicas of an application on a cluster, the greater the probability that popularity will spread from the application to the cluster, and the more popularity the cluster will receive from the application.

[0070] Based on the above embodiments, in another embodiment provided in this disclosure, in the above cluster-application transition probability matrix, the edge weight from the cluster node to the application node is determined based on the ratio of the number of replicas of the application in the cluster to the total number of replicas of all applications in the cluster.

[0071] In this embodiment, a cluster-application probability transition matrix is ​​constructed based on the distribution of applications within the cluster. .matrix The matrix reflects that, given a cluster on which multiple different applications are deployed simultaneously, the probability of heat spreading from the cluster to each application depends on the distribution of replicas of each application in the cluster.

[0072] For example, the probability of a cluster switching to a certain application is the ratio of the number of replicas of the current application in the cluster to the total number of replicas of all applications in the cluster, calculated as follows:

[0073] in, Let be the weight of the edge from cluster k to application i. To determine the number of replicas of application i in cluster k, Let N be the total number of replicas of all applications in cluster k, where N is the total number of applications in the cluster.

[0074] Therefore, the more replicas an application occupies in a cluster, the greater the probability that popularity will spread from that cluster to the application.

[0075] It should be noted that in the above calculations, the number of replicas of the same application may be different on different clusters, and the number of replicas of different applications on the same cluster may also be different; for clusters where the application has not yet been deployed, the corresponding number of replicas is zero, and the corresponding migration probability is also zero.

[0076] Based on this, by calculating the transition probability in the two directions mentioned above, reasonable weight values ​​are assigned to the bidirectional edges between the application and the cluster, so that the heat can be transmitted in a differentiated manner based on the actual replica deployment density in the two directions of application→cluster and cluster→application.

[0077] Based on the above embodiments, in another embodiment provided in this disclosure, the allocation of the workload to be scheduled to the target cluster set based on the heat value corresponding to each cluster may include: Select N clusters whose heat values ​​meet the preset conditions as the target cluster combination; The number of pre-allocated replicas for each cluster is determined based on the inverse proportion of the heat value of each cluster in the target cluster combination. The pre-allocated replica number is rounded down to obtain the final allocated replica number for each cluster.

[0078] In this embodiment, after calculating the popularity value of each cluster using the PageRank algorithm, the system needs to determine the number of replicas to be allocated on each cluster based on the popularity value of the workload to be scheduled.

[0079] The basic allocation principle of this embodiment can be: the lower the cluster's popularity, the more abundant its system resources are, and the lower the popularity of existing applications deployed on the cluster. That is, the cluster is currently in a relatively idle or low-load state, and is therefore more suitable to accept new workload replicas. Conversely, the higher the cluster's popularity, the higher its resource utilization, the less remaining available resources, or the more applications on it are being accessed by a large number of users. Therefore, the cluster is already in a relatively busy state and is not suitable to continue receiving additional scheduling load.

[0080] Based on the above principles Figure 8 The flowchart for calculating the number of copies provided in this embodiment of the disclosure specifically includes the following steps: First, after obtaining the popularity values ​​of all clusters, sort all clusters in ascending order of popularity value, that is, the cluster with the lowest popularity value is ranked first.

[0081] Next, the system receives the user's input parameter for the number of scheduling clusters, denoted as N. This parameter indicates how many clusters the user expects to distribute the replicas of the current workload across. The system extracts the top N clusters with the lowest heat values ​​from the forward-sorted cluster list as the target cluster set for this scheduling.

[0082] Then, the heat values ​​of the above N clusters are normalized.

[0083] Next, obtain the total number of workload replicas input by the user, denoted as R. For the i-th cluster, the pre-allocated number of replicas is calculated using a weighted method based on the inverse of popularity.

[0084] Specifically, first, calculate the reciprocal of the cluster's popularity value; then, calculate the proportion of this reciprocal in the sum of the reciprocals of the popularity values ​​of all N clusters; finally, multiply this proportion by the total number of replicas R to obtain the pre-allocated number of replicas for the cluster.

[0085]

[0086] in, For clusters Number of copies allocated, For clusters The number of pre-allocated replicas, For cluster replica fine-tuning functions, This represents the total number of replicas for the workload. For clusters Popularity value The number of clusters that need to be scheduled for the workload.

[0087] It can be seen that the smaller the cluster heat value, the larger its reciprocal, and the more pre-allocated replicas are obtained; the larger the cluster heat value, the smaller its reciprocal, and the fewer pre-allocated replicas are obtained, thus achieving the allocation goal of more scheduling for cold clusters and fewer scheduling for hot clusters.

[0088] Based on the above embodiments, in another embodiment provided in this disclosure, the above-mentioned rounding of the pre-allocated replica number to obtain the final allocated replica number for each cluster may include: Round down the pre-allocated number of replicas to get the rounded number of replicas; Calculate the difference between the current total number of replicas and the total number of replicas to obtain the remaining number of replicas to be allocated; The remaining number of unallocated replicas will be assigned to the corresponding cluster with the largest rounded residual.

[0089] In this embodiment, since the above calculation yields a floating-point number, while the actual number of Pod replicas must be an integer, it is necessary to round the pre-allocated replica number and ensure that the sum of the actual allocated replicas in each cluster equals the total number of replicas R specified by the user. This embodiment employs a residual fine-tuning method (…). The function is precisely tuned, and the specific fine-tuning process is as follows: First, round down: ; Calculate the current total number of replicas: ; Calculate the remaining number of replicas that need to be allocated: ; Assign M replicas to The largest (i.e., the largest residual) One cluster; Final Cluster The number of copies allocated is: ; In this way, a unique integer number of replicas is determined for each candidate cluster, and the sum of the number of replicas in each cluster is exactly equal to the total number of replicas specified by the user.

[0090] Subsequently, the task executor, based on the allocation result, distributes the corresponding number of Pod replicas of the workload to the corresponding target clusters to complete the deployment.

[0091] Based on this, the replica number determination scheme provided in this embodiment dynamically calculates the replica allocation based on the real-time cluster heat value. When the cluster experiences resource strain due to heavy workloads, the heat value increases, and fewer replicas will be automatically allocated in subsequent scheduling cycles. Conversely, when the cluster expands or workloads decrease, the heat value decreases, and more replicas will be automatically allocated. This adaptive mechanism can quickly respond to cluster resource fluctuations and sudden high-priority tasks, compensating for the lag of static weights or manual configuration schemes, and significantly improving the overall cluster throughput and resource utilization.

[0092] One or more technical solutions provided in the exemplary embodiments of this disclosure first construct a heterogeneous three-way network of user-application-cluster and use an improved PageRank algorithm to iteratively calculate the cluster popularity value, so that the popularity assessment integrates multiple factors such as user attributes, call time and multi-dimensional cluster monitoring indicators, overcoming the limitation of traditional scheduling schemes that only rely on a single resource dimension.

[0093] Secondly, user type, membership level, cooling coefficient, and time decay recursion are introduced into the user-application subnet to make the impact of historical access data on popularity decay over time, ensuring that popularity calculation responds sensitively to real-time business changes.

[0094] Secondly, the bidirectional transfer probability is calculated based on the replica ratio in the application-cluster subnet, realizing the asymmetric transmission of heat between the application and the cluster, and accurately reflecting the actual impact of deployment density on cluster heat.

[0095] Finally, in determining the number of replicas, an adaptive dynamic cross-cluster scheduling method was achieved by combining a weighted allocation of replicas based on the inverse of popularity with a residual fine-tuning rounding method.

[0096] Therefore, the workload multi-cluster scheduling method based on heat perception provided in the exemplary embodiments of this disclosure realizes quantitative evaluation of cluster heat in dimensions such as user behavior, application deployment and cluster status, and guides the dynamic adaptive allocation of replicas based on heat values, effectively improving resource utilization and load balancing level in multi-cluster environments, reducing the risk of single-cluster overload, and solving the technical problems of single-dimensional scheduling limitations and insufficient cross-cluster scheduling capabilities in existing scheduling schemes.

[0097] The foregoing primarily describes the solutions provided by exemplary embodiments of this disclosure. It is understood that, in order to achieve the above functions, the electronic device includes corresponding hardware structures and / or software modules for performing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0098] The exemplary embodiments of this disclosure can divide the electronic device into functional units according to the above method examples. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into a single processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in the exemplary embodiments of this disclosure is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0099] Exemplary embodiments of this disclosure also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of this disclosure.

[0100] Exemplary embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to embodiments of this disclosure.

[0101] Figure 9 The structural block diagram of the electronic device provided in the embodiments of this disclosure will now be described as follows: An electronic device 900 that can serve as a server or client of this disclosure is an example of a hardware device that can be applied to various aspects of this disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the disclosure described and / or claimed herein.

[0102] like Figure 9 As shown, the electronic device 900 includes a computing unit 901, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 902 or a computer program loaded from a storage unit 908 into a random access memory (RAM) 903. The RAM 903 may also store various programs and data required for the operation of the electronic device 900. The computing unit 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0103] Multiple components in electronic device 900 are connected to I / O interface 905, including: input unit 906, output unit 907, storage unit 908, and communication unit 909. Input unit 906 can be any type of device capable of inputting information to electronic device 900. Input unit 906 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 907 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 908 may include, but is not limited to, disk and optical disk. Communication unit 909 allows electronic device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0104] The computing unit 901 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 901 performs the various methods and processes described above. The various methods described above can all be implemented as computer software programs, which are tangibly contained in a machine-readable medium, such as storage unit 908. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 900 via ROM 902 and / or communication unit 909.

[0105] Figure 10 The diagram illustrates a computer program product provided in an embodiment of this disclosure. An exemplary embodiment of this disclosure also provides a computer program product 1000, including a computer program 1001, wherein the computer program 1001, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this disclosure.

[0106] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0107] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0108] As used in this disclosure, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0109] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0110] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0111] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0112] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this disclosure are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a terminal, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center integrating one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0113] Although this disclosure has been described in conjunction with specific features and embodiments, it will be apparent that various modifications and combinations can be made therein without departing from the spirit and scope of this disclosure. Accordingly, this specification and drawings are merely exemplary illustrations of the disclosure as defined by the appended claims and are to be considered as covering any and all modifications, variations, combinations, or equivalents within the scope of this disclosure. It is obvious that those skilled in the art can make various alterations and modifications to this disclosure without departing from its spirit and scope. Thus, this disclosure is also intended to include any such modifications and modifications that fall within the scope of the claims of this disclosure and their equivalents.

Claims

1. A workload multi-cluster scheduling method based on heat perception, characterized in that, A scheduling engine applied to a multi-cloud management platform, the scheduling engine including a network builder and a heat calculator, the method comprising: Obtain API call information, user profile data, and cluster monitoring metrics; The network builder constructs a heterogeneous triple network based on the API call information, the user profile data, and the cluster monitoring metrics. The heat calculator is based on the heterogeneous triple network and uses a heat calculation model to iteratively calculate and obtain the heat value corresponding to each cluster. Based on the heat value corresponding to each cluster, the workload to be scheduled is distributed to the target cluster set.

2. The method according to claim 1, characterized in that, The popularity calculator, based on the heterogeneous triplet network, uses an iterative popularity calculation model to obtain the popularity value corresponding to each cluster, including: The initial heat values ​​of application nodes and user nodes are set to be uniformly distributed, while the initial heat values ​​of cluster nodes are calculated by weighting multiple monitoring metrics. Update the cluster popularity value based on the current application node popularity value and the application-cluster transition probability matrix; Update the user popularity value based on the current application node popularity value and the user-application transition probability matrix; The application popularity value is updated together based on the current cluster node popularity value and the cluster-application transition probability matrix, as well as the current user node popularity value and the transpose of the user-application transition probability matrix; The update steps are executed iteratively until convergence occurs when the distance between the cluster popularity value vector and the application popularity value vector is less than a preset threshold for a consecutive preset number of times. The current popularity value of each cluster is then output.

3. The method according to claim 2, characterized in that, In the user-application transition probability matrix, the edge weights from user nodes to application nodes are determined based on the user influence coefficient, time decay factor, and cumulative access quality. The user influence coefficient is determined by the user type and membership level, the time decay factor is calculated based on the time difference between the current time and the last access time and the cooling coefficient, and the cumulative access quality is calculated based on the historical call data volume through a time decay recursive method.

4. The method according to claim 2, characterized in that, In the application-cluster transition probability matrix, the edge weights from application nodes to cluster nodes are determined based on the ratio of the number of replicas of the application in the cluster to the total number of replicas of the application across all clusters.

5. The method according to claim 2, characterized in that, In the cluster-application transition probability matrix, the edge weights from cluster nodes to application nodes are determined based on the ratio of the number of replicas of the application in the cluster to the total number of replicas of all applications in the cluster.

6. The method according to claim 1, characterized in that, The process of allocating the workload to be scheduled to the target cluster set based on the heat value corresponding to each cluster includes: Select N clusters whose heat values ​​meet the preset conditions as the target cluster combination; The number of pre-allocated replicas for each cluster is determined based on the inverse proportion of the heat value of each cluster in the target cluster combination. The pre-allocated replica number is rounded down to obtain the final allocated replica number for each cluster.

7. The method according to claim 6, characterized in that, The determination of the pre-allocated replica number for each cluster based on the reciprocal proportion of the heat value of each cluster in the target cluster combination includes: The heat values ​​corresponding to each cluster are normalized. The number of pre-allocated replicas for each cluster is calculated based on the ratio of the reciprocal of the normalized heat value.

8. The method according to claim 6, characterized in that, The step of rounding down the pre-allocated replica count to obtain the final allocated replica count for each cluster includes: The pre-allocated number of replicas is rounded down to obtain the rounded number of replicas; Calculate the difference between the current total number of replicas and the total number of replicas to obtain the remaining number of replicas to be allocated; The remaining number of replicas to be allocated is assigned to the corresponding cluster with the largest rounded residual.

9. A workload multi-cluster scheduling system based on heat perception, characterized in that, The system includes an API open platform, a scheduling engine, a monitoring engine, a task executor, and a user management module; The API open platform is used to record API call information for entering and exiting the control plane; The user management module is used to store user profile data; The monitoring engine is used to collect cluster monitoring metrics for each cluster. The scheduling engine includes a network builder and a heat calculator; The network builder is used to construct a heterogeneous triple network based on the API call information, the user profile data, and the cluster monitoring metrics; the popularity calculator is used to iteratively calculate the popularity value of each cluster based on the heterogeneous triple network using a popularity calculation model. The scheduling engine is also used to allocate the workload to be scheduled to the target cluster set based on the heat value corresponding to each cluster. The task executor is used to distribute the workload to be scheduled to the cluster of the target cluster set according to the allocation result.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method according to any one of claims 1-8.

11. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the method of any one of claims 1-8.

12. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the method of any one of claims 1-8.

Images