Resource configuration method and device, equipment and storage medium

Abstract

The invention relates to the technical field of computers, in particular to a resource configuration method, device and equipment and a computer readable storage medium. The method comprises the following steps: acquiring historical parameters of multiple types of applications deployed in a cluster; wherein the historical parameters are used for indicating the historical use condition of the Pod for running the corresponding application on the cluster resources; determining N groups of posterior probabilities in one-to-one correspondence with the N application types based on historical parameters of the multiple types of applications; wherein the group of posterior probabilities corresponding to one application type comprises M posterior probabilities in one-to-one correspondence with the M preset parameters, and the ith posterior probability is used for representing the adaptation degree between the corresponding application type and the ith preset parameter; 1 < = i < = M; m and N are positive integers; based on the maximum posterior probability in a group of posterior probabilities corresponding to the application type of the to-be-deployed application in the N groups of posterior probabilities, determining configuration parameters of the target Pod; wherein the target Pod is used for providing a running environment for the to-be-deployed application in the cluster.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, and computer-readable storage medium for configuring resources. Background Technology

[0002] With the widespread adoption of containerization technologies and clusters such as Kubernetes clusters (K8s), the proper allocation of Pod resources within a cluster has become a key factor in ensuring cluster stability and resource utilization. A Pod is the smallest scheduling unit in a cluster, used to provide a runtime environment for applications deployed within the cluster.

[0003] In conventional technologies, static resource configuration is typically used to set configuration parameters for Pods. This configuration method often leads to problems such as waste of cluster resources or frequent resource contention. Summary of the Invention

[0004] This application provides a method, apparatus, device, and computer-readable storage medium for configuring resources, specifically disclosing the following technical solutions: This application provides a method for configuring resources, the method comprising: obtaining historical parameters of multiple types of applications deployed in a cluster; wherein the historical parameters are used to indicate the historical usage of cluster resources by Pods running the corresponding applications; determining N sets of posterior probabilities corresponding one-to-one with N types of applications based on the historical parameters of multiple types of applications; wherein a set of posterior probabilities corresponding to an application type includes M posterior probabilities corresponding one-to-one with M preset parameters, wherein the i-th posterior probability is used to characterize the degree of adaptation between the corresponding application type and the i-th preset parameter; 1≤i≤M; M and N are both positive integers; determining the configuration parameters of the target Pod based on the maximum posterior probability in the set of posterior probabilities corresponding to the application type of the application to be deployed in the N sets of posterior probabilities; wherein the target Pod is used to provide a running environment for the application to be deployed in the cluster.

[0005] In this application, the maximum a posteriori probability represents the highest degree of fit between the application to be deployed and the corresponding preset parameters (i.e., the preset parameters are optimally matched with the resource requirements of the application to be deployed). This application can dynamically match the optimal resource configuration for the application to be deployed based on the application's historical performance, which avoids application lag caused by insufficient resource configuration, reduces waste caused by excessive resource allocation, and improves the automation and intelligence level of application deployment.

[0006] In some embodiments, the configuration parameters of the target Pod are determined based on the maximum posterior probability among the set of posterior probabilities corresponding to the application type of the application to be deployed in N sets of posterior probabilities, including: determining the maximum posterior probability among the set of posterior probabilities corresponding to the application type of the application to be deployed in N sets of posterior probabilities; and using the preset parameter corresponding to the maximum posterior probability as the configuration parameters of the target Pod.

[0007] Based on the above technical means, by clearly identifying and selecting the preset parameters corresponding to the maximum posterior probability, the configuration parameters of the target Pod can be made closer to the actual resource requirements, thereby improving the rationality of resource allocation and reducing resource waste or preemption problems caused by the large difference between the initial requested resource data and the actual situation.

[0008] In some embodiments, determining multiple sets of posterior probabilities corresponding to N application types based on historical parameters of multiple application types includes: determining M prior probabilities corresponding one-to-one with M preset parameters based on historical parameters of multiple application types; wherein the prior probabilities are used to indicate the distribution probability of the corresponding preset parameters in the historical parameters of multiple application types; determining M sets of conditional probabilities corresponding one-to-one with the M preset parameters based on historical parameters of multiple application types; wherein a set of conditional probabilities corresponding to a preset parameter includes N conditional probabilities corresponding one-to-one with the N application types, wherein the j-th conditional probability is used to characterize the probability that the Pod's usage value of cluster resources is the corresponding preset parameter when running an application of the j-th application type; 1≤j≤N; and determining N sets of posterior probabilities corresponding to the N application types based on the M prior probabilities and the M sets of conditional probabilities.

[0009] Based on the above technical means, by introducing prior probability and conditional probability, and combining Bayes' theorem to construct a posterior probability model, we can more comprehensively consider the distribution patterns of various parameters in historical data and the resource usage characteristics of different types of applications, thereby generating more accurate posterior probabilities and improving the scientificity and adaptability of subsequent resource allocation.

[0010] In some embodiments, based on historical parameters of multiple application types, determining M prior probabilities corresponding one-to-one with M preset parameters includes: calculating the proportion of each preset parameter in the historical parameters to obtain the prior probability corresponding to each preset parameter; determining M sets of conditional probabilities corresponding one-to-one with the M preset parameters based on historical parameters of multiple application types includes: for each preset parameter among the M preset parameters, calculating the probability values ​​of N application types using the preset parameters in the historical parameters to obtain a set of conditional probabilities corresponding to each preset parameter.

[0011] Based on the aforementioned technical means, in this embodiment, both conditional probability and prior probability are derived from historical parameter statistics of various applications. There is a logical relationship between conditional probability and prior probability. Prior probability represents the overall distribution of preset parameters, while conditional probability represents the distribution of preset parameters under a specific application type. Posterior probability is a predicted value determined based on prior probability and conditional probability. Through logical integration and probability correction of the above two types of statistical data, posterior probability predicts the suitability of specific application types and preset parameters, providing accurate decision-making basis for resource allocation of applications to be deployed.

[0012] In some embodiments, determining N sets of posterior probabilities corresponding to N application types based on M prior probabilities and M sets of conditional probabilities includes: for each application type, obtaining N sets of posterior probabilities corresponding to the application type based on the N conditional probabilities and N prior probabilities corresponding to the application type.

[0013] Based on the aforementioned technical methods, N conditional probabilities and N prior probabilities corresponding to each application type are used to obtain N sets of posterior probabilities. For example, by multiplying the conditional probabilities and prior probabilities one by one to form the posterior probabilities, the overall resource usage trend of each application type under different preset parameters can be effectively reflected, thereby providing a more accurate basis for resource allocation and optimizing the resource allocation strategy for Pods in the cluster.

[0014] In some embodiments, before obtaining historical parameters of multiple types of applications deployed in the cluster, the method further includes: periodically collecting historical usage data of cluster resources by multiple Pods running in the cluster that provide runtime environments for multiple types of applications; and obtaining historical parameters of multiple types of applications deployed in the cluster based on the historical usage data.

[0015] Based on the aforementioned technical means, by periodically collecting Pod resource usage data, the real-time nature and representativeness of historical parameters are ensured, thereby improving the accuracy of posterior probabilities and enhancing the reliability of resource allocation decisions.

