Multi-cluster scheduling method and device for hybrid cloud and medium

Abstract

The invention discloses a hybrid cloud-oriented multi-cluster scheduling method and device and a medium, and relates to the technical field of distributed system resource management. The method comprises the following steps: continuously collecting multi-dimensional state data of a cluster to be scheduled, and encrypting and transmitting the multi-dimensional state data to a central node to obtain a global state view; if the multi-dimensional state data meets a preset triggering condition, analyzing a service strategy associated with the global state view to obtain a structured constraint condition and weight configuration; removing clusters contained in the global state view based on a structured constraint condition to obtain a candidate cluster list; calculating a cost factor, a performance factor, a utilization rate factor and a stability factor of each candidate cluster in the candidate cluster list, and performing weighted calculation with the weight configuration to obtain a comprehensive score of each candidate cluster; and extracting the cluster with the highest comprehensive score as a target cluster, and calling the integrated scheduling executor to perform flow scheduling and resource scheduling on the target cluster.

Description

Technical Field

[0001] This application relates to the field of distributed system resource management technology, and in particular to a multi-cluster scheduling method, device and medium for hybrid clouds. Background Technology

[0002] In a hybrid cloud environment, achieving intelligent scheduling of multiple Kubernetes clusters is a key challenge in the field of cloud computing and container orchestration. Currently, this field mainly relies on scheduling schemes based on static labels or single resource metrics, such as multi-cluster management tools like Karmada and Clusternet, as well as related solutions provided by major public cloud vendors.

[0003] However, these existing technologies have several significant drawbacks. First, their scheduling dimensions are relatively singular, generally lacking comprehensive consideration of multi-dimensional factors such as cost, performance, and compliance, making it difficult to achieve global optimization. For example, when facing business needs that require both low latency and low cost, existing solutions often require operations personnel to manually write a large number of configuration rules and cannot dynamically respond to real-time changes in resource prices or network status. Second, schedulers generally lack cost awareness and cannot dynamically adjust based on fluctuations in cloud vendor instance prices, resulting in non-critical tasks often running on high-priced instances for extended periods, causing significant resource waste. Third, resource scheduling and traffic scheduling are usually disconnected in the existing system, handled independently by different systems. This separation can easily lead to inconsistencies between resource deployment and traffic routing goals, resulting in unnecessary cross-cloud transmission costs and increased end-to-end latency. In addition, existing scheduling strategies are often rigid and lack flexibility. Complex business intentions require professionals to develop custom plugins or controllers, leading to long response cycles for business changes, resulting in high operation and maintenance costs and low efficiency.

[0004] Therefore, for hybrid cloud environments, how to leverage state-aware modules and multi-factor decision engines to achieve cost-effective, performance-compliant, and compliant automated scheduling of workloads and traffic across multiple Kubernetes clusters, thereby significantly improving resource utilization efficiency and system operation and maintenance efficiency, has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a multi-cluster scheduling method, device, and medium for hybrid clouds to solve the following technical problem: how to use a state-aware module and a multi-factor decision engine to achieve automated scheduling of workloads and traffic across multiple Kubernetes clusters with optimal cost, performance, and compliance controllability, thereby significantly improving resource utilization efficiency and system operation and maintenance efficiency.

[0006] In a first aspect, embodiments of this application provide a multi-cluster scheduling method for hybrid clouds. The method includes: continuously collecting multi-dimensional state data of the clusters to be scheduled, and encrypting and transmitting the multi-dimensional state data to a central node to obtain a global state view; if the multi-dimensional state data meets preset triggering conditions, parsing the business policies associated with the global state view to obtain structured constraints and weight configurations; based on the structured constraints, eliminating clusters included in the global state view to obtain a candidate cluster list; calculating the cost factor, performance factor, utilization factor, and stability factor of each candidate cluster in the candidate cluster list, and performing a weighted calculation with the weight configuration to obtain a comprehensive score for each candidate cluster; extracting the cluster with the highest comprehensive score as the target cluster, and calling an integrated scheduling executor to perform traffic scheduling and resource scheduling on the target cluster.

[0007] In one implementation of this application, multi-dimensional status data of the cluster to be scheduled is continuously collected and encrypted before being transmitted to a central node to obtain a global status view. Specifically, this includes: deploying a collection agent in the cluster to be scheduled and continuously collecting resource and performance data from the cluster at a preset period; wherein the resource data includes CPU and / or memory and / or GPU request volume, availability, and Pod running status; performance data includes inter-cluster network latency, bandwidth, and packet loss rate; obtaining cost data from the cluster to be scheduled in real time by calling the cloud vendor's application programming interface; wherein the cost data includes on-demand pricing, spot pricing, and discount information for instance types; collecting the geographical location information, vendor information, compliance tags, and historical instance outage data of the cluster to be scheduled to obtain metadata; transmitting the collected resource data, performance data, cost data, and metadata to the central node via an encryption protocol and preprocessing them to obtain standard multi-dimensional status data; and associating the standard multi-dimensional status data to construct a global status view; wherein the global status view reflects the resource, cost, performance, and metadata status of each cluster.

[0008] In one implementation of this application, if the multidimensional state data meets a preset triggering condition, the business strategy associated with the global state view is parsed to obtain structured constraints and weight configurations. Specifically, this includes: real-time monitoring of changes in the multidimensional state data, comparing the state differences before and after the changes to determine whether the preset triggering condition is met; if the multidimensional state data meets the preset triggering condition, a triggering instruction is received, and a business scenario related to the triggering instruction is associated; the business strategy corresponding to the business scenario is invoked, and the business strategy is parsed to obtain structured constraints; wherein, the structured constraints include regional requirements, compliance standards, and resource adaptation conditions; the optimization target configuration in the business strategy is extracted, and the weight allocation rules in the optimization target configuration are extracted to determine the proportion of the optimization target in the business strategy.

