Container resource demand quantity determination method and device

Abstract

The embodiment of the invention provides a container resource demand quantity determination method and device, and is applied to the technical field of cloud native. The method comprises the following steps: acquiring historical load data of the container arrangement system before a target moment, and determining a target utilization rate of the container arrangement system according to the historical load data; wherein the target utilization rate is an expected resource utilization rate of the container arrangement system in a time period after the target moment, and the target utilization rate is determined by a periodic prediction value and a short-term correction value of the container arrangement system; the periodic predicted value is a resource expected utilization rate determined based on a periodic load characteristic and a long-term load characteristic of historical load data; the short-term correction value is the resource expected utilization rate determined based on the short-term load characteristic of the historical load data. And finally, according to the target utilization rate, determining the container resource demand of the container arrangement system. The container resource demand quantity determined by the method has relatively high precision, and is more in line with the actual container resource demand quantity.

Description

Technical Field

[0001] This application relates to the field of cloud-native technology, and in particular to a method and apparatus for determining container resource requirements. Background Technology

[0002] Container resources are the foundation for the stable operation of container instances in a container orchestration system. These resources include compute, storage, and network resources. Properly configuring container resources is crucial for ensuring the stable operation of containerized services and improving cluster resource utilization within a container orchestration system. The prerequisite for proper container resource configuration is accurate prediction of future container resource demands.

[0003] Currently, a single time scale is often used to determine the container resource demand for future periods. Specifically, this is based on hourly or daily historical load data. Historical load data refers to load data up to the current time, and the future period is the time period after the current time. However, this method of determining container resources often results in a significant discrepancy between the actual resources required in the future. Summary of the Invention

[0004] This application provides a method and apparatus for determining container resource requirements, which can improve the prediction accuracy of container resources.

[0005] In a first aspect, embodiments of this application provide a method for determining container resource requirements, the method comprising:

[0006] Obtain historical load data from the container orchestration system up to the target time.

[0007] Determine the target utilization rate of the container orchestration system based on historical load data;

[0008] The target utilization rate is the expected resource utilization rate of the container orchestration system during a target time period, which is the period after the target time. The target utilization rate is determined by the periodic forecast value and the short-term correction value of the container orchestration system. The periodic forecast value is the expected resource utilization rate determined based on the periodic load characteristics and long-term load characteristics of historical load data. The short-term correction value is the expected resource utilization rate determined based on the short-term load characteristics of historical load data.

[0009] Based on the target utilization rate, determine the container resource requirements of the container orchestration system during the target time period.

[0010] Optionally, the method for determining the periodic forecast value includes:

[0011] Based on the long-term load characteristics of historical load data, the current baseline forecast value is determined; the current baseline forecast value is the expected resource utilization rate for the target period, which is determined based on the long-term load characteristics of historical load data.

[0012] Based on the current baseline forecast value and the composite periodicity factor, the periodic forecast value is determined; the composite periodicity factor is related to the first load feature and the second load feature of the historical load data; the first load feature is the historical load feature of the first time scale, the second load feature is the historical load feature of the second time scale, and the first time scale is smaller than the second time scale.

[0013] Optionally, the methods for determining the composite periodic factor include:

[0014] Obtain the first and second factors;

[0015] The first factor is a historical average factor obtained by calculating the average value of historical load data at corresponding times within the first time period based on a first time scale; the second factor is a historical average factor obtained by calculating the average value of historical load data at corresponding times within the first time period based on a second time scale.

[0016] A composite periodic factor is determined based on the first factor and the second factor; the composite periodic factor is a number between the first factor and the second factor.

[0017] Optionally, the composite periodic factor is the sum of the product of the first parameter and the first factor, and the product of the second parameter and the second factor;

[0018] The first parameter and the second parameter are both numbers greater than 0 and less than 1, and the sum of the first parameter and the second parameter is 1.

[0019] Optionally, based on the long-term load characteristics of historical load data, the current baseline forecast value is determined, including:

[0020] Determine the segment aggregated observation value of historical load data at the target time; the segment aggregated observation value is correlated with the average value of historical load data for a first time length prior to the target time;

[0021] The current baseline forecast value is determined based on the aggregated observation values ​​and historical baseline forecast values; the historical baseline forecast value is the expected resource utilization rate determined at a time prior to the target time.

[0022] Optionally, the current baseline forecast is the sum of the product of the third parameter and the segment aggregated observation, and the product of the fourth parameter and the historical baseline forecast.

[0023] The third and fourth parameters are both numbers greater than 0 and less than 1, and the sum of the third and fourth parameters is 1.

[0024] Optionally, methods for determining short-term correction values ​​include:

[0025] The historical load data was processed using the Autoregressive Integrated Moving Average (ARIMA) time series analysis algorithm to determine short-term correction values.

[0026] Optionally, based on historical load data, the container resource requirements of the container orchestration system are determined, including:

[0027] Based on the historical load data, determine the periodic forecast value and the short-term correction value;

[0028] The container resource requirement is determined by the sum of the product of the periodic forecast value and the product of the fifth parameter and the short-term correction value; the fifth parameter is a number greater than 0 and less than 1.

[0029] Optionally, historical load data includes indicator data corresponding to business performance metrics and indicator data corresponding to resource load metrics of the smallest scheduling unit in the container orchestration system.

[0030] Business performance metrics are used to characterize the operational status of services in a container orchestration system, while resource load metrics are used to characterize the resource usage of the smallest scheduling unit.

[0031] Secondly, embodiments of this application provide a device for determining container resource requirements, the device comprising:

[0032] The acquisition unit is used to acquire historical load data of the container orchestration system up to the target time.

[0033] The first determining unit determines the target utilization rate of the container orchestration system based on historical load data;

[0034] The target utilization rate is the expected resource utilization rate of the container orchestration system during a target time period, which is the period after the target time. The target utilization rate is determined by the periodic forecast value and the short-term correction value of the container orchestration system. The periodic forecast value is the expected resource utilization rate determined based on the periodic load characteristics and long-term load characteristics of historical load data. The short-term correction value is the expected resource utilization rate determined based on the short-term load characteristics of historical load data.

[0035] The second determining unit determines the container resource requirement of the container orchestration system during the target time period based on the target utilization rate.

[0036] Thirdly, embodiments of this application provide an electronic device, including:

[0037] Memory, used to store computer programs;

[0038] A processor is used to execute computer programs to implement the methods described in any of the first aspects.

[0039] Fourthly, embodiments of this application provide a computer program that, when run on a computer, causes the computer to perform the method in any of the possible implementations of any of the above aspects.

[0040] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program (also referred to as code or instructions) that, when run on a computer, causes the computer to perform the method in any of the possible implementations of any of the above aspects.

[0041] Sixthly, embodiments of this application provide a chip system including one or more processors for calling and executing instructions stored in memory, causing the methods in any of the above aspects or possible implementations to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0042] This application provides a method and apparatus for determining container resource requirements. The method includes: acquiring historical load data of a container orchestration system before a target time; and determining a target utilization rate of the container orchestration system based on the historical load data. The target utilization rate is determined by the expected resource utilization rate of the container orchestration system after the target time, along with the periodic forecast value and short-term correction value of the container orchestration system. The periodic forecast value is the expected resource utilization rate determined based on the periodic and long-term load characteristics of the historical load data; the short-term correction value is the expected resource utilization rate determined based on the short-term load characteristics of the historical load data. Based on the target utilization rate, the container resource requirements of the container orchestration system can be determined. This method, by comprehensively considering the periodic, long-term, and short-term load characteristics of the historical load data, determines the container resource requirements with higher accuracy and a closer match to actual container resource requirements compared to determining requirements based on a single time scale. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a schematic diagram of the structure of a determining device provided in an embodiment of this application;

[0045] Figure 2 A flowchart illustrating a method for determining container resource requirements provided in this application embodiment;

[0046] Figure 3 A flowchart illustrating a method for determining a target utilization rate, as provided in this application embodiment;

[0047] Figure 4 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0048] To enable those skilled in the art to better understand the present application, the technical solutions in this embodiment will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0049] First, the technical terms involved in the embodiments of this application will be explained.

[0050] A container orchestration system is a core technology platform for the entire lifecycle of large-scale container clusters. It manages the entire lifecycle of all container resources, including but not limited to container resource scheduling, orchestration, and lifecycle management. This system enables containerized applications (hereinafter referred to as "applications") to run efficiently, stably, and scalably in a distributed cluster environment. Container orchestration systems include, but are not limited to, Kubernetes, Mesos+Marathon, etc. For ease of explanation, the following description uses Kubernetes as an example.

[0051] Container resources refer to the collective term for all kinds of hardware and logical resources required to support the stable operation of container instances in a container orchestration system. They are the core objects of containerized business deployment, scheduling, and resource allocation. Container resources include, but are not limited to, the computing resources, storage resources, and network resources of the container orchestration system.

[0052] In container orchestration systems, the rationality of container resource configuration directly affects the stability of business operations and the utilization rate of cluster resources. Configuring container resources refers to allocating specific resource scales to services.

[0053] The prerequisite for rationally allocating container resources is to accurately predict the demand for container resources in future time periods.

[0054] Currently, a single time scale is often used to determine container resource requirements. Specifically, this involves determining future container resource requirements based on hourly or daily historical load data. Historical load data refers to load data prior to the current moment. However, this method often results in a significant discrepancy between the determined container resource requirements and the actual future container resource requirements.

[0055] For example, consider a container orchestration system for an e-commerce platform. Its workload exhibits both daily fluctuations and weekly variations. Specifically, peak access times are 9:00-11:00 and 14:00-16:00 on weekdays (Monday to Friday), with CPU utilization at 70%. On weekends (Saturday and Sunday), peak access extends to 10:00-20:00, but during this peak period, CPU utilization is significantly lower than weekday peak times, at only 55%. Short-term response data indicates sudden traffic spikes during marketing campaigns. If we predict container resources at 15:00 next Saturday, based on hourly historical load data for a preset time period (e.g., the past 7 days), we can identify the two daily peaks and determine the CPU utilization to be 70%. Thus, based on the available CPU resources of the node hosting the container service, the required container resources can be determined. For example, if the node has 8 available CPU cores, the required container resources are 9 cores. However, relying solely on hourly historical load data cannot identify the weekly characteristic of lower and longer peak loads on weekends, nor can it identify the short-term characteristic of sudden traffic spikes during marketing campaigns. This results in a significant discrepancy between the determined container resource requirements and the actual resource requirements.

[0056] In view of this, embodiments of this application provide a method for determining container resource requirements, which can be applied to a device for determining container resource requirements. This device may include a software system, which can be independent prediction software or a prediction component integrated into other software systems such as cloud computing platforms, DevOps platforms, etc., in the form of plug-ins, functional modules, services, or microservices. The aforementioned software system can be provided to users as a software package, which users can deploy themselves in a private cluster or hybrid cloud environment; alternatively, the software system can be provided to users as a cloud service, which users can subscribe to and directly use the corresponding container resource prediction capabilities to implement the method for determining container resource requirements of this application. In some possible implementations, the container orchestration system may include a hardware system, which may include a cluster of computing devices (such as a container cluster node composed of multiple physical machines / virtual machines) capable of determining container resources. When the computing device cluster runs, it executes the method for determining container resource requirements of this application.