[0016] In some embodiments, the method further includes: deploying the target Pod in the cluster based on a first configuration file of the Pod; the target field in the first configuration file is the configuration parameters of the target Pod.

[0017] This application provides an apparatus for configuring resources, comprising: The acquisition unit is used to acquire historical parameters of various applications deployed in the cluster; among them, the historical parameters are used to indicate the historical usage of cluster resources by the Pods running the corresponding applications. The first determining unit is used to determine N sets of posterior probabilities corresponding one-to-one with N application types based on historical parameters of multiple application types; wherein, a set of posterior probabilities corresponding to an application type includes M posterior probabilities corresponding one-to-one with M preset parameters, wherein the i-th posterior probability is used to characterize the degree of fit between the corresponding application type and the i-th preset parameter; 1≤i≤M; M and N are both positive integers; The second determining unit is used to determine the configuration parameters of the target Pod based on the maximum posterior probability among the set of posterior probabilities corresponding to the application type of the application to be deployed in N sets of posterior probabilities; wherein, the target Pod is used to provide a running environment for the application to be deployed in the cluster.

[0018] This application provides a device for configuring resources, including: one or more processors; and a memory for storing one or more programs, which, when executed by one or more processors, cause the device to implement the method described above.

[0019] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer's processor, causes the computer to perform the method described above. Attached Figure Description

[0020] Figure 1 A flowchart illustrating a method for configuring resources provided in an embodiment of this application; Figure 2 A schematic diagram illustrating an application classification provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating a method for obtaining historical parameters provided in an embodiment of this application; Figure 4 A flowchart illustrating another method for configuring resources provided in an embodiment of this application; Figure 5 This is a schematic diagram illustrating a method for deploying an application, as provided in an embodiment of this application. Figure 6 A flowchart illustrating yet another method for configuring resources provided in an embodiment of this application; Figure 7 A schematic diagram of a device for configuring resources provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a device for configuring resources, provided in an embodiment of this application. Detailed Implementation

[0021] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0022] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0023] With the widespread adoption of containerization technologies and clusters such as Kubernetes clusters (K8s), the proper configuration of Pod resources within a cluster has become a key factor in ensuring cluster stability and resource utilization. A Pod is the smallest scheduling unit in a cluster, used to provide a runtime environment for applications deployed on the cluster.

[0024] In conventional techniques, static resource configuration is typically used to set configuration parameters for Pods, such as hardware resource requests and / or maximum usage limits. For example, configuration files, such as YAML files, define the configuration information for the Pods corresponding to the application. When deploying an application in a cluster, the configuration file for the Pod corresponding to the application is submitted to the cluster, which automatically schedules and creates the Pod and starts its lifecycle based on the configuration file. The configuration parameters in the configuration file are usually fixed values, and the configuration parameters in the configuration files of different applications are consistent. For example, the configuration parameters in the configuration file may be based on experience. This technique cannot accurately match the needs of each application, leading to inefficient cluster resource utilization. For example, some applications may have long-term resource idleness due to excessive quotas, while other applications may face performance bottlenecks due to insufficient quotas, resulting in resource contention.

[0025] Therefore, embodiments of this application provide a method, apparatus, device, and computer-readable storage medium for configuring resources. The resource configuration method proposed in this application is applicable to electronic devices with data computing capabilities. Embodiments of this application collect historical parameters of multiple types of applications deployed in a cluster and calculate the posterior probabilities corresponding to different application types. The configuration parameters of the target Pod for the application to be deployed are determined based on the maximum posterior probability among the posterior probabilities corresponding to the application to be deployed. The maximum posterior probability represents the highest degree of adaptation between the application to be deployed and the corresponding preset parameters (i.e., the preset parameters have the best adaptability to the resource requirements of the application to be deployed). This application can dynamically match the optimal resource configuration for the application to be deployed based on the application's historical performance, avoiding application lag caused by insufficient resource configuration, reducing waste caused by excessive resource allocation, and improving the automation and intelligence level of application deployment.

[0026] The following description, in conjunction with the accompanying drawings and specific embodiments, introduces a method, apparatus, device, and computer-readable storage medium for configuring resources provided in this application. Figure 1 This is a schematic diagram of a method for configuring resources provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes: S101 retrieves historical parameters of various applications deployed in the cluster.

[0027] Multiple application types refer to applications of various types deployed in a cluster, such as N application types, where N is a positive integer. In this embodiment, the electronic device can obtain historical parameters of multiple applications of various application types deployed in the cluster. One application type can correspond to multiple applications; that is, for one application type, historical parameters of multiple applications under that application type can be obtained.

[0028] In some embodiments, various application types may include, for example, compute-intensive, memory-intensive, and input / output (I / O)-intensive. Applications such as big data processing and machine learning training, which require more processor resources to perform complex computational tasks, are defined as compute-intensive. Applications such as databases and caching services, which require large amounts of memory to store data and process requests, are defined as memory-intensive. Applications such as web servers and file storage services, while their processor and memory requirements may not be very high, still need to be configured appropriately based on the number of concurrent connections and requests; therefore, these applications are defined as I / O-intensive.

[0029] For example, such as Figure 2As shown, applications can be categorized into compute-intensive, memory-intensive, and I / O-intensive applications. Furthermore, based on workload, applications can also be classified as high-load and low-load applications. Figure 2 As shown, applications can be further categorized into compute-intensive high-load applications, compute-intensive low-load applications, memory-intensive high-load applications, memory-intensive low-load applications, I / O-intensive high-load applications, and I / O-intensive low-load applications. High-load applications require more resources to process requests, while low-load applications require relatively fewer resources. Furthermore, applications can be classified based on their configuration, which is related to the number of threads, processes, and thread pool size. For example, applications can be further categorized into Class A, Class B, and Class C applications based on the size of their thread pool. A thread pool is a collection of reusable threads created and managed by the application. The size of the thread pool can be characterized using parameters such as the core thread count and the maximum thread count. Figure 2 Applications with thread pool sizes between [1, 10] can be classified as Class A applications; applications with thread pool sizes between [10, 50] can be classified as Class B applications; and applications with thread pool sizes greater than 50 can be classified as Class C applications. Applications can then be further categorized into: compute-intensive high-load Class A applications, compute-intensive high-load Class B applications, compute-intensive high-load Class C applications, compute-intensive low-load Class A applications, compute-intensive low-load Class B applications, compute-intensive low-load Class C applications, memory-intensive high-load Class A applications, memory-intensive high-load Class B applications, memory-intensive high-load Class C applications, memory-intensive low-load Class A applications, memory-intensive low-load Class B applications, memory-intensive low-load Class C applications, I / O-intensive high-load Class A applications, I / O-intensive high-load Class B applications, I / O-intensive high-load Class C applications, I / O-intensive low-load Class A applications, I / O-intensive low-load Class B applications, and I / O-intensive low-load Class C applications.

[0030] In this embodiment, a cluster refers to a logical whole formed by connecting multiple independent computers (called nodes) through a network and integrating them through a unified management system. It presents itself externally as a high-performance, highly available single pool of computing resources, capable of automatically scheduling and running applications. For example, Kubernetes (K8s) is a containerized management system built on Kubernetes. A Kubernetes-based containerized management system consists of multiple physical or virtual nodes used to deploy and run Pods.