[0009] In one implementation of this application, clusters contained in the global state view are eliminated based on structured constraints to obtain a candidate cluster list. Specifically, this includes: comparing the state information of each cluster in the global state view with the structured constraints to eliminate clusters in the global state view that do not meet the structured constraints; and summarizing the remaining clusters after filtering to obtain a candidate cluster list.

[0010] In one implementation of this application, calculating the cost factor, performance factor, utilization factor, and stability factor of each candidate cluster in the candidate cluster list specifically includes: obtaining the identification information of each candidate cluster in the candidate cluster list, and extracting the cost data, performance data, resource data, and metadata of each candidate cluster from the global status view based on the identification information; using the average price of all clusters in the candidate cluster list as the benchmark cost, and dividing the benchmark cost by the cost data in each candidate cluster to obtain the cost factor; obtaining the lowest performance index value in the candidate cluster list, and calculating the performance data in each candidate cluster with the lowest performance index value to obtain the performance factor; calculating the resource data of each candidate cluster with a preset resource target utilization rate to obtain the utilization factor; and extracting instance interruption history data from the metadata of each candidate cluster to obtain the stability factor.

[0011] In one implementation of this application, a weighted calculation is performed with the weight configuration to obtain a comprehensive score for each candidate cluster. Specifically, this includes: retrieving the weight configuration and weighting it with cost factors, performance factors, utilization factors, and stability factors to obtain a cost factor weighted score, a performance factor weighted score, a utilization factor weighted score, and a stability factor weighted score; and summing the cost factor weighted score, performance factor weighted score, utilization factor weighted score, and stability factor weighted score to obtain a comprehensive score for each candidate cluster.

[0012] In one implementation of this application, the cluster with the highest comprehensive score is extracted as the target cluster, and an integrated scheduling executor is invoked to perform traffic scheduling and resource scheduling on the target cluster. Specifically, this includes: sorting the comprehensive scores in descending order and selecting the cluster with the highest comprehensive score as the target cluster; invoking the integrated scheduling executor and performing a pre-check on the target cluster to verify whether the resource availability, network connectivity, and compliance status of the target cluster meet the preset scheduling requirements; sending resource deployment instructions to the target cluster that meets the preset scheduling requirements and continuously monitoring the operating status of the target cluster to obtain the resource scheduling results; and generating traffic routing rules corresponding to the target cluster based on the traffic management component to complete the traffic routing configuration.

[0013] In one implementation of this application, after traffic scheduling and resource scheduling of the target cluster, the method further includes: collecting the actual operating indicators of the workload in the target cluster, and comparing the actual operating indicators with the comprehensive score to obtain the indicator deviation rate; if the indicator deviation rate is greater than the preset deviation threshold, adjusting the weight coefficient in the weight configuration to obtain the optimal scheduling strategy.

[0014] Secondly, embodiments of this application also provide a multi-cluster scheduling device for hybrid clouds. The device includes: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed, enable the at least one processor to: continuously collect multi-dimensional state data of the clusters to be scheduled and encrypt and transmit the multi-dimensional state data to a central node to obtain a global state view; if the multi-dimensional state data meets preset trigger conditions, parse the business policies associated with the global state view to obtain structured constraints and weight configurations; based on the structured constraints, eliminate clusters included in the global state view to obtain a candidate cluster list; calculate the cost factor, performance factor, utilization factor, and stability factor of each candidate cluster in the candidate cluster list, and perform a weighted calculation with the weight configuration to obtain a comprehensive score for each candidate cluster; extract the cluster with the highest comprehensive score as the target cluster, and call an integrated scheduling executor to perform traffic scheduling and resource scheduling on the target cluster.

[0015] Thirdly, this application also provides a non-volatile computer storage medium for multi-cluster scheduling in hybrid clouds, storing computer-executable instructions. These instructions are configured to: continuously collect multi-dimensional state data of the clusters to be scheduled, and encrypt and transmit the multi-dimensional state data to a central node to obtain a global state view; if the multi-dimensional state data meets preset trigger conditions, parse the business policies associated with the global state view to obtain structured constraints and weight configurations; based on the structured constraints, eliminate clusters included in the global state view to obtain a candidate cluster list; calculate the cost factor, performance factor, utilization factor, and stability factor of each candidate cluster in the candidate cluster list, and perform a weighted calculation with the weight configuration to obtain a comprehensive score for each candidate cluster; extract the cluster with the highest comprehensive score as the target cluster, and call an integrated scheduling executor to perform traffic scheduling and resource scheduling on the target cluster.

[0016] This application provides a multi-cluster scheduling method, device, and medium for hybrid clouds, which has the following beneficial effects: By continuously collecting multi-dimensional status data such as resources, costs, performance, and metadata, global optimal decision-making is achieved; business strategies are parsed into structured constraints and weight configurations, and quantitative calculations are performed through a multi-factor weighted scoring model, so that under the premise of meeting hard constraints, costs and performance are accurately balanced to find the comprehensive optimal solution; traffic scheduling and resource scheduling are completed synchronously through an integrated scheduling executor, constructing a closed-loop management process of status awareness, strategy parsing, screening and scoring, and scheduling execution, avoiding service instability caused by asynchronous traffic and resource scheduling. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart of a multi-cluster scheduling method for hybrid cloud provided in this application embodiment; Figure 2 This is a schematic diagram of the internal structure of a multi-cluster scheduling device for hybrid cloud provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] This application provides a multi-cluster scheduling method, device, and medium for hybrid clouds to solve the following technical problem: how to use a state-aware module and a multi-factor decision engine to achieve automated scheduling of workloads and traffic across multiple Kubernetes clusters with optimal cost, performance, and compliance controllability, thereby significantly improving resource utilization efficiency and system operation and maintenance efficiency.