[0057] Specifically, the device can acquire historical load data of the container orchestration system up to the target time. Then, based on the historical load data, the target utilization rate of the container orchestration system is determined. The target utilization rate is the expected resource utilization rate for the target time period determined by the container orchestration system, which is located after the target time. The target utilization rate is determined by the periodic forecast and short-term correction values ​​of the container orchestration system. The periodic forecast is the expected resource utilization rate determined based on the periodic and long-term load characteristics of the historical load data; the short-term correction is the expected resource utilization rate determined based on the short-term load characteristics of the historical load data. Based on this target utilization rate, the container resource demand for the target time period can be determined. Compared to determining container resource demand based solely on hourly or daily historical load data at a single time scale, this method comprehensively considers the periodic, long-term, and short-term load characteristics of the historical load data. It combines the periodic forecast, which reflects the inherent cyclical patterns and long-term trends of the business, with the short-term correction value, which adapts to short-term sudden fluctuations. This allows the container resource demand to comprehensively and accurately reflect the actual resource demand at the target time, thereby improving the accuracy of container resource demand determination.

[0058] To make the technical solution of this application clearer and easier to understand, the system architecture of the determining device of this application will be described below with reference to the accompanying drawings.

[0059] See Figure 1 The diagram shows a structural schematic of a determining device 10, which is built on a cloud-native technology stack and connected to a container orchestration system 20. The determining device 10 is used to determine the container resource requirements of the container orchestration system 20 during a target time period. The container orchestration system 20 can then be configured based on these container resource requirements.

[0060] The determining device 10 includes an acquisition unit 101 and a determining unit 102. The determining device 10 acquires historical load data of the container orchestration system 20 up to the target time using the acquisition unit 101. Then, based on the historical load data, the determining unit 102 determines the target utilization rate of the container orchestration system. Finally, based on the target utilization rate, the determining device 10, through a second determining unit 103, determines the container resource requirements of the container orchestration system.

[0061] Specifically, the acquisition unit 101 is used to acquire historical load data of the container orchestration system 20 before the target time. The first determining unit 102 is used to determine the target utilization rate of the container orchestration system 20 based on the historical load data. The target utilization rate is the expected resource utilization rate of the container orchestration system 20 during the target time period, determined by the periodic forecast value and short-term correction value of the container orchestration system 20; wherein the periodic forecast value is the expected resource utilization rate determined based on the periodic load characteristics and long-term load characteristics of the historical load data; and the short-term correction value is the expected resource utilization rate determined based on the short-term load characteristics of the historical load data. The third determining unit 103 is used to determine the container resource requirements of the container orchestration system based on the target utilization rate.

[0062] based on Figure 1 The present application also provides a method for determining container resource requirements, in addition to the determining device 10 shown. The method for determining container resource requirements will be described in detail below with reference to the accompanying drawings.

[0063] Appendix Figure 2 A flowchart illustrating a method for determining container resource requirements provided in this application embodiment, the method comprising the following:

[0064] S10, determining device 10 acquires historical load data of container orchestration system before the target time.

[0065] The target time can be the current time.

[0066] Historical load data refers to load data up to the time preceding the target time. In specific implementations, historical load data can include at least one of the following: metric data corresponding to business performance indicators and metric data corresponding to resource load indicators of the minimum scheduling unit.

[0067] Among them, business performance metrics are used to characterize the operational status of the business, including but not limited to Queries Per Second (QPS), response time, and error rate. Resource load metrics of the smallest scheduling unit (i.e., Pod) indicate the resource consumption at the Pod level, including but not limited to Pod-level CPU utilization, memory utilization, and network I / O.

[0068] In this embodiment of the application, in order to determine the container resource requirements of the container orchestration system after the target time, the determining device 10 first acquires historical load data.

[0069] In some examples, acquisition unit 101 uses Prometheus as the metrics acquisition engine and collects historical load data through Prometheus Service Monitor. For example, determination device 10 uses Prometheus Service Monitor to collect CPU usage data of the container orchestration system for the most recent 60 days at preset intervals (e.g., 15 seconds).

[0070] In some examples, the acquisition unit 101 also includes a storage module for storing historical load data. For example, the storage module uses InfluxDB as the data storage engine to store historical load data.

[0071] S20, the determining device 10 determines the target utilization rate based on historical load data.

[0072] Specifically, target utilization refers to the expected usage of container resources by business workloads during a target time period. For example, target utilization can be CPU utilization, memory utilization, etc.

[0073] In this embodiment, the target utilization rate is determined by the periodic forecast value and short-term correction value of the container orchestration system; the periodic forecast value is the expected resource utilization rate determined based on the periodic load characteristics and long-term load characteristics of historical load data; the short-term correction value is the expected resource utilization rate determined based on the short-term load characteristics of historical load data.

[0074] In this embodiment of the application, the determining device 10 can determine the target utilization rate based on historical load data. Specifically, the determining device 10 can determine the target utilization rate based on the long-term load characteristics, short-term load characteristics, and periodic load characteristics of historical load data.