[0031] Historical parameters are used to indicate the historical usage of cluster resources by the Pods running the corresponding application. Cluster resources can be one or more of the following: processor resources, storage resources, network resources, etc. For example, historical parameters can be at least one of average and maximum values.

[0032] In some embodiments, electronic devices can retrieve historical usage data of cluster resources from a database for various applications, and based on this historical usage data, obtain historical parameters for these applications. The historical usage data includes the actual usage and duration of resources such as processors, memory, disks, and I / O. Application usage of cluster resources can be understood as the use of cluster resources by the Pods running the application.

[0033] For example, an electronic device can periodically collect historical resource usage data of multiple Pods running in a cluster that provide runtime environments for various applications. For instance, the electronic device can periodically collect data on the actual resource usage of multiple Pods running in the cluster at set time intervals. This time interval could be, for example, every minute / time, every hour / time, etc. The electronic device can store the collected historical usage data in a database. When there is an application deployment requirement, the electronic device can obtain historical parameters of various applications deployed in the cluster based on the historical usage data stored in the database. For example, the electronic device can perform statistical analysis on the historical usage data of various applications to obtain historical parameters of various applications. This statistical analysis includes obtaining maximum and average values. For example, the electronic device can obtain the maximum and average processor usage and the maximum and average memory usage for each application.

[0034] By analyzing the collected resource usage data, historical parameters of various applications deployed in the cluster can be extracted, which helps to establish a more scientific and reasonable resource scheduling mechanism. This enables more accurate resource request and restriction decisions to be made before application deployment, thereby reducing resource conflicts and preemption, and improving the overall stability and response speed of the cluster.

[0035] In this embodiment, data on cluster resource usage is periodically collected from multiple Pods running in the cluster that provide runtime environments for various applications. Based on this data, historical parameters of the various applications deployed in the cluster are obtained. This provides a more comprehensive understanding of the resource requirements of the various applications deployed in the cluster, offering a reliable basis for subsequent resource decisions and ultimately optimizing the allocation and scheduling of cluster resources.

[0036] For example, such as Figure 3As shown, the electronic device uses a data collection tool 310, such as Grafana, to collect historical usage data of cluster resources from various applications deployed in cluster 300. For example, Grafana collects historical usage data of cluster resources from the pods running applications through services in the cluster. The electronic device stores the collected historical usage data in database 320. When there is an application deployment requirement, the electronic device uses filters 330 to statistically analyze the historical usage data to obtain historical parameters of various applications, i.e., historical parameter sets 340.

[0037] After obtaining the historical parameters of multiple types of applications deployed in the cluster, the electronic device can determine N sets of posterior probabilities corresponding to N types of applications based on the historical parameters. For example, the electronic device can execute S102.

[0038] S102, based on the historical parameters of multiple application types, determine N sets of posterior probabilities that correspond one-to-one with the N application types.

[0039] In this embodiment, based on historical parameters of multiple application types, the electronic device can obtain N sets of posterior probabilities corresponding one-to-one with the N types of multiple applications. For example, taking multiple applications as compute-intensive, memory-intensive, and I / O-intensive applications, the electronic device can obtain one set of posterior probabilities corresponding to compute-intensive applications, one set of posterior probabilities corresponding to memory-intensive applications, and one set of posterior probabilities corresponding to I / O-intensive applications. As another example, taking multiple applications as compute-intensive high-load applications, compute-intensive low-load applications, memory-intensive high-load applications, memory-intensive low-load applications, I / O-intensive high-load applications, and I / O-intensive low-load applications, the electronic device can obtain one set of posterior probabilities corresponding to compute-intensive high-load applications, one set of posterior probabilities corresponding to compute-intensive low-load applications, one set of posterior probabilities corresponding to memory-intensive high-load applications, one set of posterior probabilities corresponding to memory-intensive low-load applications, one set of posterior probabilities corresponding to I / O-intensive high-load applications, and one set of posterior probabilities corresponding to I / O-intensive low-load applications. The following section will describe, with specific examples, the method for determining N sets of posterior probabilities that correspond one-to-one with N application types, which will not be elaborated here.