[0020] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0021] Figure 1 This document provides a flowchart of a multi-cluster scheduling method for hybrid clouds, as illustrated in an embodiment of this application. Figure 1 As shown in the figure, the multi-cluster scheduling method for hybrid clouds provided in this application embodiment specifically includes the following steps: Step 10: Continuously collect multi-dimensional status data of the cluster to be scheduled, and encrypt and transmit the multi-dimensional status data to the central node to obtain a global status view.

[0022] As an optional embodiment, multi-dimensional status data of the cluster to be scheduled is continuously collected and the multi-dimensional status data is encrypted and transmitted to the central node to obtain a global status view. Specifically, it may include: Step 101: Deploy a collection agent in the cluster to be scheduled and continuously collect resource data and performance data in the cluster to be scheduled according to a preset period.

[0023] In this step, for resource data collection, the collection agent interacts with the Kubernetes API Server to obtain the core resource usage and allocation at the cluster node level, including the requested amount and actual available amount of computing resources (such as CPU and GPU) and storage resources (such as memory) of the nodes. At the same time, it synchronously collects the real-time running status of Pods in the cluster to ensure accurate understanding of the current resource load and task deployment status of the cluster. In terms of performance data collection, the collection agent deployed in each cluster adopts a lightweight design to avoid interfering with the cluster's own running performance. Based on specific network probing technology, the agent periodically measures the network transmission performance indicators between clusters, including key performance parameters such as network latency, data transmission bandwidth, and packet loss rate between clusters, thereby accurately reflecting the quality of network communication between clusters.

[0024] Step 102: Obtain cost data from the cluster to be scheduled in real time by calling the cloud vendor's application programming interface.

[0025] In this step, cost data collection relies on standardized application programming interfaces (APIs) provided by cloud vendors to build a real-time data collection channel. This enables dynamic capture of cloud resource cost information for each cluster to be scheduled. Based on the interface specifications and authentication mechanisms of different cloud vendors, targeted data requests are initiated. The acquired cost data covers fee information under various pricing models corresponding to different instance types and regions of each cluster, including regular on-demand instance prices, elastic Spot instance prices, and various limited-time discounts or long-term contract offers. This ensures coverage of the core cost components that may be generated during cluster operation. Simultaneously, when API calls fail due to network fluctuations, cloud vendor interface maintenance, or other reasons, the system automatically switches to backup data calculation logic. Based on the average cost data collected historically and combined with a reasonable fluctuation coefficient, a temporary cost reference value is generated to avoid impacting the overall scheduling decision-making process due to data acquisition interruptions, ensuring the availability and stability of cost data.

[0026] Step 103: Collect the geographical location information, vendor information, compliance tags, and instance outage history data of the cluster to be scheduled in order to obtain the metadata of the cluster to be scheduled.

[0027] In this step, for cluster geographic location information, the actual physical area distribution of each cluster's deployment is recorded, clarifying its geographical affiliation; for vendor information, the cloud vendor identifier corresponding to each cluster is accurately collected, adapting to the resource characteristics and interface specifications of different vendors to ensure vendor compatibility with cost data collection, resource scheduling execution, and other stages; regarding compliance tag collection, corresponding compliance attribute tags are configured for each cluster according to business scenario requirements and industry compliance standards. These tags cover multiple dimensions such as data compliance and industry compliance, directly reflecting whether the cluster meets the compliance deployment requirements of specific businesses, supporting subsequent rapid screening of qualified clusters based on compliance constraints; and the collection of historical data on instance interruptions focuses on elastic instances within the cluster. Historical operational stability (such as Spot instances) is recorded, including key information such as the frequency and duration of instance outages in recent periods, forming derived indicators such as instance outage rate. This provides data support for assessing cluster operational stability and reducing the risk of task interruption after scheduling. During metadata maintenance, on the one hand, cluster attribute changes, such as adjustments to vendor affiliation and updates to compliance levels, can be synchronized in real time through automated mechanisms to ensure the timeliness of metadata. On the other hand, manual intervention is allowed to supplement or correct key information, such as manual labeling of special compliance tags, balancing automation efficiency with accuracy in special scenarios. Ultimately, these collected geographical locations, vendor affiliations, compliance tags, and historical instance outage data will be integrated to form structured cluster metadata.

[0028] Step 104: Transmit the collected resource data, performance data, cost data, and metadata to the central node via an encryption protocol and preprocess them to obtain standard multidimensional status data.

[0029] In this step, the collected resource data, performance data, cost data, and metadata are uniformly aggregated and then transmitted to the central node through a specified encrypted communication protocol. This encryption protocol has low latency characteristics, can adapt to the real-time transmission requirements of multi-dimensional data in large-scale clusters, ensures the transmission efficiency of data from the edge collection end to the central node, and meets the timeliness requirements of subsequent scheduling decisions. After various types of data arrive at the central node, the raw data is transformed into standard multi-dimensional state data. First, data cleaning is performed to handle outliers (such as instantaneous fluctuation values ​​in resource data, invalid probe results in performance data) and missing values ​​(such as cost data of individual clusters not being obtained in time at a certain moment) that may occur during the collection process. Outliers are removed through reasonable algorithms, and missing values ​​are filled in based on historical data patterns or data characteristics of similar clusters to ensure the accuracy and completeness of the data. Then, data standardization is performed to map various types of data to the same data range or format, eliminate the impact of differences in data dimensions, and enable resources, performance, cost, and metadata to be used by subsequent stages within the same evaluation framework.