[0075] For example, an e-commerce platform has a stable daily business load with a clear cyclical pattern, but it occasionally launches temporary promotional activities that cause short-term traffic surges. The container orchestration system needs to determine resources in advance to avoid lag or resource idleness during major promotional events. The target time is 18:00 on November 10th, and it's necessary to determine the CPU utilization for the time period after the target time, specifically from 18:00 on November 10th to 24:00 on November 11th, during this major promotional period.

[0076] Device 10 first acquired historical load data from the past six months. Analysis of this data revealed a periodicity: a typical promotional peak occurred between 8 PM on the 10th and 2 AM on the 11th of each month, with CPU utilization averaging 75%. The long-term characteristic of this historical load data was a 5% month-on-month increase in CPU utilization over the past three months, coinciding with user growth. Based on these two characteristics, the determined periodic forecast value was 85%.

[0077] Based on historical load data from one hour prior to the target time, device 10 determines its short-term load characteristics as follows: the platform suddenly pushed out a large no-threshold coupon, resulting in a 30% surge in visits within 10 minutes and a short-term increase in CPU utilization to 60%. Combining this short-term sudden fluctuation, a short-term correction value can be determined, which is then used to correct the periodic forecast value.

[0078] For example, let's assume the short-term correction value equals the sum of the CPU usage fluctuation ratio and the preset behavior coefficient. Here, the CPU usage fluctuation ratio equals the traffic fluctuation ratio multiplied by the preset ratio. The preset ratio is a number that is adjusted as needed and is greater than 0 and less than 1; for example, the preset ratio is 0.35. In the example above, if traffic surges by 30% within 10 minutes (i.e., the traffic fluctuation ratio is 30%), the CPU usage fluctuation ratio would be 30% × 0.35 = 10.5%. The preset behavior coefficient is derived from statistical analysis of user behavior data from historical marketing campaigns. The preset behavior coefficient is a number greater than 0 and less than 1; for example, if the preset behavior coefficient is 4.5%, then the short-term correction value would be 15%.

[0079] In practice, the determining device 10 can determine the container resource demand based on short-term correction values ​​and periodic forecast values. For example, if the periodic forecast value is 85% and the short-term correction value is 15%, then the target utilization rate is 40%.

[0080] In some examples, to ensure accuracy, the determination device 10 may first clean and standardize the historical load data, including but not limited to outlier detection, missing value imputation, and data smoothing.

[0081] It should be noted that in the embodiments of this application, the determining device 10 can remove outliers based on the 3σ principle, interpolate missing values ​​using linear interpolation, and reduce noise using a moving average filter to make the historical load data smoother.

[0082] S30, the determining device 10 determines the container resource requirements of the container orchestration system based on the target utilization rate.

[0083] In one specific implementation, the determining device 10 can determine the container resource requirements based on the target utilization rate and node constraints. For example, if the target utilization rate is 86%, there are 10 nodes, each node has 16 available CPU cores, and the resource safety threshold is 80%, based on the principle that the target utilization rate is less than or equal to the resource safety threshold, the container resource requirements are determined to be greater than or equal to 172 cores. Therefore, one additional node is needed, ensuring that each node in a single node has a CPU resource requirement of 16 cores.

[0084] In one example, after determining the target utilization rate, the device 10 can calculate a confidence interval based on the historical prediction error distribution, for example, a confidence interval of:

[0085] Where P_final is the target utilization rate. To determine the standard deviation of the error, for example, σ_pred is used to provide the prediction range for a 95% confidence interval. m is the confidence coefficient; if the confidence interval is 95%, m is 1.96; if it is 40%, m is 1.645; and if it is 99%, m is 2.576.

[0086] The determining device 10 can determine the container resource requirements based on this confidence interval. For example, if the target utilization rate P_final is 54.2%, σ_pred is 6%, and m is 1.96, then the confidence interval is [42.6%, 65.8%]. Based on the upper limit of the confidence interval, 65.8%, it can be determined that the container resources must be greater than or equal to this upper limit, thereby avoiding service lag issues caused by insufficient resources.

[0087] Furthermore, the determining device 10 also includes an expansion module for determining whether to expand the container resources of the container orchestration system. In this embodiment, the expansion module presets an expansion threshold. When the sum of the container resource demand and the preset safety margin exceeds the expansion threshold, the container orchestration system is triggered to expand; otherwise, the expansion is not triggered. For example, if the expansion threshold is 70%, the safety margin is 1 σ_pred (6%), the container resource demand is 54.2%, and the sum of the container resource demand and the preset safety margin is 60.2%, which does not exceed the expansion threshold, and therefore expansion is not triggered.

[0088] In other examples, the scaling module can also perform proactive scaling. For instance, if device 10 continues to predict the next 30-minute window and finds that the predicted value at 11:00 may reach 68%, and after adding a safety margin, it becomes 74% > 70%, then the container orchestration system is triggered to scale up one Pod instance in advance at 10:00 to ensure sufficient resources during peak business periods and avoid service latency and user experience degradation.

[0089] In summary, this container resource determination method uses the periodic and long-term load characteristics of historical load data to determine the expected resource utilization rate, i.e., the periodic forecast value, which reflects the inherent periodic patterns and long-term development trends of the business. It then uses the short-term load characteristics of historical load data to determine the expected resource utilization rate, i.e., the short-term correction value, which adapts to sudden fluctuations. The target utilization rate of container resources is determined by the periodic forecast value and the short-term correction value, and the container resource demand is determined based on this target utilization rate. In other words, this method overcomes the limitation of traditional single-time-scale container resource forecasting methods, which can only capture part of the load patterns, resulting in a more accurate and realistic container resource demand that better reflects actual business needs.

