Cloud platform container scheduling method and device, electronic equipment and storage medium

Abstract

The invention provides a cloud platform container scheduling method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining the state information of a physical cluster corresponding to a cloud platform, and constructing a digital twinborn body synchronized with the state of the physical cluster; for the to-be-loaded service to be loaded into the physical cluster, generating a target container scheduling strategy; determining a score of a target container scheduling strategy based on the state information of the digital twin; and determining the container scheduling strategy with the highest score in the target container scheduling strategies, and executing the container scheduling strategy with the highest score on the physical cluster. By adopting the technical scheme provided by the invention, the resource utilization rate is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a cloud platform container scheduling method, apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development of internet technology, more and more enterprises tend to store and manage information resources in the cloud in a digital and networked manner, and containerization technology has become the mainstream method for deploying cloud-native applications. Traditional container schedulers mainly make decisions based on static rules such as real-time resource availability and affinity / anti-affinity.

[0003] However, traditional container schedulers lack the ability to predict long-term cluster states. Furthermore, when resources are scarce, optimization methods are limited to post-event container merging and migration, which not only incurs additional system overhead but also fails to fundamentally prevent resource waste. Summary of the Invention

[0004] In view of this, embodiments of this application provide a cloud platform container scheduling method, apparatus, electronic device, and storage medium, which improves resource utilization.

[0005] This application mainly includes the following aspects: In a first aspect, embodiments of this application provide a cloud platform container scheduling method, the method comprising: Obtain the status information of the physical cluster corresponding to the cloud platform, and construct a digital twin that is synchronized with the status of the physical cluster; For the services to be loaded into the physical cluster, generate a target container scheduling policy; Based on the state information of the digital twin, a score for the target container scheduling strategy is determined; Identify the container scheduling policy with the highest score among the target container scheduling policies, and execute the container scheduling policy with the highest score on the physical cluster.

[0006] Furthermore, the step of generating a target container scheduling policy for the services to be loaded into the physical cluster includes: For each service in each container of the physical cluster, determine the multivariate heterogeneous vector of the service from the state information of the digital twin; The multivariate heterogeneous vectors of the service to be loaded and the multivariate heterogeneous vectors of the service are input into a pre-trained dynamic behavior prediction model to obtain the resource conflict probability between the service to be loaded and the service predicted by the dynamic behavior prediction model within a first preset time period. Based on the affinity, resource profile complementarity, and resource conflict probability between the service to be loaded and the service, the combined fitness score of the service to be loaded and the service is determined. For each container, the sum of the combined fitness scores of the service to be loaded and all services in that container is determined as the total combined fitness score of that container. Select the highest total merge fitness score from the total merge fitness scores of all containers; The strategy of incorporating the services to be loaded into containers with the highest total merge fitness score is determined as the first container scheduling strategy.

[0007] Furthermore, the step of generating a target container scheduling policy for the services to be loaded into the physical cluster includes: The strategy of placing the service to be loaded into the first new container is determined as the second container scheduling strategy.

[0008] Furthermore, the step of generating a target container scheduling policy for the services to be loaded into the physical cluster includes: Select services from all services in the physical cluster whose resource consumption percentage is lower than a preset percentage; The service with the highest affinity is selected from the affinity between the services to be loaded and services whose resource consumption ratio is lower than a preset ratio. The strategy of moving the services to be loaded and services whose resource consumption ratio corresponding to the maximum affinity is lower than the preset ratio to the second new container is determined as the third container scheduling strategy.

[0009] Furthermore, the step of generating a target container scheduling policy for the service to be loaded includes: Filter out services with an affinity greater than a preset affinity threshold from the affinity between the service to be loaded and all services, and identify services with an affinity greater than the preset affinity threshold as related services; For each associated service, the multivariate heterogeneous vector of the service to be loaded and the multivariate heterogeneous vector of the associated service are input into a pre-trained dynamic behavior prediction model to obtain the resource conflict probability between the service to be loaded and the associated service predicted by the dynamic behavior prediction model within a second preset time period. The service with the lowest probability of resource conflict is selected from the resource conflict probabilities between the service to be loaded and all related services. If the minimum resource conflict probability selected is less than the preset probability threshold, then the start execution time of the associated service with the minimum resource conflict probability is determined. The strategy of waiting for the start execution time for the service to be loaded is determined as the fourth container scheduling strategy.

[0010] Furthermore, determining the score of the target container scheduling strategy based on the state information of the digital twin includes: When executing the target container scheduling policy, identify the key services corresponding to the target container scheduling policy; Based on the status information of the key services corresponding to the target container scheduling strategy in the digital twin, the indicators corresponding to the target container scheduling strategy are determined. The score of the target container scheduling policy is determined based on the metrics corresponding to the target container scheduling policy.