[0040] In this embodiment, the set of posterior probabilities corresponding to an application type includes M posterior probabilities that correspond one-to-one with M preset parameters. The preset parameters are pre-set configuration parameters. The M preset parameters can be a preset parameter set Y, Y = {y1, y2, ..., y...} M}. Here, yi is the i-th preset parameter among M preset parameters, 1 ≤ i ≤ M. M is a positive integer. For example, taking cluster resources as processors such as CPU resources, with M equal to 6, the preset parameter set Y can be defined as a series of discrete CPU core counts. For example, Y = {0.1 cores, 0.5 cores, 1 core, 2 cores, 4 cores, 8 cores}. Again, for example, taking cluster resources as processors such as CPU resources and memory resources, with M equal to 6, the preset parameter set Y can be defined as a series of discrete combinations of CPU core counts and memory specifications. For example, Y = {(0.1 cores, 256 MiB), (0.5 cores, 512 MiB), (1 core, 1 GiB), (2 cores, 2 GiB), (4 cores, 4 GiB), (8 cores, 8 GiB}.

[0041] In some embodiments, the configuration parameters of a Pod include a request value and a limit value. The request value defines the minimum resource guarantee that the Pod must ensure when scheduled. The scheduler uses this value to find nodes with sufficient available resources for the Pod. The limit value defines the hard upper limit of resources that the Pod is allowed to use during runtime. The request value corresponds to the average usage value in the preset parameters, and the limit value corresponds to the maximum usage value in the preset parameters. In a single-objective scenario, such as when only one of the request value or the limit value needs to be determined in the configuration parameters, the preset parameters are either the preset average usage value or the preset maximum usage value. In a multi-objective scenario, such as a dual-objective scenario, where both the request value and the limit value need to be determined, the electronic device can be configured with two sets of preset parameters: one set of preset average usage values ​​and the other set of preset maximum usage values. In this case, for each set of preset parameters, the electronic device can execute S102 and S103 once to obtain the configuration parameters of the application to be deployed in one dimension. Alternatively, in a dual-objective scenario, the preset parameters include both the average usage value and the maximum usage value. For example, taking cluster resources as processors such as CPU resources, with M equal to 5, Y = {(0.1 cores, 0.5 cores), (1.0 cores, 2.0 cores), (2.0 cores, 4.0 cores), (4.0 cores, 6.0 cores), (8.0 cores, 12.0 cores)}. Here, the first value in the tuple can be a preset average usage value, and the second value is a preset maximum usage value. For example, (0.1 cores, 0.5 cores) means that the average usage value in the first preset parameter is 0.1 cores, and the maximum usage value is 0.5 cores. Thus, in a dual-target scenario, the electronic device only needs to execute S102 and S103 once to obtain the configuration parameters in both dimensions. For example, taking cluster resources as processor resources such as CPU resources and memory resources, with M equal to 5, Y = {(0.1 cores, 0.5 cores, 256 MiB, 512 MiB), (1.0 cores, 2.0 cores, 512 MiB, 1 GiB), (2.0 cores, 4.0 cores, 1 GiB, 2 GiB), (4.0 cores, 6.0 cores, 2 GiB, 4 GiB), (8.0 cores, 12.0 cores, 4 GiB, 8 GiB)}. Here, the first value in the quadruple can be the preset average CPU usage, the second value is the preset maximum CPU usage, the third value can be the preset average memory usage, and the fourth value is the preset maximum memory usage.

[0042] As discussed above, electronic devices can acquire a set of posterior probabilities corresponding to each application type. In this embodiment, the set of posterior probabilities corresponding to each application type includes M posterior probabilities that correspond one-to-one with M preset parameters, where the i-th posterior probability is used to characterize the degree of fit between the corresponding application type and the i-th preset parameter. For example, taking cluster resources as processors such as CPU resources, and M equals 6, the set of posterior probabilities corresponding to one application type includes 6 posterior probabilities. In this set of posterior probabilities, the first posterior probability is used to characterize the degree of fit between the corresponding application type and the first preset parameter; the second posterior probability is used to characterize the degree of fit between the corresponding application type and the second preset parameter; and so on, without further elaboration.

[0043] Below is a specific example. For instance, there are M preset parameters Y = {0.1 cores, 0.5 cores, 1 core}, and the application types are compute-intensive, memory-intensive, and I / O-intensive. A set of posterior probabilities corresponds to compute-intensive applications, including three posterior probabilities. These three posterior probabilities, in turn, indicate the compatibility of compute-intensive applications with 0.1 cores, compute-intensive applications with 0.5 cores, and compute-intensive applications with 1 core. A set of posterior probabilities corresponds to memory-intensive applications, in turn, indicating the compatibility of memory-intensive applications with 0.1 cores, memory-intensive applications with 0.5 cores, and memory-intensive applications with 1 core. A set of posterior probabilities corresponds to I / O-intensive applications, in turn, indicating the compatibility of I / O-intensive applications with 0.1 cores, I / O-intensive applications with 0.5 cores, and I / O-intensive applications with 1 core. The degree of compatibility indicates how well the preset parameters match the resource requirements of the application to be deployed. A higher degree of compatibility indicates a better match between the preset parameters and the resource requirements of the application to be deployed.

[0044] After obtaining N sets of posterior probabilities corresponding one-to-one with N application types, the electronic device can determine the corresponding configuration parameters for the application to be deployed based on the application type. For example, the electronic device can execute S103.

[0045] S103. Based on the maximum posterior probability among the set of posterior probabilities corresponding to the application type of the application to be deployed in N sets of posterior probabilities, determine the configuration parameters of the target Pod.

[0046] In this embodiment, the electronic device determines a set of posterior probabilities corresponding to the application to be deployed from N sets of posterior probabilities, based on the application type of the application to be deployed. The application to be deployed refers to a new application that is about to be launched in the cluster; its resource requirements are not yet determined and need to be predicted based on historical data. The electronic device determines the configuration parameters of the target Pod based on the maximum posterior probability among the set of posterior probabilities corresponding to the application to be deployed. The maximum posterior probability is the posterior probability with the largest value among the set of posterior probabilities. The target Pod is used to provide a runtime environment for the application to be deployed in the cluster. The configuration parameters are at least one of a requested value and a maximum usage limit value. For example, the electronic device determines the requested value in the configuration parameters based on the average usage value corresponding to the maximum posterior probability. The electronic device determines the maximum usage limit value in the configuration parameters based on the maximum usage value corresponding to the maximum posterior probability.

[0047] In some embodiments, the electronic device uses a preset parameter corresponding to the maximum a posteriori probability as a configuration parameter for the target Pod. For example, the electronic device determines the maximum a posteriori probability corresponding to the application to be deployed based on preset parameters such as a preset average usage value, and uses the average usage value corresponding to that maximum a posteriori probability as the request value in the configuration parameters of the target Pod. The electronic device also determines the maximum a posteriori probability corresponding to the application to be deployed based on preset parameters such as a preset maximum usage value, and uses the maximum usage value corresponding to that maximum a posteriori probability as the maximum usage limit value in the configuration parameters of the target Pod.

[0048] Taking a compute-intensive application as an example, with a preset maximum usage value Y = {0.5 cores, 2 cores, 4 cores, 6 cores, 12 cores}, the electronic device, based on the above method, determines a set of posterior probabilities corresponding to compute-intensive applications as {0.05, 0.15, 0.3, 0.4, 0.1}. The electronic device uses the preset parameter corresponding to a posterior probability of 0.4, such as 8 cores, as the maximum usage limit value for the target Pod. As another example, with a preset average usage value Y = {0.1 cores, 0.5 cores, 1 core, 2 cores, 4 cores}, the set of posterior probabilities corresponding to compute-intensive applications is {0.1, 0.1, 0.2, 0.5, 0.1}. The electronic device uses the preset parameter corresponding to a posterior probability of 0.5, such as 2 cores, as the request value for the target Pod.

[0049] In other embodiments, the electronic device processes a preset parameter corresponding to the maximum a posteriori probability to obtain the configuration parameters of the target Pod. For example, the electronic device multiplies the preset parameter corresponding to the maximum a posteriori probability by a safety factor to obtain the configuration parameters. The preset parameter is at least one of the average usage value and the maximum usage value.

[0050] In other embodiments, the electronic device aggregates the preset parameters corresponding to the top P maximum posterior probabilities to obtain the configuration parameters of the target Pod. The aggregation process may include, for example, averaging or weighted summation. P is a positive integer.

[0051] As can be seen, the resource configuration method provided in this application calculates the posterior probability of various applications under different preset resource parameters based on historical parameters of multiple applications, and determines the configuration parameters of the target Pod based on the maximum posterior probability. This not only improves the accuracy of resource configuration, but also effectively addresses the resource waste and unreasonable allocation problems caused by traditional static configuration, providing a scientific, efficient, and scalable solution for large-scale containerized deployment.

[0052] The following describes a method for determining multiple sets of posterior probabilities for electronic devices corresponding to N application types.

[0053] In some embodiments, the electronic device determines multiple sets of posterior probabilities corresponding to N application types based on Bayes' theorem, wherein Bayes' theorem can be expressed as in formula (1).

[0054] , formula (1).

[0055] in, It is the posterior probability; It is conditional probability, also known as likelihood probability; It is the prior probability; This is the marginal probability, usually used as a normalization constant. It is based on the Naive Bayes independence assumption, i.e., each feature x... i Given parameters Y, the x and y are independent, and P(X|Y) = (x1, x2, ..., x...). N |Y)= That is, the above formula (1) can be expressed as: .

[0056] In this embodiment of the application, a set of posterior probabilities corresponding to the application type can be expressed as: For example, a set of posterior probabilities corresponding to the first application type can be expressed as: The set of posterior probabilities corresponding to the second application type can be expressed as: The set of posterior probabilities corresponding to the Nth application type can be expressed as: Taking the preset parameters Y={0.5 cores, 2 cores, 4 cores, 6 cores, 12 cores}, and the application types as compute-intensive, memory-intensive, and I / O-intensive as examples, the posterior probabilities corresponding to compute-intensive applications can be P(0.5 cores|compute-intensive), P(2 cores|compute-intensive), P(4 cores|compute-intensive), P(6 cores|compute-intensive), and P(12 cores|compute-intensive). The posterior probabilities corresponding to memory-intensive applications can be P(0.5 cores|memory-intensive), P(2 cores|memory-intensive), P(4 cores|memory-intensive), P(6 cores|memory-intensive), and P(12 cores|memory-intensive). The posterior probabilities corresponding to I / O-intensive applications can be P(0.5 cores|I / O-intensive), P(2 cores|I / O-intensive), P(4 cores|I / O-intensive), P(6 cores|I / O-intensive), and P(12 cores|I / O-intensive).