[0030] Step 105: Associate the standard multidimensional state data to build a global state view.

[0031] In this step, the resource data, performance data, cost data, and metadata of each cluster are first cross-dimensionally correlated. For example, resource data such as CPU availability and memory request volume of a cluster are bound to performance data such as network latency and bandwidth. At the same time, cost data such as real-time instance prices and discount information, as well as metadata such as geographical location, compliance tags, and instance outage history, are also linked to ensure that each cluster record contains complete multi-dimensional attribute information and avoids data fragmentation. During the correlation process, logical mapping relationships between data are established. For example, the "compliance tag" in the metadata is linked to the "node availability" in the resource data to clarify the actual resource carrying capacity of compliant clusters. The "instance type price" in the cost data is linked to the "network latency" in the performance data to intuitively present the cost differences of clusters with different performance levels. At the same time, the correlated data is dynamically updated in real time. When any dimension of data changes, the global status view will be updated synchronously to ensure that the cluster status in the view is consistent with the actual operation and to avoid scheduling decision deviations due to data lag.

[0032] Step 20: If the multidimensional state data meets the preset triggering conditions, then parse the business strategy associated with the global state view to obtain structured constraints and weight configurations.

[0033] As an optional embodiment, if the multidimensional state data meets the preset triggering conditions, the business strategy associated with the global state view is parsed to obtain structured constraints and weight configurations. Specifically, this may include: Step 201: Real-time monitoring of changes in multidimensional state data, comparing the state differences before and after the changes in multidimensional state data, to determine whether the preset triggering conditions are met.

[0034] In this step, relying on the global status view linkage, the dynamic changes of resources, performance, cost and metadata are tracked. Instead of viewing changes in a single dimension in isolation, the multi-dimensional coordinated fluctuations are analyzed in relation to each other to fully perceive the cluster status. After capturing changes, the differences between the states before and after are compared, and the changes in numerical values ​​(such as resource quantity, cost, and latency fluctuations) and attribute changes (such as compliance tags and interruption history adjustments) are quantified. Then, the differences are matched and verified with preset trigger conditions to determine whether the trigger threshold is reached or a specific scenario is met. For example, when the change in cluster resource utilization exceeds the set range, cost data fluctuates significantly, or a new cluster that meets a specific compliance tag is added, it will be determined that the trigger condition is met.

[0035] Step 202: If the multidimensional state data meets the preset triggering conditions, then receive the triggering instruction and associate it with the business scenario related to the triggering instruction.

[0036] In this step, once the multidimensional state data meets the preset trigger conditions, the system will immediately receive the trigger command generated by the state change. This command carries the core identification information of the trigger scenario, including the trigger source (such as resource fluctuations in a cluster, cost changes, etc.) and the associated basic data dimensions. Based on the identification information in the trigger command, the system retrieves the globally configured business scenario mapping rules. These rules pre-establish the correspondence between different trigger types and business scenarios. For example, trigger commands related to resource utilization will be associated with resource-sensitive business scenarios; trigger commands for cost data fluctuations will be associated with cost-priority business scenarios. At the same time, the system synchronously matches the preset basic parameters under this business scenario, such as business type and service level requirements, to ensure that subsequent strategy parsing can accurately match the scenario requirements.

[0037] Step 203: Invoke the business strategy corresponding to the business scenario and parse the business strategy to obtain structured constraints.

[0038] In this step, once a specific business scenario is associated with it, the system retrieves the corresponding preset business strategy based on the scenario identifier. These business strategies are predefined through declarative APIs or graphical templates, including pre-built templates adapted to general scenarios and custom strategies based on business characteristics, ensuring a precise match with scenario requirements. During the strategy parsing phase, the system first extracts the core content of the hard constraints in the strategy. These constraints clarify the bottom-line conditions that scheduling must meet, involving key dimensions such as the cluster's geographical affiliation, compliance qualifications, and resource type, which serve as the basic criteria for subsequent cluster selection. At the same time, the extracted constraint information is standardized, transforming the configuration content or description information in the strategy into a structured data format that can be directly recognized and executed by the machine. This clearly defines the exclusion rules and mandatory requirements for cluster selection, providing accurate and implementable judgment criteria for subsequent selection of candidate clusters from the global cluster pool.

[0039] Step 204: Extract the optimization target configuration from the business strategy, and extract the weight allocation rules from the optimization target configuration to determine the proportion of the optimization target in the business strategy.

[0040] In this step, after completing the business strategy analysis, the optimization target configuration contained in the strategy is further extracted. This configuration focuses on the core optimization direction of the business in scheduling, covering optimization requirements in key dimensions such as cost, performance, and resource utilization, and clarifies the target directions that should be prioritized in scheduling decisions. Subsequently, for the extracted optimization target configuration, the preset weight allocation rules are analyzed. These rules, through structured parameter definitions, clarify the relative importance of different optimization targets in the overall decision. Based on the parameters in the rules, the weights of each optimization target are quantified and standardized to ensure that the sum of the weights of all optimization targets conforms to the preset logic. Finally, the proportion of each optimization target in the business strategy is clearly determined, providing the weight basis for each target dimension when the multi-factor decision engine calculates the cluster comprehensive score.

[0041] Step 30: Based on structured constraints, eliminate clusters contained in the global state view to obtain a candidate cluster list.