[0011] Furthermore, determining the score of the target container scheduling policy based on the metrics corresponding to the target container scheduling policy includes: Determine the highest score among the scores of the first container scheduling policy, the second container scheduling policy, and the third container scheduling policy; The sum of the highest score and the index corresponding to the fourth container scheduling strategy is determined as the score of the fourth container scheduling strategy.

[0012] Secondly, embodiments of this application also provide a cloud platform container scheduling device, the device comprising: The acquisition module is used to acquire the status information of the physical cluster corresponding to the cloud platform and construct a digital twin that is synchronized with the status of the physical cluster. The generation module is used to generate target container scheduling strategies for the services to be loaded into the physical cluster. The scoring module is used to determine the score of the target container scheduling strategy based on the state information of the digital twin; The execution module is used to determine the container scheduling policy with the highest score among the target container scheduling policies, and to execute the container scheduling policy with the highest score on the physical cluster.

[0013] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory through the bus. The machine-readable instructions are executed by the processor to perform the steps of the cloud platform container scheduling method described in the first aspect or any possible implementation of the first aspect.

[0014] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the cloud platform container scheduling method described in the first aspect or any possible implementation of the first aspect.

[0015] This application provides a cloud platform container scheduling method, apparatus, electronic device, and storage medium. The method involves acquiring the status information of the physical cluster corresponding to the cloud platform and constructing a digital twin synchronized with the status of the physical cluster. For services to be loaded into the physical cluster, a target container scheduling strategy is generated. Based on the status information of the digital twin, a score for the target container scheduling strategy is determined. The highest-scoring container scheduling strategy among the target strategies is determined, and the highest-scoring container scheduling strategy is executed on the physical cluster.

[0016] This improves resource utilization.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This application provides a flowchart of one of the cloud platform container scheduling methods. Figure 2 This document shows a second flowchart of a cloud platform container scheduling method provided in an embodiment of this application. Figure 3 The third flowchart of a cloud platform container scheduling method provided in this application embodiment is shown; Figure 4 The fourth flowchart of a cloud platform container scheduling method provided in this application embodiment is shown; Figure 5 The fifth flowchart of a cloud platform container scheduling method provided in this application embodiment is shown; Figure 6 This paper shows a schematic diagram of the structure of a cloud platform container scheduling device provided in an embodiment of this application; Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0021] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] The methods, apparatus, electronic devices, or computer-readable storage media described in this application can be applied to any scenario requiring cloud platform container scheduling. This application does not limit specific application scenarios, and any scheme using the cloud platform container scheduling method and apparatus provided in this application is within the protection scope of this application.

[0023] It is worth noting that with the rapid development of internet technology, more and more enterprises tend to store and manage information resources in the cloud in a digital and networked manner, and containerization technology has become the mainstream method for deploying cloud-native applications. Traditional container schedulers mainly make decisions based on static rules such as real-time resource availability and affinity / anti-affinity. However, traditional container schedulers lack the ability to predict long-term cluster states. In addition, when resources are scarce, optimization methods are limited to post-event container merging and migration, which not only brings additional system overhead but also fails to fundamentally prevent resource waste.

[0024] To address the aforementioned issues, this application proposes a cloud platform container scheduling method, apparatus, electronic device, and storage medium, thereby improving resource utilization.

[0025] To facilitate understanding of this application, the technical solutions provided in this application will be described in detail below with reference to specific embodiments.

[0026] In this application embodiment, the following challenges exist in the existing containerized environment: 1. Low resource utilization: Because some services are only loaded when the container starts, a large number of containers run a single service at extremely high load for a long time. This mode not only causes serious waste of computing resources, but also causes cluster resource fragmentation problems. Existing solutions mostly adopt the strategy of "post-event merging", that is, creating new containers and migrating and integrating low-load services when resources are scarce. This post-event remedy is passive, and the migration operation itself will bring additional network, computing and storage overhead. 2. Temporal limitations of traditional scheduling mechanisms: Traditional container schedulers (such as the default scheduler of Kubernetes) rely on static rules to make decisions, mainly based on real-time resource reserves and affinity / anti-affinity and other state indicators. This mechanism has a fundamental defect: it lacks the ability to predict the future cluster state and cannot evaluate the impact of the current scheduling decision on long-term indicators such as resource fragmentation trend, cumulative energy consumption effect and service stability. 3. Lack of algorithm evaluation environment: In complex system environments, it is necessary to establish a parallel simulation verification platform to evaluate the effectiveness of different scheduling algorithms. However, the current container scheduling field generally lacks built-in decision-making simulation mechanisms and fails to integrate real-time simulation verification into the scheduling process, making it difficult to achieve truly optimal dynamic scheduling. To solve the above problems, it is necessary to build an intelligent scheduling framework. This framework should have proactive prediction capabilities, advance planning capabilities, and multi-dimensional comprehensive evaluation capabilities, thereby fundamentally improving resource utilization and eliminating cluster fragmentation problems.