[0057] This application's embodiments determine multiple sets of posterior probabilities corresponding to N application types based on conditional probability and prior probability. For example, an electronic device performs... Figure 4 The method shown determines N sets of posterior probabilities, each corresponding to one of the N application types. For example... Figure 4 As shown, the method includes: S401, based on historical parameters of multiple applications, determine M prior probabilities that correspond one-to-one with M preset parameters.

[0058] In this embodiment, the electronic device can obtain M prior probabilities, each corresponding to one of M preset parameters. A prior probability corresponding to a preset parameter indicates the distribution probability of that preset parameter among historical parameters of multiple applications. In other words, the prior probability characterizes the proportion of the corresponding preset parameter among historical parameters of multiple applications. For example, the proportion of each of the M preset parameters among historical parameters is statistically analyzed to obtain the prior probability corresponding to each preset parameter. For instance, the electronic device statistically analyzes the proportion of each preset parameter from historical parameters of multiple applications; this proportion is the prior probability of that preset parameter. The prior probability can reflect the frequency of each preset parameter in actual applications.

[0059] Taking the preset parameters as the maximum usage value Y = {0.5 cores, 2 cores, 4 cores, 6 cores, 12 cores} as an example, the electronic device can obtain the prior probability P(Y) corresponding to these 5 preset parameters one by one. iExamples of preset parameters include P(0.5 cores), P(2 cores), P(4 cores), P(6 cores), and P(12 cores). P(0.5 cores) represents the probability distribution of 0.5 cores actually used in the historical operating parameters of various applications; that is, the proportion of this preset parameter (0.5 cores) in the historical maximum usage limit records of all applications. Similarly, the other prior probabilities, such as P(2 cores) and P(4 cores), correspond to the probability distribution / proportion of their respective preset parameters in the historical parameters.

[0060] S402, determine M sets of conditional probabilities that correspond one-to-one with M preset parameters based on historical parameters of multiple applications.

[0061] Electronic devices determine M sets of conditional probabilities, each corresponding to one of M preset parameters, based on historical parameters from multiple application types. The j-th conditional probability in a set of conditional probabilities corresponding to a preset parameter represents the probability that a Pod's usage of cluster resources is equal to the corresponding preset parameter when running an application of the j-th application type; 1 ≤ j ≤ N. Conditional probability refers to the probability of another event occurring given a certain condition. In this application, conditional probability is used to describe the probability that a Pod's usage of cluster resources is equal to a certain preset parameter under a specific application type.

[0062] Taking the preset parameters as the maximum usage value Y = {0.5 cores, 2 cores, 4 cores, 6 cores, 12 cores} as an example, the electronic device can obtain a set of conditional probabilities P(x) corresponding one-to-one with these 5 preset parameters. i |Y). Taking compute-intensive, memory-intensive, and I / O-intensive application types as examples, a set of conditional probabilities corresponding to 0.5 cores are: P(compute-intensive|0.5 cores), P(memory-intensive|0.5 cores), and P(I / O-intensive|0.5 cores). Here, P(compute-intensive|0.5 cores) represents the probability that a Pod's cluster resource usage (such as maximum or average usage) is 0.5 cores when running the first application type, such as a compute-intensive application. P(memory-intensive|0.5 cores) represents the probability that a Pod's cluster resource usage is 0.5 cores when running the second application type, such as a memory-intensive application. P(I / O-intensive|0.5 cores) represents the probability that a Pod's cluster resource usage is 0.5 cores when running the third application type, such as an I / O-intensive application.

[0063] In some embodiments, for each of the M preset parameters, the probability values ​​of N application types using the preset parameter are statistically analyzed in the historical parameters to obtain a set of conditional probabilities corresponding to each preset parameter.

[0064] For example, for a preset parameter, the electronic device, based on the usage parameters of various applications, sequentially calculates the probability value of the j-th application type using the preset parameter. Taking the preset parameter Y={0.5 cores, 2 cores, 4 cores, 6 cores, 12 cores} as an example, for 0.5 cores, based on the usage parameters of various applications, the electronic device calculates the proportion of compute-intensive applications using 0.5 cores out of the total number of records of all applications using 0.5 cores, obtaining the conditional probability P(compute-intensive|0.5 cores). The electronic device calculates the proportion of memory-intensive applications using 0.5 cores out of the total number of records of all applications using 0.5 cores, obtaining the conditional probability P(memory-intensive|0.5 cores). The electronic device calculates the proportion of I / O-intensive applications using 0.5 cores out of the total number of records of all applications using 0.5 cores, obtaining the conditional probability P(I / O-intensive|0.5 cores). For the other preset parameters such as 2 cores, 4 cores, 6 cores, and 12 cores, the electronic device can perform the same method to determine a set of prior probabilities corresponding to each preset parameter.

[0065] In this embodiment, both conditional probability and prior probability are derived from historical parameter statistics of various applications. There is a logical relationship between conditional probability and prior probability. Prior probability represents the overall distribution of preset parameters, while conditional probability represents the distribution of preset parameters under a specific application type. Posterior probability is a predicted value determined based on prior probability and conditional probability. Its core function is to predict the compatibility probability of using the j-th preset parameter when the application to be deployed belongs to the i-th application type Xi, rather than a direct statistical result of historical data. Posterior probability, through logical integration and probability correction of the above two types of statistical data, achieves prediction of the compatibility between specific application types and preset parameters, providing accurate decision-making basis for resource allocation of the application to be deployed.

[0066] S403, based on M prior probabilities and M conditional probabilities, determine N sets of posterior probabilities corresponding to N application types.

[0067] Posterior probability is the final result calculated based on prior probability and conditional probability. It is used to represent the probability that a preset parameter holds true given the observed data (such as application type).

[0068] In some embodiments, the electronic device can determine N sets of posterior probabilities corresponding to N application types based on formula (1). Specifically, for each application type, N sets of posterior probabilities corresponding to the application type are obtained based on the N conditional probabilities and N prior probabilities corresponding to the application type. For example, continuing with the previous example, P(computationally intensive | 0.5 cores)•P(0.5 cores) / P(computationally intensive) is the posterior probability (0.5 cores | computationally intensive), P(computationally intensive | 2 cores)•P(2 cores) / P(computationally intensive) is the posterior probability (2 cores | computationally intensive), P(computationally intensive | 4 cores)•P(4 cores) / P(computationally intensive) is the posterior probability (4 cores | computationally intensive), P(computationally intensive | 6 cores)•P(6 cores) / P(computationally intensive) is the posterior probability (6 cores | computationally intensive), and P(computationally intensive | 12 cores)•P(12 cores) / P(computationally intensive) is the posterior probability (12 cores | computationally intensive). Here, P(computationally intensive) is the sum of the N conditional probabilities.