[0042] As an optional embodiment, based on structured constraints, clusters contained in the global state view are eliminated to obtain a candidate cluster list. Specifically, this may include: Step 301: Compare the state information of each cluster in the global state view with the structured constraints to eliminate clusters in the global state view that do not meet the structured constraints.

[0043] In this step, based on the global status view, complete status information for each cluster is extracted, including core dimensions such as resource capacity, geographical location, compliance attributes, and vendor affiliation. This data is then compared and verified against the parsed and generated structured constraints one by one. During the comparison, each cluster is checked against all hard standards according to the minimum requirements of the constraints. For example, it is verified whether the cluster's region is within the constraint limit, whether the compliance label is consistent with the constraint requirements, and whether the currently available resources have reached the minimum threshold specified by the constraints. Clusters that are confirmed not to meet any structured constraint are removed from the candidate range of the global status view, and only clusters that meet the constraint requirements in all dimensions are retained, ultimately forming a candidate cluster list. This provides cluster samples that meet the basic business requirements for subsequent multi-factor scoring and optimal decision-making.

[0044] Step 302: Summarize the remaining clusters after filtering to obtain a list of candidate clusters.

[0045] In this step, clusters that have been verified to meet all hard constraints are uniformly aggregated. During the aggregation process, the unique cluster identifier is used as an index to associate and extract the core status information of each qualified cluster in the global status view, including key dimension data such as resources, performance, cost, and metadata, to ensure the integrity and accuracy of information for each retained cluster. At the same time, the aggregated cluster information is structured and organized, and the cluster identifier, core status parameters, and other contents are standardized and arranged according to the preset data format to avoid information fragmentation or inconsistent formats. Finally, through the above aggregation and organization process, a candidate cluster list containing all clusters that meet the constraints is formed. This list will serve as the direct data source for subsequent multi-factor scoring and optimal cluster decision-making, laying the foundation for accurately calculating the comprehensive score of each cluster.

[0046] Step 40: Calculate the cost factor, performance factor, utilization factor, and stability factor of each candidate cluster in the candidate cluster list, and perform a weighted calculation with the weight configuration to obtain the comprehensive score of each candidate cluster.

[0047] As an optional embodiment, the cost factor, performance factor, utilization factor and stability factor of each candidate cluster in the candidate cluster list are calculated. Specifically, this may include: Step 401: Obtain the identification information of each candidate cluster in the candidate cluster list, and extract the cost data, performance data, resource data and metadata of each candidate cluster from the global status view based on the identification information.

[0048] In this step, the candidate cluster list is first traversed, and the unique identifier of each candidate cluster is extracted one by one. This identifier serves as the core index for associating with the global status view data, ensuring that the complete status record of the corresponding cluster can be accurately located. Subsequently, based on the cluster identifier, multi-dimensional data of each candidate cluster is extracted from the global status view. On the one hand, cost data (including instance pricing, discount information, etc.) and performance data (including network latency, bandwidth, packet loss rate, etc.) are extracted. On the other hand, resource data (such as node resource request volume, availability, and Pod running status) and metadata (including geographical location, compliance tags, instance interruption history, etc.) are extracted simultaneously. The entire extraction process is automatically completed based on the structured data association mechanism, ensuring that the multi-dimensional data of each candidate cluster completely matches its identifier, avoiding data mismatch or missing data.

[0049] Step 402: Use the average price of all clusters in the candidate cluster list as the baseline cost, and divide the baseline cost by the cost data in each candidate cluster to obtain the cost factor.

[0050] In this step, when calculating the cost factor, the cost data of all clusters in the candidate cluster list are first summarized and averaged. The resulting average price is determined as the benchmark cost. This benchmark cost reflects the overall cost level of clusters within the candidate range, providing a reference standard for subsequent comparisons of the cost advantages and disadvantages of individual clusters. Subsequently, using the real-time cost data of each candidate cluster as the calculation object, the pre-determined benchmark cost is divided by the cost data of each cluster. The result obtained through this calculation is the cost factor of the corresponding candidate cluster. The magnitude of the cost factor can intuitively reflect the degree of advantage of the cluster's cost relative to the average cost within the candidate range, providing a quantitative basis for the cost dimension evaluation in subsequent multi-factor weighted scoring.

[0051] Step 403: Obtain the lowest performance index value from the candidate cluster list, and calculate the performance factor by combining the performance data of each candidate cluster with the lowest performance index value.

[0052] In this step, when calculating the performance factor, the performance data of all clusters in the candidate cluster list are first traversed, and the performance index value with the smallest value is selected and determined as the minimum performance index value. This value serves as the optimal benchmark for the performance dimension, used to measure the performance gap between the clusters. Subsequently, based on the actual performance data of each candidate cluster, the difference between the cluster's performance data and the minimum performance index value is calculated. Then, this difference is divided by the minimum performance index value to obtain the performance deviation ratio. Subtracting this deviation ratio from 1 yields the final result, which is the performance factor of the corresponding candidate cluster. The magnitude of the performance factor directly reflects the degree to which the cluster's performance is close to the optimal benchmark, providing quantitative support for the evaluation of the performance dimension in subsequent multi-factor weighted scoring.

[0053] Step 404: Calculate the resource data in each candidate cluster with the preset resource target utilization rate to obtain the utilization factor.

[0054] In this step, when calculating the utilization factor, a preset resource target utilization rate is first obtained. This target value is a benchmark parameter set based on the balance between efficient resource utilization and stable business operation. Then, resource data for each candidate cluster is extracted, with a focus on indicators related to the current actual resource utilization rate. Next, the utilization factor for each candidate cluster is calculated by first finding the absolute value of the difference between its current actual resource utilization rate and the preset resource target utilization rate, and then subtracting this absolute value from 1. The result is the utilization factor for that candidate cluster. The magnitude of the utilization factor directly reflects the degree of closeness between the cluster's current resource utilization rate and the target utilization rate, providing a quantitative basis for the evaluation of the resource utilization efficiency dimension in the subsequent multi-factor weighted scoring.