[0027] Please see Figure 1 , Figure 1 This is one of the flowcharts for a cloud platform container scheduling method provided in an embodiment of this application.

[0028] like Figure 1 As shown in the figure, the cloud platform container scheduling method provided in this application embodiment includes the following steps: Step S101: Obtain the status information of the physical cluster corresponding to the cloud platform and construct a digital twin that is synchronized with the status of the physical cluster.

[0029] Here, the status information includes: real-time usage of node resources (CPU, memory, disk I / O, network bandwidth), node resource limits, configuration of running containers, list of services within containers, and service performance metrics (QoS). Multimodal data from the physical cluster is acquired to construct a simulation environment that is synchronous with the physical cluster in real time but computationally isolated—that is, a digital twin.

[0030] Step S102: Generate a target container scheduling policy for the services to be loaded into the physical cluster.

[0031] Here, the target container scheduling strategy includes: the first container scheduling strategy, the second container scheduling strategy, the third container scheduling strategy, and the fourth container scheduling strategy.

[0032] Here, upon receiving a scheduling request, multiple container scheduling strategies are generated to ensure optimal task scheduling. By comprehensively considering various resource configurations and operational requirements, the highest efficiency and best performance of task execution are achieved.

[0033] The following is combined Figure 2 Let's explain in detail how to generate the first container scheduling strategy.

[0034] Please see Figure 2 , Figure 2 This is a second flowchart of a cloud platform container scheduling method provided in an embodiment of this application.

[0035] like Figure 2 As shown, the first container scheduling policy is generated in the following manner: Step S11: For each service in each container of the physical cluster, determine the multivariate heterogeneous vector of the service from the state information of the digital twin.

[0036] Here, the multivariate heterogeneous vector is obtained by concatenating historical behavior feature vectors, profile feature vectors, and event vectors. The historical behavior feature vector is obtained by inputting time-series data of the service's resource usage (including CPU, memory, and IO curves) over a predetermined past period into a Long Short-Term Memory (LSTM) network or a Temporal Convolutional Network (TCN) for feature extraction. The profile feature vector is obtained by embedding discrete static attributes (including QoS levels and resource sensitivity types) and mapping them to service profile feature vectors. The event vector is obtained by using discrete events affecting the load (such as "promotional activity started" or "scheduled backup task") as context markers, encoding them one-hot, and then mapping them to event vectors through a fully connected layer.

[0037] Step S12: Input the multivariate heterogeneous vector of the service to be loaded and the multivariate heterogeneous vector of the service into the pre-trained dynamic behavior prediction model to obtain the resource conflict probability between the service to be loaded and the service predicted by the dynamic behavior prediction model within a first preset time period.

[0038] Here, the multivariate heterogeneous vectors of the two services are used as the input vectors of the dynamic behavior prediction model. The dynamic behavior prediction model predicts the merged resource consumption, resource conflict probability, and QoS default risk after the two services are merged and deployed. Merged resource consumption refers to the merged resource consumption data of the two services over a future period after the merged deployment. This merged resource consumption data includes CPU utilization and memory consumption, etc. The output dimension of the dynamic behavior prediction model is [resource type, quantile, future time point]. As an example, the predicted CPU consumption is [CPU, P90, t=5], representing the 90th quantile of CPU utilization predicted by the dynamic behavior prediction in the 5th minute of the future. The resource conflict probability is the predicted probability of severe resource contention occurring in the merged group over a future period, ranging from [0, 1]. The QoS default risk is the probability that the QoS service performance indicators will exceed the SLA (Service Level Agreement) threshold due to the influence of resource-consuming services. Each QoS service outputs a risk probability within the range of [0, 1].

[0039] In the embodiments of this application, the dynamic behavior prediction model is trained as follows: The dynamic behavior prediction model adopts an Encoder-Decoder architecture. In the Encoder layer, dynamic features are extracted using parallel LSTM for each service's historical behavior vector and profile features. Simultaneously, an attention module is added to calculate the attention weights between different service features, thereby simulating resource competition. The attention module uses a graph bias attention mechanism, i.e., the score is summed with the graph bias before softmax activation. Specifically, when the dynamic behavior prediction model calculates the attention weights between service A and service B, it relies not only on the dynamic features of A and B but also incorporates a graph bias. In the Decoder layer, the dynamic behavior prediction model decodes and generates historical behavior feature vectors, profile feature vectors, and event vectors. As an example, the formula for calculating the total attention score is: ,in, It is a learnable or preset scalar bias factor used to adjust the strength of the spectral bias; For spectral offset, To serve the dynamic characteristics of A, To serve the dynamic characteristics of B, The total attention score, This is the correlation calculation function. The attention score is obtained by normalizing the total attention score.