[0090] The key to the container resource determination method provided in this application lies in the determination of the target utilization rate. The specific implementation of determining the target utilization rate will be described in detail below with reference to the accompanying drawings.

[0091] To enable those skilled in the art to better understand the determination method provided in the embodiments of this application, historical load data is illustrated using the CPU utilization rate of the most recent 60 days as an example.

[0092] The historical load data exhibits multi-layered periodic patterns. Long-term trends show that business growth leads to a gradual increase in the baseline forecast. Periodic patterns indicate peak access times are 9:00-11:00 AM and 2:00-4:00 PM, with weekday CPU usage higher than weekend CPU usage. Short-term response data shows sudden traffic spikes during marketing campaigns. The current time is 9:45 AM on Wednesday, used to determine CPU usage at 10:00 AM on Wednesday (the target time period).

[0093] Appendix Figure 3 A flowchart of a method for determining a target utilization rate is provided in this application embodiment. The method includes the following steps:

[0094] S301, determine the current baseline forecast value based on the long-term load characteristics of historical load data.

[0095] The current baseline forecast is the expected resource utilization for the target period, determined based on long-term load characteristics from historical load data. This can be understood as reflecting the average resource utilization level for periods following the current moment. For example, a baseline forecast of 45% for Wednesday at 10:00 AM, based on 60 days of historical load data prior to the current moment, indicates that the CPU utilization for the entire day of Wednesday will be 45%.

[0096] In practice, the determining device 10 can aggregate historical load data for a second time period according to a first time length, and determine the current baseline forecast value based on the aggregation result. For example, the determining device aggregates historical load data from the past 60 days on a daily basis to obtain the daily trend of the baseline forecast value. Based on this trend, the current baseline forecast value for the time period after the current moment is determined.

[0097] It should be noted that the first time period can be 1 day, 2 days, 3 hours, 5 hours, etc., and can be adjusted according to the specific needs. The second time period can also be adjusted as needed; for example, the second time period can be the past 60 days.

[0098] In some examples, determining device 10 can determine the segment aggregated observations of historical load data at the target time. Based on the segment aggregated observations and historical baseline predictions, a current baseline prediction is determined. The historical baseline predictions are baseline predictions determined at times prior to the current time. The segment aggregated observations are correlated with the average of historical load data for a first time period prior to the target time. For example, the segment aggregated observations are daily aggregated observations, the target time is time t, and the daily aggregated observations are the average CPU utilization over the 24 hours prior to time t.

[0099] In a specific implementation, the determining device 10 can determine the current reference prediction value according to formula (1):

[0100] (1)

[0101] Where S(t-1) is the historical baseline predicted value determined at time t-1; α is the smoothing coefficient, which is a number greater than 0 and less than 1, for example, α=0.3. t X is the current baseline prediction value determined at time t. t These are daily aggregated observations.

[0102] The baseline forecast obtained in this way can track the gradual trend changes in business load, such as the long-term increase in CPU utilization due to business growth, and can also filter out short-term sudden fluctuations, such as instantaneous peak requests and outliers caused by occasional resource preemption. Therefore, it can enhance the certainty of the baseline forecast.

[0103] S302, determine the periodic forecast value based on the current benchmark forecast value and the composite periodic factor.

[0104] A composite periodicity factor is used to describe the load characteristics of historical load data across multiple time scales. In this embodiment, the composite periodicity factor is used to describe the load characteristics at a first time scale and a second time scale. The first time scale is smaller than the second time scale; for example, the first time scale is one day, and the second time scale is one week.

[0105] In this embodiment of the application, the determining device 10 can process the historical load data of the first time period to obtain the first factor and the second factor.

[0106] The first factor is related to the load characteristics of the first time scale. If the first time scale is 1 day, the first factor can also be an intraday factor. In this embodiment, the first factor is a historical average factor obtained by statistically averaging the historical load data at the corresponding moment within the first time period based on the first time scale. For example, the determining device 10 can calculate the average ratio of the CPU utilization rate at 10:00 AM each day to the average CPU utilization rate of the historical load data for the entire day based on the CPU utilization rate at 10:00 AM each day for the past 28 days, thus obtaining the first factor. For example, the ratio for day 1 is 1.19, the ratio for day 2 is 1.20, and so on. Taking the average of the ratios over 28 days, the first factor is 1.2, which means that the 10:00 AM time period is usually 20% higher than the average value for the entire day.

[0107] It should be noted that the first time period may be the same as or different from the second time period, and this application embodiment does not limit this. For example, the first time period is the past 28 days.

[0108] The second factor is related to the load characteristics of the second time scale. In this embodiment, the second factor is a historical average factor determined by statistically averaging the historical load data at the corresponding moment within the first time period based on the second time scale. If the second time scale is one week, the second factor is also called the intra-week factor.

[0109] For example, if we calculate the average CPU utilization for all Wednesdays at 10 AM over the past 28 days, say 51.75%, and calculate the global average load over the past 28 days, say 45%, then the second factor is 51.75% / 45% = 1.15. This means that the Wednesday 10 AM timeframe is 15% higher than the global average.

[0110] The determining device 10 can determine the composite periodic factor based on the first factor and the second factor. The composite periodic factor is a value between the first factor and the second factor. For example, if the first factor is 1.2 and the second factor is 1.15, then the composite periodic factor is a number between 1.15 and 1.2, such as 1.17.

[0111] In one specific implementation, the composite periodic factor is positively correlated with the first factor and also positively correlated with the second factor. As the first factor increases, the composite periodic factor also increases, and as the second factor increases, the composite periodic factor also increases.

