A method for scheduling running resources of intelligent manufacturing software

Abstract

This invention discloses a resource scheduling method for supporting intelligent manufacturing software. It employs an LSTM prediction model to predict the load indicators of each container within a predetermined time period. The Gablas test is used to remove suspicious values ​​with large deviations from the predicted load indicators. Based on the removed load indicators, the total comprehensive load of all service Pods in the current system is calculated. If the total comprehensive load exceeds a certain threshold range, scaling operations are performed based on the calculated expected number of replicas. Simultaneously, considering the impact of excessively high or low comprehensive loads of individual service Pods on system services, if the total comprehensive load does not exceed the threshold range, this invention uses a method of judging whether the comprehensive load of a single service Pod exceeds the threshold range to determine whether to trigger scaling operations. This achieves predictive scaling to adapt to resource consumption in advance, which is beneficial for improving cluster resource utilization and ensuring the operational quality of containers in the cluster.

Description

Technical Field

[0001] This invention belongs to the field of intelligent manufacturing optimization control technology, specifically, it relates to a method for scheduling runtime resources to support intelligent manufacturing software. Background Technology

[0002] With the development of the internet and the evolution of cloud technology architecture, the infrastructure of enterprises in the smart manufacturing field is undergoing a transformation from physical servers to virtual machines and now to container clusters. Containerization technology is rapidly developing and is increasingly favored by enterprises in the smart manufacturing field due to its advantages such as fast startup, high scalability, good portability, and high resource utilization. Enterprises are gradually migrating their production environment's business to containers, achieving business cloudification, improving business delivery and iteration capabilities, and significantly improving the utilization of computing resources.

[0003] As applications expand, the number of containerized deployments is growing exponentially. Factors such as communication between containers and resource usage increase the challenges for enterprises in the smart manufacturing sector, leading to the emergence of frameworks for managing container clusters. Among these, Google's open-source Kubernetes has become the mainstream solution due to its advantages, including the ability to manage a large number of cross-host containers, lightweight open-source nature, optimized resource utilization, and scalable functionality.

[0004] In Kubernetes built-in clusters, elastic scaling refers to the ability of the cluster to dynamically adjust the number of nodes, Pods, or resource configurations as business volume increases or decreases. This ensures the service quality of applications in the cluster while saving resources, allowing for the deployment of more services.

[0005] In the Kubernetes ecosystem, different components are provided at multiple dimensions and layers to meet various scaling scenarios. Generally, the workload of business operations is handled by two parts: hosts (workload units) and services (workloads). In Kubernetes, hosts are typically Node nodes, while services refer to Pods (resource types such as Deployments, StatefulSets, and DaemonSets) and the containers contained within those Pods. Therefore, the two largest dimensions of elastic scaling are the host dimension and the service dimension. There are two main implementation methods: horizontal scaling and vertical scaling.

[0006] While Kubernetes' built-in resource scheduler can handle container management and orchestration in most scenarios, it still has some issues with dynamic resource scheduling and cluster elastic scaling, especially horizontal scaling.

[0007] During the Pod's autoscaling period, the system is already resource-saturated. If the request traffic increases at this time, the system service response time will increase accordingly, which will cause request congestion and trigger a chain reaction in the service call chain, directly affecting upstream and downstream business systems, and may even lead to service unavailability and damage the system's availability.

[0008] When calculating utilization, Kubernetes clusters use CPU resources as a data metric. In reality, the CPU usage of a Pod during operation can exceed the number of requests, resulting in a calculated CPU utilization exceeding 100%, which is inconsistent with expectations.

[0009] Because the resource usage of all containers is accumulated, the total resource usage of a Pod may not accurately reflect the resource usage of each individual container. This phenomenon can also lead to some problems, such as a container having very high resource usage, but because the total resource usage at the Pod level is within acceptable constraints, HPA will not perform operations to expand the target object's size.