[0040] In the embodiments of this application, the goal of the dynamic behavior prediction model is to predict the emergent behavior of multiple services after a hypothetical merger, focusing on the relationships between services.

[0041] In the embodiments of this application, the graph bias is obtained as follows: the physical and logical resources of the cluster and their relationships are abstracted into a computable and queryable resource state graph G=(V, E, W). In the resource state graph, V represents the node set, including physical host nodes, container nodes, service nodes, etc.; E represents the edge set, covering which host the container is deployed on, which container the service is deployed in, and the call relationship between services, etc.; W is the graph bias, i.e., the edge weight, representing the affinity between services. The weights are updated through periodic calculation. For example, the edge weight between service A and service B can be calculated using the following formula: ,in This represents the average network traffic between two services over the past period. This represents the average number of RPC calls over the past period. Norm() is the normalization function. and It is an adjustable business weighting factor.

[0042] Step S13: Based on the affinity between the service to be loaded and the service, the complementarity of resource profiles, and the probability of resource conflicts, determine the combined fitness score of the service to be loaded and the service.

[0043] Here, when the task type of the service to be loaded is a computational task, resource complementarity will be given priority; when the task type of the service to be loaded is a highly sensitive task, the risk of mutual interference between the service to be loaded and other services will be considered. If there is a risk of mutual interference, the fitness score will be 0.

[0044] In this embodiment, the fitness score is calculated based on three dimensions. The resource profile complementarity between services is determined by analyzing the historical resource usage curves of two services. If one service is at a peak and the other is at a trough, it represents perfect complementarity, and the resource profile complementarity is 1. If the historical resource usage curves of the two services completely overlap, the resource profile complementarity is 0. The reason for using service affinity as a calculation dimension is that merging and deploying services with high affinity can significantly reduce cross-node communication latency and network overhead. The reason for using the resource conflict probability between services as a calculation dimension is to avoid deploying latency-sensitive high-QoS services and interference services with large fluctuations in resource consumption on the same container or node, ensuring service stability.

[0045] As an example, when the task type of the service to be loaded is a computational task, the merge fitness score can be calculated using formula (1). When the task type of the service to be loaded is a highly sensitive task, the merge fitness score can be calculated using formula (2).

[0046] (1), (2).

[0047] in, This is a decision function used to determine whether there is a risk of mutual interference between the service to be loaded and other services. If there is a risk of mutual interference, then... If the value is 0, then there is no risk of mutual interference. =1; The weights corresponding to the complementarity of resource profiles. To create complementary resource profiles, The weights corresponding to affinity. The weights corresponding to the resource conflict probabilities. This represents the probability of resource conflicts.

[0048] Step S14: Select the highest combined fitness score from the combined fitness scores of the service to be loaded and all services.

[0049] Step S15: For each container, the sum of the combined fitness scores of the service to be loaded and all services in that container is determined as the total combined fitness score of that container.

[0050] Step S16: Select the highest total merge fitness score from the total merge fitness scores of all containers.

[0051] Step S17: The strategy of merging the service to be loaded into the container with the maximum total merge fitness score is determined as the first container scheduling strategy.

[0052] In this embodiment, the strategy for placing the service to be loaded into the first new container is defined as the second container scheduling strategy. Here, the second container scheduling strategy mimics the method of a traditional scheduler. When a suitable existing container cannot be found, or in order to preserve the status quo as a comparison benchmark, a physical node is selected for the service to be loaded, and a new, independent container is created to ensure the stability of the service.

[0053] The following is combined Figure 3 Let's explain in detail how to generate a third container scheduling strategy.

[0054] Please see Figure 3 , Figure 3 This is the third flowchart of a cloud platform container scheduling method provided in the embodiments of this application.

[0055] like Figure 3 As shown, the third container scheduling policy is generated in the following way: Step S21: Select services from all services in the physical cluster whose resource consumption ratio is lower than a preset ratio.

[0056] Step S22: Select the service with the highest affinity from the affinity between the service to be loaded and the service whose resource consumption ratio is lower than the preset ratio.

[0057] Step S23: The strategy of moving the service to be loaded and the service whose resource consumption ratio corresponding to the maximum affinity is lower than the preset ratio to the second new container is determined as the third container scheduling strategy.

[0058] Here, the third container scheduling strategy will actively look for an existing service in the physical cluster with low load (i.e. resource consumption ratio) and high affinity with the service to be loaded, trigger service migration, and migrate the existing service and the service to be loaded together to a new container.

[0059] The following is combined Figure 4 Let's explain in detail how to generate the fourth container scheduling strategy.

[0060] Please see Figure 4 , Figure 4 This is the fourth flowchart of a cloud platform container scheduling method provided in the embodiments of this application.