[0069] In other embodiments, due to its specific application type The marginal probabilities are consistent, and for a given application type, this application focuses on the maximum posterior probability among a set of posterior probabilities corresponding to that application type. When marginal probabilities are consistent, this value can be ignored. To simplify calculations, improve computational efficiency, and reduce power consumption, this application uses... The posterior probability is represented. In the example, for each application type, the N conditional probabilities and N prior probabilities corresponding to the application type are multiplied together to obtain N sets of posterior probabilities corresponding to the application type.

[0070] Continuing with the example from earlier, we multiply the N conditional probabilities corresponding to compute-intensive applications, such as P(compute-intensive|0.5 cores), P(compute-intensive|2 cores), P(compute-intensive|4 cores), P(compute-intensive|6 cores), and P(compute-intensive|12 cores), along with their corresponding N conditional probabilities, to obtain a set of posterior probabilities corresponding to compute-intensive applications. For example, we use P(compute-intensive|0.5 cores)•P(0.5 cores) to represent the posterior probability (0.5 cores|compute-intensive), P(compute-intensive|2 cores)•P(2 cores) to represent the posterior probability (2 cores|compute-intensive), P(compute-intensive|4 cores)•P(4 cores) to represent the posterior probability (4 cores|compute-intensive), P(compute-intensive|6 cores)•P(6 cores) to represent the posterior probability (6 cores|compute-intensive), and P(compute-intensive|12 cores)•P(12 cores) to represent the posterior probability (12 cores|compute-intensive).

[0071] The above embodiments are illustrated using one application type as an example. It should be understood that the above method can be performed for each application type to obtain a set of posterior probabilities corresponding to an application type.

[0072] Combined with the preceding text Figure 4 This paper introduces a method for determining N sets of posterior probabilities corresponding to N application types. In some embodiments, after determining the N sets of posterior probabilities corresponding to the N application types, the electronic device can determine the configuration parameters corresponding to that application type, i.e., the configuration parameters of the POD running this type of application, for each application type. The electronic device can store the configuration parameters corresponding to each application type in a preset location. When developers have deployment needs, the target Pod is deployed in the cluster based on the application to be deployed and the first configuration file.

[0073] The first configuration file is a structured configuration file (such as YAML / JSON format) related to application resource scheduling. It contains at least one target field, including fields such as `request` and `limit`. The `request` field can include fields like `resources requests cpu` and `resources requests memory`. The `limit` field can include fields like `resources limits cpu` and `resources limits memory`. The `request` field corresponds to the average usage value in the configuration parameters, and the `limit` field corresponds to the maximum usage value in the configuration parameters. In other words, the target fields in the first configuration file are the configuration parameters for the target Pod.

[0074] In some embodiments, the electronic device submits a first configuration file to the cluster. The cluster, such as a scheduler, automatically schedules and creates the target Pod based on the first configuration file and initiates the lifecycle of the target Pod. For example, the scheduler selects a suitable node to create and run the target Pod according to the resource requirements specified in the first configuration file. Figure 5 This demonstrates the method for deploying the application in a cluster.

[0075] Figure 5In the first configuration file 510, the `resourceslimits cpu` field has a value of 1 core, and the `resourceslimits cpu memory` field has a value of 500Mi; the `resources requests cpu` field has a value of 0.5 cores, and the `resources requests memory` field has a value of 250Mi. The electronic device submits the first configuration file to the service interface 520 (API Server) in the cluster. The API Server verifies the configuration format and submits the first configuration file to the controller manager 530. The controller manager stores the first configuration file in the etcd database 550. The scheduler 540 monitors the cluster resource usage and, based on the node's resource status (such as remaining CPU / memory), selects appropriate nodes (as shown in the lower part of the diagram) to determine the Pod's running location. The kubelet component on the node (not shown in the diagram) receives the scheduling instructions, pulls the image specified in the first configuration file (such as nginx), creates and runs the Pod container, and finally completes the application deployment.

[0076] The following describes a method for configuring resources provided by an embodiment of this application, using a specific scenario as an example.

[0077] To address the increasingly complex mobile internet application scenarios and rising application demands, traditional monolithic architectures can no longer meet user needs for processing application data. Distributed systems have emerged, breaking down complex business requirements into multiple relatively independent services deployed on different service resources. However, the execution environment of programs on the same server is not isolated, making it difficult to allocate computing resources rationally. Virtualization technology has emerged to address this need. Virtualization technology has completely broken down the insurmountable barriers of server physical structure. Users can configure computing resources according to actual application needs. Containerization technology, derived from virtualization, is more adapted to actual user needs. It can break down complex business processes into independent, simple business processes, each with its own network, storage, etc. The increasing number of containers has brought challenges to container management. Containerization technology only encapsulates and deploys a single, minimal environment and manages its own lifecycle, but lacks a unified management tool for servers and all containers on server clusters. Kubernetes manages containers on server clusters, enabling server load balancing, version rollback, container self-healing, elastic scaling, and other functions. Kubernetes enables users to customize resource scheduling policies and achieve rich orchestration capabilities. Since its launch, Kubernetes has been recognized by the industry and has become one of the most widely used container orchestration systems.

[0078] In a Kubernetes cluster, the Pod is the basic unit of resource scheduling. However, traditional Pod resource allocation methods are often based on static resource configurations and cannot be dynamically adjusted according to the actual running status of the Pod, resulting in serious waste of resources. Therefore, developing a method that can dynamically predict Pod resource requirements is of great practical significance.

[0079] Related technology 1 proposes a set of methods for acquiring load change data of Pods in container clusters; and establishes a container cloud scaling model based on dynamic thresholds for Pod load change data, which can improve the response speed and service quality of container cloud resources.

[0080] Related technology 2 proposes a hybrid elastic scaling method for container clouds based on resource demand prediction. This method constructs a historical resource usage dataset through cloud application resource operation monitoring and designs a novel deep learning model employing multiple convolutional kernels and two-sequence information interaction to accurately predict dynamically changing multi-time-period resource demands.

[0081] Related technology 3 proposes a container resource scheduling method, which proposes a method to reasonably allocate the application to be deployed to the nodes in the cluster. The main innovation lies in the scheduling strategy of all nodes in the cluster, which can save network transmission time and improve efficiency.

[0082] None of the aforementioned technologies predict or make decisions regarding the resources required by the application from a demand perspective. If the initial resource request data differs significantly from the actual data, it will also lead to resource waste.

[0083] Automotive companies employ a wide variety of complex applications, each with vastly different resource requirements when deployed in container environments. Using a unified YAML library for these diverse applications can lead to resource waste and contention. When resource contention exceeds the host machine's maximum capacity, Pods may be evicted or even destroyed. To better utilize server resources and ensure stable operation of all applications across the cluster, a thorough analysis of the application is necessary before Pod startup to determine the appropriate resource request limits and constraints.

[0084] This invention proposes a Kubernetes Pod resource decision-making method based on statistical theory, as exemplified by, for example... Figure 6 As shown, the method includes the following steps: S601: Data collection and storage.

[0085] Collect historical resource usage data for Pods running various types of applications. This data includes the actual usage and duration of resources such as CPU, memory, disk, and I / O. It also collects the current resource status of the cluster, including the total resources, allocated resources, and idle resources on each node. Extract features related to Pod resource requirements from the collected data, such as Pod type, runtime, and historical resource usage. Store the collected historical resource usage data in a database. For example, use Grafana to monitor the historical resource usage data of different application types throughout their lifecycle, periodically fetching data and storing it in the database.