[0010] While Kubernetes HPA provides cluster platform-level CPU and memory metrics, it lacks application-specific business processing statistics. Current elastic scaling is merely passive, reactive scaling and does not support predictive scaling strategies, thus failing to promptly meet increasing traffic demands. Summary of the Invention

[0011] This invention addresses some of the problems mentioned above in horizontal scaling by proposing an improved elastic scaling strategy. It provides a method for calculating the comprehensive load (CL) and uses CL as an indicator of elastic scaling. Scaling operations are triggered when the overall comprehensive load exceeds a threshold range, or when the comprehensive load of a single Pod is too high or too low. At the same time, an LSTM prediction model is used to predict resources to perform scaling in advance and ensure service quality.

[0012] The present invention is implemented using the following technical solutions:

[0013] A method for scheduling runtime resources to support intelligent manufacturing software is proposed, including:

[0014] An LSTM prediction model is used to predict the load metrics of containers over a specified future time period; these load metrics include CPU, memory, network bandwidth utilization, and disk I / O speed.

[0015] The Gebrs test was used to remove suspicious values ​​from the predicted load index;

[0016] Calculate the total overall load of all service Pods based on the load metrics data after removal;

[0017] When the total overall load exceeds the total threshold range, calculate the expected number of replicas and perform scaling operations.

[0018] When the total load does not exceed the total threshold range, the load of a single service Pod is determined. When the load of a single service Pod exceeds the threshold range, the expected number of replicas is calculated based on the threshold limit of the threshold range, and the Pod is scaled up or down based on the expected number of replicas.

[0019] In some embodiments of the present invention, the method further includes:

[0020] The overall load of the current service Pod is defined as: CL = λ1 * M + λ2 * C + λ3 * D + λ4 * N; where CL is the overall load of the current service Pod, M is the memory utilization, C is the CPU utilization, D is the disk I / O percentage, N is the network bandwidth utilization, and λ is the weight that satisfies λ1 + λ2 + λ3 + λ4 = 1 and α i This refers to the utilization rate of the indicator.

[0021] In some embodiments of the present invention, the expected number of replicas is calculated based on a threshold limit within a threshold range, and the system is expanded or reduced based on the expected number of replicas, including:

[0022] When the overall load of a single service Pod exceeds the upper limit of the threshold, the expected number of replicas is calculated based on the lower limit of the threshold: If the number of replicas remains unchanged, no expansion will be performed; otherwise, expansion will be performed according to the desired number of replicas.

[0023] When the overall load of a single service Pod exceeds the lower threshold, the expected number of replicas is calculated based on the upper threshold: If the number of replicas remains unchanged, no scaling down will be performed; otherwise, scaling down will be performed according to the expected number of replicas.

[0024] In some embodiments of the present invention, the method further includes:

[0025] The total load is calculated according to a set number of times. When the total load exceeding a set proportion exceeds the total threshold range, a scaling operation is triggered, and the scaling operation is performed based on the average of the expected number of replicas calculated when the trigger condition is met.

[0026] Compared with existing technologies, the advantages and positive effects of this invention are as follows: The resource scheduling method for supporting intelligent manufacturing software proposed in this invention uses an LSTM prediction model to predict the load indicators of each container within a future set time period. It uses the Gablas test to remove suspicious values ​​with large deviations from the predicted load indicators. Based on the removed load indicators, it calculates the total comprehensive load of all service Pods in the current system. If the total comprehensive load exceeds the total threshold range, it performs scaling operations based on the calculated expected number of replicas. Simultaneously, considering the impact of excessively high or low comprehensive loads of individual service Pods on system services, if the total comprehensive load does not exceed the total threshold range, this invention uses the method of judging whether the comprehensive load of a single service Pod exceeds the threshold range to determine whether to trigger scaling operations. This achieves predictive scaling to adapt to resource consumption in advance, which is beneficial for improving cluster resource utilization and ensuring the operational quality of containers in the cluster.

[0027] Other features and advantages of the present invention will become clearer after reading the detailed description of the embodiments of the present invention in conjunction with the accompanying drawings. Attached Figure Description

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