[0061] like Figure 4 As shown, the fourth container scheduling policy is generated in the following way: Step S31: Filter out services with an affinity greater than a preset affinity threshold from the affinity between the service to be loaded and all services, and identify services with an affinity greater than the preset affinity threshold as related services.

[0062] Step S32: For each associated service, input the multivariate heterogeneous vector of the service to be loaded and the multivariate heterogeneous vector of the associated service into the pre-trained dynamic behavior prediction model, and obtain the resource conflict probability between the service to be loaded and the associated service predicted by the dynamic behavior prediction model within a second preset time period.

[0063] Here, the first preset time is longer than the second preset time. A dynamic behavior prediction model is used to predict the probability of resource conflicts between services to be loaded and related services in the near future.

[0064] Step S33: Select the associated service with the lowest resource conflict probability from the resource conflict probabilities between the service to be loaded and all associated services.

[0065] Step S34: If the minimum resource conflict probability selected is less than the preset probability threshold, then determine the start execution time of the associated service with the minimum resource conflict probability.

[0066] Step S35: The strategy of waiting for the start execution time of the service to be loaded is determined as the fourth container scheduling strategy.

[0067] Here, as an example, if a service with a low probability of resource conflict has an 80% chance of starting execution within 3 minutes, then the service to be loaded will be waited for 3 minutes. The fourth container scheduling strategy introduces time-dimensional decision-making considerations, not only limiting itself to immediate response to the current request, but also seeking global scheduling benefits across time windows, thereby achieving a more global optimization.

[0068] Return to reference Figure 1 Step S103: Based on the state information of the digital twin, determine the score of the target container scheduling strategy.

[0069] The following is combined Figure 5 This section will explain in detail how to determine the score of the target container scheduling strategy based on the state information of the digital twin.

[0070] Please see Figure 5 , Figure 5 This is the fifth flowchart of a cloud platform container scheduling method provided in the embodiments of this application.

[0071] like Figure 5 As shown, regarding step S103, in a specific implementation, as an example, the following steps may be included: Step S1031: When executing the target container scheduling policy, identify the key services corresponding to the target container scheduling policy.

[0072] Here, after generating the target container scheduling policy, firstly, a snapshot of the digital twin's baseline state at the current moment is obtained. Then, a completely independent and computationally isolated simulation session is created for each container scheduling policy.

[0073] Once a container scheduling policy is input into the simulation session, the simulation engine parses the policy and identifies all key services involved in the hypothetical co-location scenario under that policy. Key services are the set of services that coexist in the same hypothetical co-location scenario after the container scheduling policy is executed. Under the first container scheduling policy, the key services involved in the hypothetical co-location scenario include: services to be loaded and services in containers with the highest total combined fitness score. Under the second container scheduling policy, the key services involved in the hypothetical co-location scenario include: services to be loaded. Under the third container scheduling policy, the key services involved in the hypothetical co-location scenario include: services to be loaded and services whose resource consumption ratio corresponding to the highest affinity is lower than a preset ratio. Under the fourth container scheduling policy, the key services involved in the hypothetical co-location scenario include: services to be loaded and related services with the lowest probability of resource conflict.

[0074] Step S1032: Based on the status information of the key services corresponding to the target container scheduling strategy in the digital twin, determine the indicators corresponding to the target container scheduling strategy.

[0075] Here, based on the status information of the key services corresponding to the target container scheduling strategy in the digital twin, the multivariate heterogeneous vector of the key services is determined. The multivariate heterogeneous vector of the key services is then input into the dynamic behavior prediction model to obtain the resource consumption, resource conflict probability, and QoS default risk of the key services within a first preset time period predicted by the dynamic behavior prediction model.

[0076] By integrating the merged resource consumption, resource conflict probability, and QoS default risk among critical services with the predicted state of services that have not changed in the digital twin, we can obtain the merged resource consumption of each node at each future time point, analyze the remaining resource distribution of each node at each future time point, the operating status of each service at each future time point, and the future resource consumption ratio fluctuation trend and safety margin of the physical cluster as a whole, so as to construct the complete cluster state at the first preset time in the future.

[0077] Step S1033: Determine the score of the target container scheduling strategy based on the indicators corresponding to the target container scheduling strategy.

[0078] Here, the indicators include: future scheduling feasibility space, resource fragmentation evolution trend index, SLA default expectation value, opportunity waiting benefit risk ratio, energy consumption performance trade-off efficiency, and future migration demand and chain risk index.

[0079] In this application, the future scheduling feasible space is the average of the total remaining resources of all nodes in the physical cluster within a first preset time period. As an example, the future scheduling feasible space can be calculated using formula (3).

[0080] (3).

[0081] in, To provide feasible space for future scheduling The time for future prediction, i.e., the first prediction time. Let n be the upper limit of physical resources for node n. The resource consumption for merging node n at time t.