[0055] Step 405: Extract instance interruption history data from the metadata of each candidate cluster to obtain the stability factor.

[0056] In this step, when calculating the stability factor, historical data related to instance outages is first extracted from the metadata of each candidate cluster. This data records the outage situation of elastic instances within the cluster over a period of time and is the core basis for evaluating the stability of cluster operation. Subsequently, based on the extracted historical data of instance outages, the instance outage rate of the cluster in the corresponding period is calculated. Subtracting this outage rate from 1 yields the stability factor of the candidate cluster. The magnitude of the stability factor directly reflects the stability of the cluster instance operation, especially for scenarios that rely on elastic instances, providing quantitative support for the evaluation of the stability dimension in the subsequent multi-factor weighted scoring.

[0057] Step 406: Retrieve the weight configuration and weight it with the cost factor, performance factor, utilization factor, and stability factor to obtain the weighted score of the cost factor, the weighted score of the performance factor, the weighted score of the utilization factor, and the weighted score of the stability factor.

[0058] In this step, the preset weight configuration is first retrieved from the parsed business strategy. This configuration clarifies the relative importance of the four dimensions—cost, performance, utilization, and stability—in the scheduling decision, and the weight allocation of each dimension aligns with the business optimization goals. Subsequently, the retrieved weights of each dimension are multiplied by the factors of the corresponding candidate clusters to obtain the weighted scores of the utilization factor and the stability factor. Through this weighted calculation process, each factor is transformed into a quantitative score that fits the priority of the business strategy, laying the foundation for the subsequent summary calculation of the cluster's comprehensive score.

[0059] Step 407: Sum the weighted scores of cost factor, performance factor, utilization factor, and stability factor to obtain the comprehensive score of each candidate cluster.

[0060] In this step, a comprehensive score is calculated for each candidate cluster. The weighted scores of cost factor, performance factor, utilization factor, and stability factor for each candidate cluster are uniformly collected and integrated into a single quantitative indicator, namely the comprehensive score of the candidate cluster, through summation. This comprehensively integrates the weight preferences in the business strategy with the multi-dimensional characteristics of the cluster itself, objectively reflecting the comprehensive adaptability of each candidate cluster in terms of cost optimization, performance, resource utilization efficiency, and operational stability, providing a direct and core decision-making basis for the subsequent selection of the optimal scheduling cluster.

[0061] Step 50: Extract the cluster with the highest comprehensive score as the target cluster, and call the integrated scheduler to perform traffic scheduling and resource scheduling on the target cluster.

[0062] As an optional embodiment, the cluster with the highest comprehensive score is extracted as the target cluster, and the integrated scheduling executor is invoked to perform traffic scheduling and resource scheduling on the target cluster. Specifically, it may include: Step 501: Sort the comprehensive scores in descending order and select the cluster with the highest comprehensive score as the target cluster.

[0063] In this step, all candidate clusters are sorted in descending order of their comprehensive scores to form a clear priority sequence. The sorting process strictly compares the comprehensive scores of each cluster to ensure the accuracy and fairness of the sorting results and avoid sorting biases caused by differences in dimension weights or factor calculations. After sorting, the cluster with the highest comprehensive score at the top of the sequence will be determined as the target cluster. The comprehensive score of this target cluster fully reflects its optimal suitability in multiple dimensions such as cost optimization, performance, resource utilization efficiency, and operational stability. It perfectly matches the optimization goals and weight preferences preset by the business strategy and is the optimal decision result for intelligent scheduling of multiple Kubernetes clusters in a hybrid cloud environment, providing a clear target for the execution of subsequent scheduling instructions.

[0064] Step 502: Invoke the integrated scheduler and perform a pre-check on the target to verify whether the resource availability, network connectivity and compliance status of the target cluster meet the preset scheduling requirements.

[0065] In this step, after identifying the target cluster, a pre-check process is initiated to ensure that the target cluster has a reliable foundation for scheduling execution. The pre-check focuses on three core dimensions: First, it verifies the resource availability status of the target cluster to confirm whether its current remaining resources can meet the resource requirements of the scheduling task, avoiding scheduling failure due to insufficient resources. Second, it verifies the network connectivity of the cluster, checking whether the network communication between the central node and the target cluster, and between the target cluster and related business components, is smooth, ensuring that the transmission of scheduling instructions and subsequent business data interaction are not affected. Finally, it verifies the compliance status of the cluster, reconfirming whether its compliance labels, regional attributes, etc., still meet the constraints of the business strategy, eliminating compliance risks due to status changes. The entire pre-check process is completed automatically by the executor, quickly providing feedback on the verification results, and providing a compliant, available, and connected environment guarantee for the final execution of scheduling instructions.

[0066] Step 503: Send resource deployment instructions to the target cluster that meets the preset scheduling requirements, and continuously monitor the running status of the target cluster to obtain the resource scheduling results.

[0067] In this step, after the target cluster passes the pre-check, a standardized resource deployment instruction is sent to it. The instruction includes the resource configuration, deployment specifications, and related parameters required by the business, ensuring that the resource deployment meets the needs of the business scenario. Relying on the integrated scheduling executor, the running status of the target cluster is continuously monitored, and key dimensions such as resource allocation progress, service startup status, network connection stability, and compliance attribute maintenance are tracked in real time. During the monitoring process, various status feedbacks during the deployment process are dynamically captured, including whether resources are successfully allocated, whether services are running normally, and whether any abnormal alarms occur. These feedback information are integrated into a complete resource scheduling result, which not only clarifies the execution effectiveness of the scheduling task, but also provides data support for possible subsequent scheduling adjustments or optimizations.