[0112] In some examples, the determining device 10 can determine the composite periodic factor according to formula (2):

[0113] F t =β×H h +(1-β)×W w (2)

[0114] Among them, F t H is the composite periodicity factor at time t. h As the first factor, W w Let F be the second factor, and β be the weighting coefficient of the first factor. β is a number greater than 0 and less than 1, for example, β = 0.7. For instance, if the first factor is 1.2, the second factor is 1.15, and β is 0.7, then F... t The value is 1.185. This method of determining the composite cycle factor can accurately characterize various cyclical patterns in business operations.

[0115] In some examples, the cyclical forecast is the product of the composite cyclical factor and the current benchmark forecast. For instance, if the current benchmark forecast is 45% and the composite cyclical factor is 1.185, then the cyclical forecast is 45% × 1.185 = 53.3%.

[0116] S303, determine the short-term correction value.

[0117] Considering that sudden load changes and short-term anomalies may occur in actual use, and rapid response to drastic changes in container resource requirements is crucial, embodiments of this application can also determine short-term correction values ​​based on the short-term load characteristics of historical load data.

[0118] In some examples, the determination device can process historical load data for the third time period using the Auto Regressive Integrated Moving Average (ARIMA) time series analysis algorithm. The ARIMA algorithm can capture the autocorrelation and trend changes of short-term data, analyze historical fluctuation patterns to identify characteristics of sudden load changes, and determine short-term correction values. For example, determination device 10 captures the additional impact of recent sudden load changes on Wednesday morning at 10:00 AM. Specifically, determination device 10 uses an ARIMA(2,1,1) model based on the most recent 7 days of 15-minute granular data (672 sampling points) up to 9:45 AM, employing a single-step prediction mode to directly determine Wednesday morning at 10:00 AM, showing a slight upward trend, with a short-term correction value of 3%.

[0119] It should be noted that the third time period is shorter than the first time period and also shorter than the second time period.

[0120] It should be noted that single-step prediction mode refers to predicting a short-term correction value for only one smallest time unit in the future, based on complete historical data up to the current moment. For example, predicting the short-term correction value for the next 15 minutes based on 7 days of complete historical data from the current moment. Compared with multi-step extrapolation, single-step prediction has higher prediction accuracy and lower error accumulation risk, and can promptly identify sudden changes in load patterns, providing container orchestration systems with agile scaling trigger signals.

[0121] S304, determine the target utilization rate based on periodic forecasts and short-term corrections.

[0122] In one example, the container resource requirement is obtained according to formula (3):

[0123] P_final=Ct+Ws×Rt(3)

[0124] Where P_final is the target utilization rate, Ct is the periodic predicted value, Rt is the short-term correction value, and Ws is the short-term correction weight coefficient. Ws can be greater than 0 or less than 0, and can be adjusted as needed, for example, Ws=0.3.

[0125] For example, if Ct is 53.3%, Rt is 3%, and Ws = 0.3, then P_final is 54.2%. This means the system predicts a CPU utilization rate of 54.2% at 10:00 AM on Wednesday. If the historical prediction error standard deviation σ_pred = 6%, the 95% confidence interval is [42.6%, 65.8%], and actual detection shows a CPU utilization rate of 55.8% for that period, the prediction error is 1.6%. This indicates that the accuracy of determining the current target utilization rate is high.

[0126] It should be noted that the execution order of S301 and S303 is not limited in the embodiments of this application. For example, they can be executed simultaneously, or S301 can be executed first and then S303 can be executed, or S303 can be executed first and then S301 can be executed.

[0127] It should be noted that the sample points for the historical load data described in S301, S302, and S303 of this application embodiment can be the same or different, and can be adjusted as needed. For example, the historical load data in S301 can be historical load data from 60 days prior to the current time, with each hourly interval. The historical load data in S302 is historical load data from 4 weeks prior to the current time, with each 15-minute interval. The historical load data in S303 is historical load data from 7 days prior to the current time, with each 15-minute interval.

[0128] In summary, the technical feature of determining baseline forecast values ​​based on historical load data can accurately capture the long-term upward trend of business load. The technical feature of calculating periodic forecast values ​​based on composite periodic factors can accurately describe load characteristics at different time scales, such as intraday time-of-day differences and weekly periodic variations. Processing short-term historical data using the ARIMA time series analysis algorithm can capture sudden load changes and adjust forecast values, making the forecast results more refined. Therefore, periodic forecast values ​​can better match actual load conditions, enhancing the predictability of future load. Short-term correction values ​​can identify abnormal events that may affect short-term load, thus enabling rapid response. In conclusion, the target utilization rate determination method provided in this application embodiment can effectively improve the determination accuracy.

[0129] Based on the above method for determining container resource requirements, this application also provides a determining device 10. The determining device 10 will be described below from a functional modular perspective with reference to the accompanying drawings. See also... Figure 1 The schematic diagram of the determining device shown shows that the determining device 10 includes:

[0130] The acquisition unit 101 is used to acquire historical load data of the container orchestration system up to the target time. Optionally, the historical load data includes indicator data corresponding to service characterization indicators and indicator data corresponding to resource load indicators of the minimum scheduling unit in the container orchestration system; the service characterization indicators are used to characterize the service operation status in the container orchestration system, and the resource load indicators are used to characterize the resource occupancy of the minimum scheduling unit.