[0082] In this application, the resource fragmentation evolution trend index is the variance of the remaining resources of all nodes. The larger the variance, the more uneven the resource distribution, which is more conducive to scheduling large tasks and thus reducing the degree of fragmentation. As an example, the resource fragmentation evolution trend index can be calculated by formula (4).

[0083] (4).

[0084] in, This is an index representing the evolution trend of resource fragments.

[0085] In this application, the expected value of SLA default is the sum of the QoS default risks of all services at all times within a first preset time period. As an example, the expected value of SLA default can be calculated using formula (5).

[0086] (5).

[0087] in, The expected default value of the SLA. To address the QoS default risk output at time t.

[0088] In this application, the opportunity-wait-benefit-risk ratio is used to assess whether waiting for a better future deployment is worthwhile in the fourth container scheduling strategy, i.e., the expected benefit minus the waiting cost. As an example, the opportunity-wait-benefit-risk ratio can be calculated using formula (6).

[0089] (6).

[0090] in, Waiting for the risk-reward ratio of an opportunity The execution probability of the correlation service with the minimum probability of resource conflict. The fitness score is calculated by combining the services to be loaded with the services that have the lowest probability of resource conflicts. The penalty factor per unit time. The start time of the associated service with the lowest probability of resource conflict.

[0091] In this application, the energy consumption-performance trade-off efficiency is used to evaluate the trade-off efficiency of the strategy between energy consumption and performance. Energy consumption is positively correlated with the proportion of CPU resource consumption, so future CPU resource consumption is used as a direct proxy indicator of energy consumption, and the lower the energy consumption-performance trade-off efficiency, the better. As an example, the energy consumption-performance trade-off efficiency can be calculated by formula (7).

[0092] (7).

[0093] in, To compromise energy efficiency over performance, This represents the percentage of CPU resource consumption.

[0094] In this application, the future migration demand and cascading risk index is the sum of the "resource conflict probability" within the first preset time period. If the resource conflict probability is high, migration may be necessary in the future. As an example, the energy consumption performance trade-off efficiency can be calculated using formula (8).

[0095] (8).

[0096] in, To compromise energy efficiency over performance, This represents the probability of resource conflict between services at time t.

[0097] In the implementation of this application, and A positive indicator (the higher the better), targeting and The maximum value normalization is used as an example. The calculation method of maximum value normalization is shown in formula (9).

[0098] (9).

[0099] in, for and , This is the result after normalizing the maximum value of the indicator. This refers to the maximum value of the metric across all current container scheduling policies. The minimum value of the metric among all current container scheduling policies. To prevent the value from being zero or a minimum.

[0100] In the implementation of this application, and A negative indicator (the smaller the better), targeting and Inverse normalization is used as an example. The inverse normalization calculation method is shown in formula (10).

[0101] (10).

[0102] in, for and , and , This is the result after inverse normalization of the indicator.

[0103] In this implementation, the corresponding weight vector is loaded according to the scheduling objective configured by the user (e.g., "cost priority" or "performance priority"). The weight vector can be obtained through W=[ , , , ] indicates that, , For the corresponding weights , for The corresponding weights for The corresponding weights for The corresponding weights. As an example, in high-performance mode... =0.4, =0.4, =0.1, =0.1.

[0104] As an example, the scores for the first, second and third container scheduling policies can be calculated using formula (11).

[0105] (11).

[0106] in, As one of the scores in the first, second, and third container scheduling strategies, k It is one of the scheduling policies among the first, second, and third container scheduling policies. This is the penalty coefficient. Wherein, The indicator is not subject to normalization; instead, it is converted into a penalty coefficient to enforce the veto mechanism. Specifically, if... If the risk exceeds the set risk coefficient, the penalty coefficient is 0; otherwise, it is 1.

[0107] In this application, the score of the fourth container scheduling strategy is determined by: determining the highest score among the scores of the first, second, and third container scheduling strategies; and determining the score of the fourth container scheduling strategy by summing the highest score with the index corresponding to the fourth container scheduling strategy.

[0108] Step S104: Determine the container scheduling policy with the highest score among the target container scheduling policies, and execute the container scheduling policy with the highest score on the physical cluster.

[0109] Here, after selecting the optimal container scheduling strategy, the system automatically converts it into a sequence of native API instructions executable by the underlying container platform (such as Kubernetes) (e.g., creating new containers, loading a specified list of services, destroying old containers, etc.) and performs scheduling operations in the physical cluster.

[0110] This application provides a cloud platform container scheduling method that improves resource utilization.

[0111] Based on the same application concept, this application also provides a cloud platform container scheduling device corresponding to the cloud platform container scheduling method provided in the above embodiments. Since the principle of the device in this application to solve the problem is similar to the cloud platform container scheduling method in the above embodiments of this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0112] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a cloud platform container scheduling device provided in an embodiment of this application.