[0029] Figure 1 This is a schematic diagram illustrating the execution of the resource scheduling method for supporting intelligent manufacturing software proposed in this invention;

[0030] Figure 2 This is a schematic diagram of the LSTM model in an embodiment of the present invention;

[0031] Figure 3 This is an embodiment of the resource scheduling method for supporting intelligent manufacturing software proposed in this invention. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] In the description of this invention, it should be understood that the terms "center", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0034] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "joining" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0035] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0036] The resource scheduling method for supporting intelligent manufacturing software proposed in this invention, such as... Figure 1 As shown, it includes:

[0037] S1: Use an LSTM prediction model to predict the load index of containers over a specified future time period.

[0038] Since there is no necessary connection between the historical load data of the cluster, and it is obtained in real time based on CPU and other usage data, and the changes in historical data must be taken into account when making predictions, and it must also have a memory function, this invention uses the LSTM algorithm for load prediction.

[0039] As the system runs, it generates time-series load metrics, which are composed of the current CPU, memory, disk I / O speed, and bandwidth usage.

[0040] Based on these load metrics, the system load within a specified time period can be predicted, and resources can be elastically scaled based on the predicted future load metrics.

[0041] After obtaining these monitoring metrics, the metrics are collected, processed, trained, and predicted. The load metrics of a certain service Pod over a certain period of time are recorded as LT={(t1,CL1)…(ti,CL1)…(tn,CLn)}.

[0042] This invention uses the LSTM algorithm to predict load indicators within a set future time period by learning and training on load indicator data from several historical time periods, thus providing a basis for decision-making regarding the dynamic scaling of the system.

[0043] First, the training dataset needs to be preprocessed. Since the load metric dataset consists of ordered data at equal time intervals, only one dimension of the load metric needs to be read, forming a one-dimensional array. Second, after successfully obtaining the array of the specified length, it is normalized using MinMaxScaler to distribute it within the interval [-1, 1], which helps the network model fit faster and improves its accuracy. Then, Keras is used for model building, and the default parameters of Keras can be used.

[0044] The LSTM model is set to have 2 layers, and an implementation is as follows: Figure 2 As shown, finally, the model is trained and fitted. After the model training is completed, the model is saved as a persistent file. When making a prediction, the training is directly loaded and the input is passed in to complete the prediction process.

[0045] S2: Use the Gebrstra test to remove suspicious values ​​from the predicted load index.

[0046] After LSTM predicts the load data for a future set time period (10s in this embodiment of the invention), it is necessary to determine the resource requirements of a certain service Pod in the cluster based on these predicted data, so as to achieve dynamic, advance-aware, and smooth dynamic scaling of the service Pod without affecting the existing transaction data.

[0047] Because the volume of transactions processed per second and resource usage vary, resource utilization dynamically changes, making it impossible for any prediction to be 100% accurate. Therefore, resource scaling cannot be simply based on prediction data for a single second; instead, it's necessary to assess resource utilization over a future period. Since these load data may contain suspicious values ​​with significant deviations, it's essential to first verify the data for any suspicious values ​​when calculating the overall load for the next 10 seconds.

[0048] This invention employs the Grubbs test to remove suspicious values, including:

[0049] 1) Adopt Calculate the G value for each load metric, where x iThis is a load metric, where n is the number of data points. This is the mean of all the data.

[0050] 2) Determine the critical value by looking up the Gablas critical value table based on the amount of data and the confidence probability.

[0051] 3) Data with a G value less than the critical value are classified as valid data.

[0052] S3: Calculate the total load of all service Pods based on the load metrics data after removal.

[0053] In this invention, the overall load of the current service Pod is defined as: CL = λ1 * M + λ2 * C + λ3 * D + λ4 * N; where CL is the overall load of the current service Pod, M is the memory utilization rate, C is the CPU utilization rate, D is the disk I / O ratio, N is the network bandwidth utilization rate, and λ is the weight that satisfies λ1 + λ2 + λ3 + λ4 = 1 and α i This refers to the utilization rate of the indicator.