[0086] S602: Generate usage parameters for various applications.

[0087] Customized filters analyze collected historical resource usage data to calculate the maximum and average usage of different resources for different applications, and form training sets according to application types to facilitate subsequent resource decisions. The training sets include an application type set X and a historical parameter set D. X = {x1, x2, ..., x...} N}, where x j It is the j-th application type out of N application types, where 1 ≤ j ≤ N. D = {d1, d2, ..., d...} T}, where d k It is the historical parameter set D of multiple applications, where 1 ≤ k ≤ T, and T is a positive integer. That is, the historical parameter set D includes multiple records that correspond one-to-one with multiple applications of various types, and one record corresponding to each application is used to record the historical parameters of that application.

[0088] S603: Predicts the configuration parameters of a target pod based on various types of historical parameters.

[0089] For example, using Bayes' theorem as the basic statistical theory of this invention, statistical calculations are performed on the collected historical parameters, which will serve as input parameters for Bayes' theorem. A Pod resource demand prediction model is constructed using Bayes' theorem. This model takes the application type corresponding to the target Pod as input and, based on the historical parameter set D, outputs the predicted resource demand of the target Pod over a future period. This model can, for example, achieve... Figure 1 The methods shown in S102 and S103 are illustrated.

[0090] In some embodiments, in multi-objective scenarios, such as dual-objective scenarios, where it is necessary to simultaneously determine the maximum usage value (corresponding to the `limit` field) and the average usage value (corresponding to the `request` field) of the application to be deployed, the electronic device can obtain two sets of posterior probabilities corresponding to the application to be deployed. For example, the electronic device can independently obtain a set of posterior probabilities for each of the two configuration dimensions. Specifically, the first set of posterior probabilities (maximum usage value dimension): The preset parameter set is configured as a set of preset maximum usage values, such as Y={0.5 cores, 2 cores, 4 cores, 6 cores, 12 cores}. Using the Bayesian probability calculation method described above (statistically calculating the prior probability and likelihood probability under this dimension, and deriving the posterior probability), a set of posterior probabilities for the application to be deployed in the maximum usage value dimension is obtained. The second set of posterior probabilities (average usage dimension): The preset parameter set is configured as a set of preset average usage values, such as Y={0.1 cores, 1.0 cores, 2.0 cores, 4.0 cores, 8.0 cores}. Using the same Bayesian probability calculation method as described above, another set of posterior probabilities for the application to be deployed in the average usage dimension is obtained. Electronic devices can then select the optimal maximum usage value and the optimal average usage value for the application to be deployed based on the maximum value in each set of posterior probabilities, achieving precise resource allocation in a dual-objective dimension.

[0091] In some embodiments, historical data can be used to train and validate the model during the model building process to improve the accuracy of predictions.

[0092] S604: Deploy the target pod in the cluster.

[0093] After obtaining the configuration parameters of the target pod, the electronic device can also dynamically allocate resources to the target pod based on the predicted resource requirements of the target pod and the current resource status of the cluster. When cluster resources are sufficient, the resource allocation of the pod can be appropriately increased to meet its performance requirements; when cluster resources are scarce, the resource allocation of the pod can be appropriately reduced to save resources.

[0094] In some embodiments, the first step in orchestrating with Kubernetes is creating a minimal deployment unit (such as a target Pod). Before creating a Pod, a Pod description file needs to be written and stored in etcd. etcd is a highly available key-value store used to store all configuration information for the cluster. etcd plays a crucial role in Kubernetes, acting as the "brain" or "data center" of the Kubernetes cluster. etcd stores all metadata and configuration information of the Kubernetes cluster, including the definitions and states of resources such as Pods, Services, Deployments, ReplicaSets, DaemonSets, and Nodes. Typically, a YAML file is created and submitted to the cluster using the Kubernetes API to begin the Pod's lifecycle. The YAML uses different keywords to specify the source information of the Pod being started, including resource data, dependent images, mount information, and cluster node selectors. The resources field specifies the CPU and memory resources required by the container, as well as the maximum resource limits that can be used. This is crucial for ensuring the stable operation of the Pod, avoiding resource contention, and performing effective resource scheduling. The resources field typically contains two fields: limits and requests. The `requests` field represents the amount of resources the scheduler should consider when allocating nodes to a pod. If there are not enough resources in the cluster to satisfy a pod's requests, the pod must wait until sufficient resources become available before it can be scheduled. The `limits` field defines the maximum amount of resources a container can use, which can limit the amount of CPU and memory resources that a started pod can arbitrarily consume.

[0095] The control method embodiments of this application have been described in detail above with reference to the accompanying drawings. The device embodiments of this application will now be described in detail with reference to the accompanying drawings. It should be understood that the description of the device embodiments corresponds to the method embodiments; therefore, any parts not described in detail can be referred to the control method embodiments described above.

[0096] Figure 7 This is a schematic diagram of the structure of a resource configuration device provided in an embodiment of this application, as shown below. Figure 7 As shown, the device 700 for configuring resources may include an acquisition unit 710, a first determination unit 720, and a second determination unit 730.

[0097] The acquisition unit 710 is used to acquire historical parameters of various applications deployed in the cluster; wherein, the historical parameters are used to indicate the historical usage of cluster resources by the Pod running the corresponding application; The first determining unit 720 is used to determine N sets of posterior probabilities corresponding one-to-one with N application types based on historical parameters of multiple application types; wherein, a set of posterior probabilities corresponding to an application type includes M posterior probabilities corresponding one-to-one with M preset parameters, wherein the i-th posterior probability is used to characterize the degree of fit between the corresponding application type and the i-th preset parameter; 1≤i≤M; M and N are both positive integers; The second determining unit 730 is used to determine the configuration parameters of the target Pod based on the maximum posterior probability among the set of posterior probabilities corresponding to the application type of the application to be deployed in N sets of posterior probabilities; wherein, the target Pod is used to provide a running environment for the application to be deployed in the cluster.

[0098] The second determining unit 730 is further configured to determine the maximum posterior probability among the set of posterior probabilities corresponding to the application type of the application to be deployed in the N sets of posterior probabilities; and to use the preset parameter corresponding to the maximum posterior probability as the configuration parameter of the target Pod.

[0099] The first determining unit 720 is further configured to determine M prior probabilities corresponding one-to-one with M preset parameters based on historical parameters of multiple application types; wherein the prior probabilities are used to indicate the distribution probability of the corresponding preset parameter in the historical parameters of multiple application types; determine M sets of conditional probabilities corresponding one-to-one with the M preset parameters based on the historical parameters of multiple application types; wherein a set of conditional probabilities corresponding to a preset parameter includes N conditional probabilities corresponding one-to-one with N application types, wherein the j-th conditional probability is used to characterize the probability that the Pod uses cluster resources at the value corresponding to the preset parameter when running an application of the j-th application type; 1≤j≤N; and determine N sets of posterior probabilities corresponding to the N application types based on the M prior probabilities and the M sets of conditional probabilities.