[0068] Step 504: Based on the traffic management component, generate traffic routing rules corresponding to the target cluster to complete the traffic routing configuration.

[0069] In this step, the traffic management component is invoked to generate exclusive traffic routing rules based on the target cluster's identification information, network configuration, and business access requirements. These rules specify the forwarding path, distribution method, and associated adaptation parameters of the business traffic, ensuring that traffic can be accurately directed to the target cluster. During the generation process, the component automatically adapts to the target cluster's network environment and business scenario characteristics to avoid routing conflicts or access bottlenecks. After the rules are generated, the traffic management component synchronizes them to the global routing configuration system, completing the deployment and activation of the routing rules. This enables the smooth diversion of business traffic to the target cluster, ensuring the continuity and stability of business access after scheduling.

[0070] Step 505: Collect the actual operating metrics of the workload in the target cluster and compare the actual operating metrics with the comprehensive score to obtain the metric deviation rate.

[0071] In this step, the monitoring component continuously collects actual operating metrics of the workload in the target cluster, covering core dimensions such as resource utilization, performance, and operational stability, ensuring the comprehensiveness and real-time nature of the metric collection. Subsequently, the collected actual operating metrics are compared one by one with the expected metrics corresponding to the comprehensive score calculated before scheduling, quantifying the degree of difference between the two. Through a preset calculation logic, the difference between the actual metric and the expected metric is divided by the expected metric, and the result is the metric deviation rate. This deviation rate directly reflects the degree of fit between the actual operating status of the target cluster workload and the scheduling expectations, providing key data references for the subsequent optimization and adjustment of scheduling strategies.

[0072] Step 506: If the index deviation rate is greater than the preset deviation threshold, adjust the weight coefficients in the weight configuration to obtain the optimal scheduling strategy.

[0073] In this step, when the detected deviation rate exceeds the preset deviation threshold, it indicates that the current scheduling strategy does not match the actual operating state of the target cluster as expected. The weight configuration optimization process is then initiated. Based on the specific performance of the deviation rate, the core source of the deviation is identified in the corresponding dimension. Subsequently, based on the deviation analysis results, the weight coefficients of each dimension in the weight configuration are dynamically adjusted. The weight proportion of the dimension causing the deviation is appropriately adjusted, while also considering the balance requirements of other dimensions to avoid new imbalances caused by optimization of a single dimension. During the adjustment process, the adjusted weight configuration is iteratively verified until the deviation rate falls back to the threshold range. Ultimately, the optimal scheduling strategy that adapts to the current business scenario and the actual state of the cluster is formed, continuously improving the accuracy and effectiveness of scheduling decisions.

[0074] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a multi-cluster scheduling device for hybrid clouds, the structure of which is as follows: Figure 2 As shown.

[0075] Figure 2 This is a schematic diagram of the internal structure of a multi-cluster scheduling device for hybrid clouds, provided as an embodiment of this application. Figure 2 As shown, the device includes: At least one processor 201; And a memory 202 that is communicatively connected to at least one processor; The memory 202 stores instructions executable by at least one processor. These instructions are executed by at least one processor 201, enabling the processor 201 to: continuously collect multi-dimensional state data of the clusters to be scheduled and encrypt and transmit the multi-dimensional state data to the central node to obtain a global state view; if the multi-dimensional state data meets preset trigger conditions, parse the business policies associated with the global state view to obtain structured constraints and weight configurations; based on the structured constraints, eliminate clusters included in the global state view to obtain a candidate cluster list; calculate the cost factor, performance factor, utilization factor, and stability factor of each candidate cluster in the candidate cluster list and perform a weighted calculation with the weight configuration to obtain a comprehensive score for each candidate cluster; extract the cluster with the highest comprehensive score as the target cluster and call the integrated scheduling executor to perform traffic scheduling and resource scheduling on the target cluster.

[0076] Some embodiments of this application provide corresponding to Figure 1A non-volatile computer storage medium for multi-cluster scheduling in hybrid clouds stores computer-executable instructions. These instructions are configured to: continuously collect multi-dimensional state data of the clusters to be scheduled and encrypt and transmit this data to a central node to obtain a global state view; if the multi-dimensional state data meets preset trigger conditions, parse the business policies associated with the global state view to obtain structured constraints and weight configurations; based on the structured constraints, eliminate clusters included in the global state view to obtain a candidate cluster list; calculate the cost factor, performance factor, utilization factor, and stability factor of each candidate cluster in the candidate cluster list and perform a weighted calculation with the weight configuration to obtain a comprehensive score for each candidate cluster; extract the cluster with the highest comprehensive score as the target cluster and call an integrated scheduling executor to perform traffic and resource scheduling on the target cluster.

[0077] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for IoT devices and media are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0078] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0079] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0080] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0081] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0082] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0083] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0084] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0085] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0086] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0087] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A multi-cluster scheduling method for hybrid clouds, characterized in that, The method includes: The system continuously collects multidimensional status data of the cluster to be scheduled and encrypts and transmits the multidimensional status data to the central node to obtain a global status view; wherein, the multidimensional status data includes resource data, cost data, performance data and metadata; If the multidimensional state data meets the preset triggering conditions, the business strategy associated with the global state view is parsed to obtain structured constraints and weight configurations. Based on the structured constraints, clusters included in the global state view are eliminated to obtain a candidate cluster list. The cost factor, performance factor, utilization factor, and stability factor of each candidate cluster in the candidate cluster list are calculated and weighted with the weight configuration to obtain a comprehensive score for each candidate cluster. The cluster with the highest overall score is selected as the target cluster, and the integrated scheduler is invoked to perform traffic scheduling and resource scheduling on the target cluster.