[0113] like Figure 6 As shown in the figure, the cloud platform container scheduling device 610 provided in this application embodiment includes: The acquisition module 611 is used to acquire the status information of the physical cluster corresponding to the cloud platform and construct a digital twin that is synchronized with the status of the physical cluster. The generation module 612 is used to generate a target container scheduling strategy for the services to be loaded into the physical cluster. The scoring module 613 is used to determine the score of the target container scheduling strategy based on the state information of the digital twin. The execution module 614 is used to determine the container scheduling policy with the highest score among the target container scheduling policies, and to execute the container scheduling policy with the highest score on the physical cluster.

[0114] Furthermore, the generation module 612 is specifically used for: For each service in each container of the physical cluster, determine the multivariate heterogeneous vector of the service from the state information of the digital twin; The multivariate heterogeneous vectors of the service to be loaded and the multivariate heterogeneous vectors of the service are input into a pre-trained dynamic behavior prediction model to obtain the resource conflict probability between the service to be loaded and the service predicted by the dynamic behavior prediction model within a first preset time period. Based on the affinity, resource profile complementarity, and resource conflict probability between the service to be loaded and the service, the combined fitness score of the service to be loaded and the service is determined. For each container, the sum of the combined fitness scores of the service to be loaded and all services in that container is determined as the total combined fitness score of that container. Select the highest total merge fitness score from the total merge fitness scores of all containers; The strategy of incorporating the services to be loaded into containers with the highest total merge fitness score is determined as the first container scheduling strategy.

[0115] Furthermore, the generation module 612 is specifically used for: The strategy of placing the service to be loaded into the first new container is determined as the second container scheduling strategy.

[0116] Furthermore, the generation module 612 is specifically used for: Select services from all services in the physical cluster whose resource consumption percentage is lower than a preset percentage; The service with the highest affinity is selected from the affinity between the services to be loaded and services whose resource consumption ratio is lower than a preset ratio. The strategy of moving the services to be loaded and services whose resource consumption ratio corresponding to the maximum affinity is lower than the preset ratio to the second new container is determined as the third container scheduling strategy.

[0117] Furthermore, the generation module 612 is specifically used for: Filter out services with an affinity greater than a preset affinity threshold from the affinity between the service to be loaded and all services, and identify services with an affinity greater than the preset affinity threshold as related services; For each associated service, the multivariate heterogeneous vector of the service to be loaded and the multivariate heterogeneous vector of the associated service are input into a pre-trained dynamic behavior prediction model to obtain the resource conflict probability between the service to be loaded and the associated service predicted by the dynamic behavior prediction model within a second preset time period. The service with the lowest probability of resource conflict is selected from the resource conflict probabilities between the service to be loaded and all related services. If the minimum resource conflict probability selected is less than the preset probability threshold, then the start execution time of the associated service with the minimum resource conflict probability is determined. The strategy of waiting for the start execution time for the service to be loaded is determined as the fourth container scheduling strategy.

[0118] Furthermore, the scoring module 613 is specifically used for: When executing the target container scheduling policy, identify the key services corresponding to the target container scheduling policy; Based on the status information of the key services corresponding to the target container scheduling strategy in the digital twin, the indicators corresponding to the target container scheduling strategy are determined. The score of the target container scheduling policy is determined based on the metrics corresponding to the target container scheduling policy.

[0119] Furthermore, when the scoring module 613 is used to determine the score of the target container scheduling strategy based on the indicators corresponding to the target container scheduling strategy, it is also specifically used for: Determine the highest score among the scores of the first container scheduling policy, the second container scheduling policy, and the third container scheduling policy; The sum of the highest score and the index corresponding to the fourth container scheduling strategy is determined as the score of the fourth container scheduling strategy.

[0120] This application provides a cloud platform container scheduling device that improves resource utilization.

[0121] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0122] like Figure 7 As shown, the electronic device 700 includes a processor 710, a memory 720, and a bus 730.

[0123] The memory 720 stores machine-readable instructions executable by the processor 710. When the electronic device 700 is running, the processor 710 communicates with the memory 720 via the bus 730. When the machine-readable instructions are executed by the processor 710, they can perform the operations described above. Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 The specific implementation of the cloud platform container scheduling method in the method embodiment shown can be found in the method embodiment, and will not be repeated here.

[0124] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 The specific implementation of the cloud platform container scheduling method in the method embodiment shown can be found in the method embodiment, and will not be repeated here.