[0100] The first determining unit 720 is also used to calculate the proportion of each preset parameter among the M preset parameters in the historical parameters, and obtain the prior probability corresponding to each preset parameter; for each preset parameter among the M preset parameters, the probability value of the application of the N application types in the historical parameters using the preset parameter is calculated, and a set of conditional probabilities corresponding to each preset parameter is obtained.

[0101] The first determining unit 720 is also used to obtain N sets of posterior probabilities corresponding to each application type, based on the N conditional probabilities and N prior probabilities corresponding to the application type.

[0102] The acquisition unit 710 is also used to periodically collect historical usage data of cluster resources from multiple Pods running in the cluster that provide runtime environments for various types of applications; and to obtain historical parameters of various types of applications deployed in the cluster based on the historical usage data.

[0103] The device for configuring resources may also include a deployment unit for deploying a target Pod in the cluster based on a first configuration file of the Pod; the target field in the first configuration file is the configuration parameters of the target Pod.

[0104] Figure 8 This is a schematic diagram of the structure of a device for configuring resources according to an embodiment of this application. The device 800 for configuring resources includes one or more processors 810 and one or more memories 820.

[0105] The processor 810 can support the control device in implementing the methods described in the preceding method embodiments.

[0106] The memory 820 stores a program that can be executed by the processor 810, causing the processor 810 to perform the methods described in the preceding method embodiments. The memory 820 can be independent of the processor 810 or integrated into the processor 810.

[0107] Optionally, the vehicle 800 may also include a transceiver 830. The processor 810 can communicate with other devices or chips via the transceiver 830. For example, the processor 810 can send and receive data with other devices or chips via the transceiver 830.

[0108] This application provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the steps of the methods described in any of the above embodiments.

[0109] It should be noted that the descriptions of the computer-readable storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the computer-readable storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0110] The aforementioned processor can be at least one of the following: application-specific integrated circuit (ASIC), digital signal processor (DSP), digital signal processing device (DSPD), programmable logic device (PLD), field-programmable gate array (FPGA), central processing unit (CPU), controller, microcontroller, and microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0111] The aforementioned computer-readable storage medium / memory can be a read-only memory, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a ferromagnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD ROM), etc.

[0112] This application provides a computer program including computer-readable code. When the computer-readable code runs in an electronic device, the processor in the electronic device executes some or all of the steps in the above-described method.

[0113] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer-readable storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0114] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0115] It should be noted that, in this document, 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. Unless otherwise specified, 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 that element.

[0116] In the several embodiments provided in this application, it should be understood that the disclosed 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, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0117] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0119] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0120] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence or the part that contributes to related technologies, 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 an in-vehicle terminal (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0121] The above are merely 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.

[0122] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A method for configuring resources, characterized in that, The method includes: Obtain historical parameters of various applications deployed in the cluster; wherein, the historical parameters are used to indicate the historical usage of cluster resources by the Pods running the corresponding applications; Based on the historical parameters of the various applications, N sets of posterior probabilities are determined, each corresponding to one of the N application types. Each set of posterior probabilities corresponding to one application type includes M posterior probabilities corresponding to one of M preset parameters. The i-th posterior probability is used to characterize the degree of fit between the corresponding application type and the i-th preset parameter. 1≤i≤M; M and N are both positive integers. The configuration parameters of the target Pod are determined based on the maximum posterior probability among the N sets of posterior probabilities corresponding to the application type of the application to be deployed; wherein the target Pod is used to provide a runtime environment for the application to be deployed in the cluster.

2. The method according to claim 1, characterized in that, The configuration parameters of the target Pod are determined based on the maximum posterior probability among the N sets of posterior probabilities corresponding to the application type of the application to be deployed, including: Determine the maximum posterior probability among the set of posterior probabilities that corresponds to the application type of the application to be deployed from the N sets of posterior probabilities; The preset parameters corresponding to the maximum posterior probability are used as the configuration parameters of the target Pod.

3. The method according to claim 1 or 2, characterized in that, The determination of multiple sets of posterior probabilities corresponding to N application types based on historical parameters of the multiple application types includes: Based on the historical parameters of the various applications, M prior probabilities are determined that correspond one-to-one with the M preset parameters; wherein, the prior probabilities are used to indicate the distribution probability of the corresponding preset parameters in the historical parameters of the various applications. Based on the historical parameters of the various application types, M sets of conditional probabilities are determined, each corresponding to one of the M preset parameters. Each set of conditional probabilities corresponding to a preset parameter includes N conditional probabilities corresponding to one of the N application types. The j-th conditional probability is used to characterize the probability that when running an application of the j-th application type, the Pod's usage of cluster resources is the corresponding preset parameter; 1≤j≤N. Based on the M prior probabilities and the M conditional probabilities, determine the N posterior probabilities corresponding to the N application types.

4. The method according to claim 3, characterized in that, The step of determining M prior probabilities corresponding one-to-one with the M preset parameters based on the historical parameters of the multiple applications includes: calculating the proportion of each preset parameter in the historical parameters to obtain the prior probability corresponding to each preset parameter. Determining M sets of conditional probabilities corresponding one-to-one with the M preset parameters based on the historical parameters of the multiple application types includes: for each preset parameter among the M preset parameters, calculating the probability values ​​of N application types using the preset parameter in the historical parameters, and obtaining a set of conditional probabilities corresponding to each preset parameter.

5. The method according to claim 3, characterized in that, The step of determining N sets of posterior probabilities corresponding to N application types based on the M prior probabilities and the M sets of conditional probabilities includes: For each application type, based on the N conditional probabilities and the N prior probabilities corresponding to the application type, N sets of posterior probabilities corresponding to the application type are obtained.

6. The method according to any one of claims 1-5, characterized in that, Before obtaining historical parameters of multiple types of applications deployed in the cluster, the method further includes: Historical usage data of cluster resources by multiple Pods running in the cluster that provide the runtime environment for the various types of applications are periodically collected. Based on the historical usage data, historical parameters of various applications deployed in the cluster are obtained.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Based on the first configuration file of the Pod, the target Pod is deployed in the cluster; the target field in the first configuration file is the configuration parameter of the target Pod.

8. An apparatus for allocating resources, characterized in that, include: The acquisition unit is used to acquire historical parameters of various applications deployed in the cluster; wherein, the historical parameters are used to indicate the historical usage of cluster resources by the Pods running the corresponding applications; The first determining unit is used to determine N sets of posterior probabilities corresponding one-to-one with N application types based on the historical parameters of the multiple application types; wherein, a set of posterior probabilities corresponding to an application type includes M posterior probabilities corresponding one-to-one with M preset parameters, wherein the i-th posterior probability is used to characterize the degree of fit between the corresponding application type and the i-th preset parameter; 1≤i≤M; M and N are both positive integers; The second determining unit is used to determine the configuration parameters of the target Pod based on the maximum posterior probability among the set of posterior probabilities corresponding to the application type of the application to be deployed in the N sets of posterior probabilities; wherein the target Pod is used to provide a running environment for the application to be deployed in the cluster.

9. A device for configuring resources, characterized in that, include: One or more processors; A memory for storing one or more programs that, when executed by one or more processors, cause the device to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the computer's processor, causes the computer to perform the method according to any one of claims 1 to 7.

Images