[0054] As described above, the weights of the four load metrics are adjusted according to their importance, but the sum of the weights is 1, and the calculated overall load CL falls within the range of [0, 1]. A larger CL indicates a higher system load, requiring dynamic system scaling. In practice, the weight of each load metric needs to be dynamically set based on the application type. For example, compute-intensive service Pods should have a heavier weight for the CPU factor, while read-write applications should have a heavier weight for the disk I / O factor.

[0055] This invention considers the utilization rate of various load indicators in the calculation of weights. The utilization rate α of a certain indicator... i The higher the value, the greater the impact on CL.

[0056] Based on the comprehensive load formula given above, the CL of each service Pod can be calculated. This CL metric can comprehensively reflect the overall load level of the current Pod node while simplifying the calculation complexity and ensuring the quality of application services.

[0057] The total load here is the sum of the loads of all service Pods in the system, with a threshold range of [ab, a+b], where a is the scaling threshold and b is the scaling tolerance coefficient. The total threshold range is [j(ab), j(a+b)], where j is the number of current service Pods.

[0058] S4: When the total overall load exceeds the total threshold range, calculate the expected number of replicas and perform scaling operations.

[0059] When the total load of all service Pods exceeds the total threshold range, the expected number of replicas can be calculated and executed according to the existing scaling operations, which is not the part limited by this invention.

[0060] In some embodiments of the present invention, the total comprehensive load is calculated according to a set number of times. When the total comprehensive load exceeds a set proportion (e.g., 50% of the set number of times) and exceeds the total threshold range, the scaling operation is triggered. The scaling operation is performed based on the average of the expected number of replicas calculated when the triggering condition is met, so as to avoid errors caused by inaccurate resource utilization in a single instance.

[0061] S5: When the total load does not exceed the threshold range, determine the load of a single service Pod. When the load of a single service Pod exceeds the threshold range, calculate the expected number of replicas based on the threshold limit of the threshold range, and scale up or down based on the expected number of replicas.

[0062] Considering that the total overall load of a Pod does not accurately reflect the load of each container, this invention also considers situations where a high overall load of a single service Pod leads to service unavailability, or a low overall load of a single service Pod leads to wasted service resources.

[0063] Even if the total load of all service Pods does not meet the scaling requirements, a scaling operation can still be triggered if the total load of a single service Pod is too high or too low.

[0064] In Kubernetes environment testing and experiments, the main focus was on the relationship between dynamic scaling time consumption, the number of replicas during scaling, and whether the number of Pods after scaling immediately triggered a new scaling cycle. To fully utilize resources and improve Pod response efficiency, while also considering situations where a single service Pod's load is too high or too low, this invention sets the dynamic scaling threshold to 0.6 and the scaling tolerance coefficient to 0.1. The maximum number of replicas for dynamic scaling is twice the original number, and the minimum number of replicas for dynamic scaling down is half the original number, rounded up.

[0065] When the total load does not exceed the threshold range, it is necessary to determine the maximum and minimum load of a single service Pod. By comparing the boundary conditions of the extreme values ​​and the threshold, it is necessary to determine whether further scaling operations are needed.

[0066] If the overall load of a single service Pod in the cluster exceeds the upper limit of the threshold, then scaling up will be considered. However, the overall load of all Pods in the cluster will also be taken into account, and the number of new replicas will be calculated based on the lower limit of the threshold. Where k is the number of replicas of the current application, and min is the lower limit of the dynamic scaling threshold; if the number of replicas remains unchanged, no scaling operation is required; otherwise...

[0067] Similarly, if the overall load of a single service Pod in the cluster is lower than the lower threshold, a scaling-down operation will be considered. Taking into account the overall load of all Pods in the cluster, the number of new replicas will be calculated based on the upper threshold. Where k is the number of replicas of the current application, and max is the upper limit of the dynamic scaling threshold. If the number of replicas remains unchanged, no scaling up operation is required; otherwise, a scaling down operation is performed based on the new number of replicas.