[0125] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0126] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0127] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0128] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0129] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A cloud platform container scheduling method, characterized in that, The method comprises: obtaining state information of a physical cluster corresponding to a cloud platform, and constructing a digital twin synchronized with the state of the physical cluster; generating a target container scheduling strategy for a to-be-loaded service to be loaded into the physical cluster; determining a score of the target container scheduling strategy based on the state information of the digital twin; determining a container scheduling strategy with the highest score in the target container scheduling strategy, and executing the container scheduling strategy with the highest score on the physical cluster.

2. The cloud platform container scheduling method of claim 1, wherein, The generating of the target container scheduling strategy for the to-be-loaded service to be loaded into the physical cluster comprises: determining a multi-element heterogeneous vector of each service in each container of the physical cluster from the state information of the digital twin; inputting the multi-element heterogeneous vector of the to-be-loaded service and the multi-element heterogeneous vector of the service into a pre-trained dynamic behavior prediction model to obtain a resource conflict probability between the to-be-loaded service and the service within a first preset time predicted by the dynamic behavior prediction model; determining a merging fitness score of the to-be-loaded service and the service based on affinity, resource image complementarity and resource conflict probability between the to-be-loaded service and the service; determining a total merging fitness score of each container as a sum of merging fitness scores of the to-be-loaded service and all services of the container; selecting a maximum total merging fitness score from total merging fitness scores of all containers; determining a strategy of incorporating the to-be-loaded service into the container with the maximum total merging fitness score as a first container scheduling strategy. 3.The cloud platform container scheduling method of claim 2, wherein, The generating of the target container scheduling strategy for the to-be-loaded service to be loaded into the physical cluster comprises: determining a strategy of placing the to-be-loaded service into a first new container as a second container scheduling strategy.

4. The cloud platform container scheduling method of claim 3, wherein, The generating of the target container scheduling strategy for the to-be-loaded service to be loaded into the physical cluster comprises: selecting services with resource consumption proportions lower than a preset proportion from all services of the physical cluster; selecting a maximum affinity from affinity between the to-be-loaded service and the services with resource consumption proportions lower than the preset proportion; determining a strategy of moving the to-be-loaded service and the service with the maximum affinity and a resource consumption proportion lower than the preset proportion to a second new container as a third container scheduling strategy.

5. The cloud platform container scheduling method of claim 4, wherein, The generating of the target container scheduling strategy for the to-be-loaded service to be loaded into the physical cluster comprises: selecting an affinity greater than a preset affinity threshold from affinity between the to-be-loaded service and all services, and determining services with the affinity greater than the preset affinity threshold as related services; for each related service, inputting a multi-element heterogeneous vector of the to-be-loaded service and a multi-element heterogeneous vector of the related service into a pre-trained dynamic behavior prediction model to obtain a resource conflict probability between the to-be-loaded service and the related service within a second preset time predicted by the dynamic behavior prediction model; selecting a related service with a minimum resource conflict probability from resource conflict probabilities between the to-be-loaded service and all related services; If the smallest resource conflict probability is smaller than a preset probability threshold, a start execution time of the associated service with the smallest resource conflict probability is determined. A strategy of waiting for the start execution time for the to-be-loaded service is determined as a fourth container scheduling strategy.

6. The cloud platform container scheduling method of claim 1, wherein, The score of the target container scheduling strategy is determined based on the state information of the digital twin, including: In executing the target container scheduling strategy, a key service corresponding to the target container scheduling strategy is identified; Based on the state information of the key service corresponding to the target container scheduling strategy in the digital twin, an index corresponding to the target container scheduling strategy is determined; The score of the target container scheduling strategy is determined based on the index corresponding to the target container scheduling strategy.

7. The cloud platform container scheduling method of claim 5, wherein, The score of the target container scheduling strategy is determined based on the index corresponding to the target container scheduling strategy, including: The highest score among the scores of the first container scheduling strategy, the second container scheduling strategy and the third container scheduling strategy is determined; The sum of the highest score and an index corresponding to the fourth container scheduling strategy is determined as the score of the fourth container scheduling strategy. 8.A cloud platform container scheduling apparatus characterized by comprising: The cloud platform container scheduling apparatus includes: An acquisition module configured to acquire state information of a physical cluster corresponding to a cloud platform, and construct a digital twin synchronized with the state of the physical cluster; A generation module configured to generate a target container scheduling strategy for a to-be-loaded service to be loaded into the physical cluster; A score module configured to determine a score of the target container scheduling strategy based on state information of the digital twin; An execution module configured to determine a container scheduling strategy with the highest score among the target container scheduling strategies, and execute the container scheduling strategy with the highest score on the physical cluster.

9. An electronic device, comprising: It includes: A processor, a memory and a bus, the memory stores machine readable instructions executable by the processor, when the electronic device is running, the processor and the memory communicate through the bus, the machine readable instructions are executed by the processor to perform the steps of the cloud platform container scheduling method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to perform the steps of the cloud platform container scheduling method as claimed in any one of claims 1 to 7.

Images