2. The multi-cluster scheduling method for hybrid cloud as described in claim 1, characterized in that, Continuously collect multi-dimensional status data of the cluster to be scheduled, and encrypt and transmit the multi-dimensional status data to the central node to obtain a global status view, specifically including: A data collection agent is deployed in the cluster to be scheduled, and resource data and performance data in the cluster to be scheduled are continuously collected at a preset period. The resource data includes CPU and / or memory and / or GPU request volume, availability, and Pod running status. The performance data includes inter-cluster network latency, bandwidth, and packet loss rate. By calling the cloud provider's application programming interface (API), cost data of the cluster to be scheduled can be obtained in real time; wherein, the cost data includes on-demand pricing, spot pricing and discount information for instance types; Collect the geographical location information, vendor information, compliance tags, and instance outage history data of the cluster to be scheduled in order to obtain the metadata of the cluster to be scheduled. The collected resource data, performance data, cost data, and metadata are transmitted to the central node via an encryption protocol and preprocessed to obtain standard multidimensional status data. The standard multidimensional state data are correlated to construct a global state view; wherein the global state view is used to reflect the resource, cost, performance and metadata status of each cluster.

3. The multi-cluster scheduling method for hybrid cloud as described in claim 1, characterized in that, If the multidimensional state data meets the preset triggering conditions, the business strategy associated with the global state view is parsed to obtain structured constraints and weight configurations, specifically including: The changes in the multidimensional state data are monitored in real time, and the state differences before and after the changes in the multidimensional state data are compared to determine whether the preset triggering conditions are met. If the multidimensional state data meets the preset triggering conditions, a triggering instruction is received, and the business scenario related to the triggering instruction is associated. The business strategy corresponding to the business scenario is invoked, and the business strategy is parsed to obtain the structured constraints; wherein, the structured constraints include regional requirements, compliance standards, and resource adaptation conditions. Extract the optimization target configuration from the business strategy, and extract the weight allocation rules from the optimization target configuration to determine the proportion of the optimization target in the business strategy.

4. The multi-cluster scheduling method for hybrid cloud as described in claim 1, characterized in that, Based on the structured constraints, clusters included in the global state view are eliminated to obtain a candidate cluster list, specifically including: The state information of each cluster in the global state view is compared with the structured constraints to eliminate clusters in the global state view that do not meet the structured constraints. The selected and retained clusters are aggregated to obtain the candidate cluster list.

5. A multi-cluster scheduling method for hybrid cloud as described in claim 1, characterized in that, The calculation of the cost factor, performance factor, utilization factor, and stability factor for each candidate cluster in the candidate cluster list includes: Obtain the identification information of each candidate cluster in the candidate cluster list, and based on the identification information, extract the cost data, performance data, resource data and metadata of each candidate cluster from the global status view; The average price of all clusters in the candidate cluster list is used as the benchmark cost, and the benchmark cost is divided by the cost data in each candidate cluster to obtain the cost factor; Obtain the lowest performance index value from the candidate cluster list, and calculate the performance factor by combining the performance data of each candidate cluster with the lowest performance index value; The resource data in each candidate cluster is calculated with the preset resource target utilization rate to obtain the utilization rate factor; Extract instance interruption history data from the metadata of each candidate cluster to obtain the stability factor.

6. The multi-cluster scheduling method for hybrid cloud according to claim 1, characterized in that, The scores of each candidate cluster are obtained by weighting the scores with the weight configuration, specifically including: The weight configuration is retrieved and weighted with the cost factor, the performance factor, the utilization factor, and the stability factor to obtain a weighted score for the cost factor, a weighted score for the performance factor, a weighted score for the utilization factor, and a weighted score for the stability factor. The weighted scores of the cost factor, performance factor, utilization factor, and stability factor are summed to obtain the comprehensive score of each candidate cluster.

7. The multi-cluster scheduling method for hybrid cloud as described in claim 1, characterized in that, The cluster with the highest overall score is selected as the target cluster, and the integrated scheduler is invoked to perform traffic and resource scheduling on the target cluster, specifically including: The comprehensive scores are sorted in descending order, and the cluster with the highest comprehensive score is selected as the target cluster. The integrated scheduling executor is invoked, and the target is pre-checked to verify whether the resource availability, network connectivity, and compliance status of the target cluster meet the preset scheduling requirements. Send resource deployment instructions to the target cluster that meets the preset scheduling requirements, and continuously monitor the running status of the target cluster to obtain resource scheduling results; Based on the traffic management component, traffic routing rules corresponding to the target cluster are generated to complete the traffic routing configuration.

8. A multi-cluster scheduling method for hybrid cloud as described in claim 1, characterized in that, After performing traffic scheduling and resource scheduling on the target cluster, the method further includes: The actual operating metrics of the workload in the target cluster are collected, and the actual operating metrics are compared with the comprehensive score to obtain the metric deviation rate; If the deviation rate of the indicator is greater than the preset deviation threshold, the weight coefficient in the weight configuration is adjusted to obtain the optimal scheduling strategy.

9. A multi-cluster scheduling device for hybrid clouds, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform a method as described in any one of claims 1-8.

10. A non-volatile computer storage medium for multi-cluster scheduling in hybrid clouds, storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, they implement a method as described in any one of claims 1-8.

Images