[0131] The first determining unit 102 is used to determine the target utilization rate of the container orchestration system based on historical load data. The target utilization rate is the expected resource utilization rate of the container orchestration system during a target time period, where the target time period is the period following the target time. The target utilization rate is determined by the periodic predicted value and the short-term correction value of the container orchestration system. The periodic predicted value is the expected resource utilization rate determined based on the periodic load characteristics and long-term load characteristics of historical load data. The short-term correction value is the expected resource utilization rate determined based on the short-term load characteristics of historical load data.

[0132] The second determining unit 103 is used to determine the container resource demand of the container orchestration system during the target time period based on the target utilization rate.

[0133] For example, the above-mentioned acquisition unit 101, first determination unit 102, and second determination unit 103 can be implemented in hardware or in software.

[0134] When implemented through software, the acquisition unit 101, the first determining unit 102, and the second determining unit 103 can be applications or functional modules running on computing devices, such as prediction engine components deployed in a cloud-native environment. These applications can also be virtualized and provided to users as virtualization services. Virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, or container services. Specifically, a VM service can be a service that uses virtualization technology to create virtual machine resource pools on multiple physical hosts to provide VMs for users to use on demand; a BMS service is a service that uses virtualization technology to create BMS resource pools on multiple physical hosts to provide BMS for users to use on demand; and a container service is a service that uses virtualization technology to create container resource pools on multiple physical hosts to provide containers for users to use on demand. A VM is a simulated virtual computer, that is, a logical computer; a BMS is a scalable, high-performance computing service with computing performance indistinguishable from traditional physical machines and featuring secure physical isolation; a container is a kernel virtualization technology that can provide lightweight virtualization to isolate user space, processes, and resources. It should be understood that the VM service, BMS service, and container service mentioned above are merely specific examples. In practical applications, virtualization services can also be other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0135] When implemented in hardware, the acquisition unit 101, the first determining unit 102, and the second determining unit 103 may include at least one computing device (such as a server) or at least one computing core. Alternatively, the aforementioned units may also be devices implemented using application-specific integrated circuits (ASICs) or programmable logic devices (PLDs). The PLD may be implemented using complex programmable logical devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), or any combination thereof.

[0136] In some possible implementations, when the first determining unit 102 determines the periodic forecast value, it is specifically used to: determine the current baseline forecast value based on the long-term load characteristics of historical load data; the current baseline forecast value is the expected resource utilization rate of the target period determined based on the long-term load characteristics of historical load data; determine the periodic forecast value according to the current baseline forecast value and the composite periodic factor; the composite periodic factor is related to the first load characteristic and the second load characteristic of historical load data; the first load characteristic is the historical load characteristic of a first time scale, the second load characteristic is the historical load characteristic of a second time scale, and the first time scale is smaller than the second time scale.

[0137] In some possible implementations, when the first determining unit 102 determines the composite periodic factor, it is specifically used to: obtain a first factor and a second factor; wherein, the first factor is a historical average factor obtained by statistically averaging the historical load data at corresponding moments within a first time period based on a first time scale; the second factor is a historical average factor obtained by statistically averaging the historical load data at corresponding moments within the first time period based on a second time scale; and determine the composite periodic factor based on the first factor and the second factor; wherein, the composite periodic factor is specifically the sum of the product of the first parameter and the first factor, and the product of the second parameter and the second factor; both the first parameter and the second parameter are numbers greater than 0 and less than 1, and the sum of the first parameter and the second parameter is 1.

[0138] In some possible implementations, when the first determining unit 102 determines the current baseline prediction value, it is specifically used to: determine the segment aggregated observation value of historical load data at the target time; the segment aggregated observation value is related to the average value of historical load data for a first time length before the target time; determine the current baseline prediction value based on the segment aggregated observation value and the historical baseline prediction value; the historical baseline prediction value is the expected resource utilization rate determined at a time before the target time; wherein, the current baseline prediction value is the sum of the product of the third parameter and the segment aggregated observation value, and the product of the fourth parameter and the historical baseline prediction value; the third parameter and the fourth parameter are both numbers greater than 0 and less than 1, and the sum of the third parameter and the fourth parameter is 1.

[0139] In some possible implementations, when the first determining unit 102 determines the short-term correction value, it is specifically used to: process historical load data using the autoregressive integral moving average (ARIMA) time series analysis algorithm to determine the short-term correction value.

[0140] In some possible implementations, when the first determining unit 102 determines the target utilization rate, it is specifically used to: determine a periodic predicted value and a short-term correction value based on the historical load data; determine the target utilization rate based on the sum of the product of the periodic predicted value, the fifth parameter, and the short-term correction value; the fifth parameter is a number greater than 0 and less than 1.

[0141] This application also provides a computing device. The computing device can be used to implement... Figure 1 The function of the determining device 10 shown is to perform the aforementioned method for determining container resource requirements. The hardware structure of the computing device will now be described with reference to the accompanying drawings.

[0142] This application also provides a computing device. The computing device can be used to implement... Figure 1 The function of the determining device 10 shown is to perform the aforementioned method for determining container resource requirements. The hardware structure of the computing device will now be described with reference to the accompanying drawings.

[0143] See Figure 4 The diagram illustrates the structure of a computing device 400, which includes a bus 402, a processor 404, a memory 406, and a communication interface 408. The processor 404, memory 406, and communication interface 408 communicate via the bus 402. The computing device 400 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 400.

[0144] Bus 402 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus 402 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 402 may include a path for transmitting information between various components of the computing device 400 (e.g., memory 406, processor 404, communication interface 408).