[0068] The improved elastic scaling process is as follows: Figure 3 As shown, the modified elastic scaling algorithm still maintains the intermittent operation control loop characteristic, obtaining the latest predicted load value every 15 seconds. First, a suspicious value removal operation is performed to delete predictions with large errors. Then, the remaining set is used to calculate the total comprehensive load value of the Pods and check if it is within the total threshold range. Taking a threshold range of [0.5, 0.7] as an example, if it is not within the total threshold range based on this range, scaling is directly triggered, without needing to judge individual service Pods with large load deviations. If the total comprehensive load is within the total threshold range, to ensure that the resource usage of each container is within a reasonable range, the algorithm collects the maximum and minimum load data of the current service Pods. By judging the relationship between the maximum load and the upper threshold, it determines whether a scaling operation is needed; and by judging the relationship between the minimum load and the lower threshold, it determines whether a scaling operation is needed.

[0069] It should be noted that, in the specific implementation process, the above-mentioned control part can be implemented by a hardware processor executing computer-executable instructions in software form stored in memory, which will not be elaborated here. The programs corresponding to the actions performed by the above control circuit can all be stored in the computer-readable storage medium of the system in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0070] The computer-readable storage media mentioned above may include volatile memory, such as random access memory; may also include non-volatile memory, such as read-only memory, flash memory, hard disk or solid-state drive; and may also include combinations of the above types of memory.

[0071] The term "processor" as mentioned above can also refer to a collective of multiple processing elements. For example, a processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor, and it can also be a special-purpose processor.

[0072] It should be noted that the above description is not intended to limit the present invention, and the present invention is not limited to the examples given above. Any changes, modifications, additions or substitutions made by those skilled in the art within the scope of the present invention should also fall within the protection scope of the present invention.

Claims

1. A method for scheduling running resources to support intelligent manufacturing software, characterized in that, include: An LSTM prediction model is used to predict the load metrics of containers over a specified future time period; these load metrics include CPU, memory, network bandwidth utilization, and disk I / O speed. The Gebrs test was used to remove suspicious values ​​from the predicted load index; Calculate the total overall load of all service Pods based on the load metrics data after removal; When the total overall load exceeds the total threshold range, calculate the expected number of replicas and perform scaling operations. When the total load does not exceed the total threshold range, the load of a single service Pod is determined. When the load of a single service Pod exceeds the threshold range, the expected number of replicas is calculated based on the threshold limit of the threshold range, and the system is scaled up or down based on the expected number of replicas. The process includes calculating the expected number of replicas based on a threshold limit within a threshold range, and then scaling up or down based on the expected number of replicas, including: When the overall load of a single service Pod exceeds the upper limit of the threshold, the expected number of replicas is calculated based on the lower limit of the threshold: If the number of replicas remains unchanged, no expansion will be performed; otherwise, expansion will be performed according to the desired number of replicas. When the overall load of a single service Pod exceeds the lower threshold, the expected number of replicas is calculated based on the upper threshold: If the number of replicas remains unchanged, no scaling down will be performed; otherwise, scaling down will be performed according to the expected number of replicas. Where k is the number of replicas of the current application, min is the lower limit of the dynamic scaling threshold, and max is the upper limit of the dynamic scaling threshold; The method further includes: Define the overall load of the current service Pod as: CL= *M+ *C+ *D+ *N; where CL is the overall load of the current service Pod, M is the memory utilization, C is the CPU utilization, D is the disk I / O percentage, N is the network bandwidth utilization, and λ is the weight that satisfies and , For indicator utilization rate; The total load is calculated according to a set number of times. When the total load exceeding a set proportion exceeds the total threshold range, a scaling operation is triggered, and the scaling operation is performed based on the average of the expected number of replicas calculated when the trigger condition is met.

Images