[0145] Processor 404 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0146] Memory 406 may include volatile memory, such as random access memory (RAM). Memory 406 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD). Memory 406 stores executable program code, which processor 404 executes to implement the aforementioned method for determining container resource requirements. Specifically, memory 406 stores instructions for the determining device 10 to execute the method for determining container resource requirements. For example, memory 406 may store instructions for implementing the acquisition unit 101, the first determining unit 102, and the third determining unit 103.

[0147] The communication interface 408 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 400 and other devices or communication networks.

[0148] According to the method provided in the embodiments of this application, this application also provides a chip system, which includes one or more processors for calling and executing instructions stored in memory, thereby causing the method described in the embodiments of this application to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0149] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0150] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the network device or terminal device in any of the foregoing method embodiments.

[0151] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the network device or terminal device in any of the foregoing method embodiments.

[0152] The computer-readable storage medium may be the aforementioned volatile memory or non-volatile memory, or it may include both volatile memory and non-volatile memory.

[0153] In the embodiments of this application, the terms and English abbreviations are exemplary examples given for ease of description and should not be construed as limiting the application in any way. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0154] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated.

[0155] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

Claims

1. A method for determining container resource requirements, characterized in that, The methods include: Obtain historical load data from the container orchestration system up to the target time. Based on the historical load data, determine the target utilization rate of the container orchestration system; The target utilization rate is the expected resource utilization rate of the container orchestration system during the target time period, which is the period after the target time. The target utilization rate is determined by the periodic forecast and short-term correction values ​​of the container orchestration system; the periodic forecast value is the expected resource utilization rate determined based on the periodic load characteristics and long-term load characteristics of historical load data; the short-term correction value is the expected resource utilization rate determined based on the short-term load characteristics of historical load data. Based on the target utilization rate, determine the container resource requirements of the container orchestration system during the target time period.

2. The method according to claim 1, characterized in that, The method for determining the periodic predicted value includes: Based on the long-term load characteristics of the historical load data, a current baseline forecast value is determined; the current baseline forecast value is the expected resource utilization rate for the target period determined based on the long-term load characteristics of the historical load data. The periodic forecast value is determined based on the current baseline forecast value and the composite periodic factor; the composite periodic factor is related to the first load feature and the second load feature of the historical load data; the first load feature is the historical load feature at a first time scale, the second load feature is the historical load feature at a second time scale, and the first time scale is smaller than the second time scale.

3. The method according to claim 2, characterized in that, The method for determining the composite periodic factor includes: Obtain the first and second factors; Wherein, the first factor is a historical average factor obtained by statistically analyzing the average value of historical load data at corresponding moments within the first time period based on the first time scale; the second factor is a historical average factor obtained by statistically analyzing the average value of historical load data at corresponding moments within the first time period based on the second time scale. The composite periodic factor is determined based on the first factor and the second factor; the composite periodic factor is a number between the first factor and the first factor.

4. The method according to claim 3, characterized in that, The composite periodic factor is the sum of the product of the first parameter and the first factor, and the product of the second parameter and the second factor; Wherein, both the first parameter and the second parameter are numbers greater than 0 and less than 1, and the sum of the first parameter and the second parameter is 1.

5. The method according to claim 2, characterized in that, The determination of the current baseline forecast value based on the long-term load characteristics of the historical load data includes: Determine the segment aggregated observation value of the historical load data at the target time; the segment aggregated observation value is correlated with the average value of the historical load data for a first time length prior to the target time; The current baseline prediction value is determined based on the aggregated observation value of the segment and the historical baseline prediction value; the historical baseline prediction value is the expected resource utilization rate determined at the time prior to the target time.

6. The method according to claim 5, characterized in that, The current baseline prediction value is the sum of the product of the third parameter and the segment aggregated observation value, and the product of the fourth parameter and the historical baseline prediction value; Wherein, the third parameter and the fourth parameter are both numbers greater than 0 and less than 1, and the sum of the third parameter and the fourth parameter is 1.

7. The method according to claim 1, characterized in that, The method for determining the short-term correction value includes: The historical load data is processed using the Autoregressive Integrated Moving Average (ARIMA) time series analysis algorithm to determine the short-term correction value.

8. The method according to claim 1, characterized in that, Determining the target utilization rate of the container orchestration system based on the historical load data includes: Based on the historical load data, determine the periodic forecast value and the short-term correction value; The container resource demand is determined based on the sum of the product of the periodic forecast value, the fifth parameter, and the short-term correction value; the fifth parameter is a number greater than 0 and less than 1.

9. The method according to any one of claims 1-8, characterized in that, The historical load data includes the indicator data corresponding to the business characterization indicators and the indicator data corresponding to the resource load indicators of the smallest scheduling unit in the container orchestration system. The business performance metrics are used to characterize the operational status of services in the container orchestration system, and the resource load metrics are used to characterize the resource usage of the smallest scheduling unit.

10. A device for determining the demand for container resources, characterized in that, The device includes: The acquisition unit is used to acquire historical load data of the container orchestration system up to the target time. The first determining unit is used to determine the target utilization rate of the container orchestration system based on the historical load data. The target utilization rate is the expected resource utilization rate of the container orchestration system during a target time period, which is the period after the target time. The target utilization rate is determined by the periodic forecast value and short-term correction value of the container orchestration system. The periodic forecast value is the expected resource utilization rate determined based on the periodic load characteristics and long-term load characteristics of historical load data. The short-term correction value is the expected resource utilization rate determined based on the short-term load characteristics of historical load data. The second determining unit is used to determine the container resource demand of the container orchestration system during the target time period based on the target utilization rate.

Images