Kubernetes pod elastic scaling method in resource-constrained state
By introducing the Softmax classification model and the custom metric Ela, the scaling problem of Kubernetes Pods under resource-constrained conditions is solved, enabling more precise resource management and load adaptation, and improving the flexibility and efficiency of cluster management.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHENGDU SHENGSIRUI INFORMATION TECH
- Filing Date
- 2022-11-03
- Publication Date
- 2026-05-22
Smart Images
Figure CN115469974B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of container orchestration strategies, and in particular to a method for elastic scaling of Kubernetes Pods under resource-constrained conditions. Background Technology
[0002] With the increasing popularity of container technology, the Kubernetes framework, as one of the best representatives in the field of container orchestration tools, has been widely adopted, and major companies are also making targeted modifications to the open-source version of the Kubernetes framework. In its v2 / beta version, Kubernetes introduced the Horizontal Pod Autoscaler, a Pod autoscaler service that allows users to customize cluster elastic scaling metrics. Although recent research has begun on Kubernetes Pod elastic scaling methods, most existing methods cannot accurately grasp the elastic scaling limits of the cluster, and most methods lack strategies for handling constrained states.
[0003] The publication number is CN 114637650 A, titled "An Elastic Scaling Method Based on Kubernetes Clusters." It proposes a CNN-LSTM hybrid network that predicts future workloads based on historical metrics. The absolute value of the difference between the current and predicted metric values is compared to a set threshold. If the difference exceeds the threshold, scaling up or down is necessary. A timer is used to calculate the time taken; if the time taken is less than or equal to a time threshold, scaling up or down is performed. The default cluster elastic scaling metrics only include basic metrics such as CPU and memory, which cannot accurately reflect the actual system conditions.
[0004] Publication number CN 113395178 A, entitled "A Method and Apparatus for Elastic Scaling of Container Clouds," proposes a two-level elastic scaling approach that proactively scales up nodes by automatically monitoring cluster status and microservice resource utilization. First, it determines whether the microservice's resource utilization meets preset scaling conditions. If so, it calculates the resources required for scaling and then checks whether the remaining nodes in the cluster meet the scaling requirements. If not, it scales up to the minimum required size. The default cluster elastic scaling metrics only include basic indicators such as CPU and memory, which cannot accurately reflect the system's actual situation. Kubernetes will be applied to hosts with fewer computing and storage resources in the future, such as expansion boards. A key characteristic of these hosts is the high likelihood of resource-constrained states during operation, which existing Kubernetes Pod elastic scaling methods cannot handle.
[0005] The shortcomings of the existing technologies mentioned above affect the elastic scaling capability of Kubernetes, making it unable to manage extremely large-scale containers and placing a significant burden on administrators in cluster management. Therefore, this invention proposes a method for elastic scaling of Kubernetes Pods under resource-constrained conditions. Summary of the Invention
[0006] The main technical problem solved by this invention is to provide a method for elastic scaling of Kubernetes Pods under resource-constrained conditions, which can solve the problem that existing Kubernetes Pod elastic scaling methods cannot adapt to potential resource-constrained conditions.
[0007] To address the aforementioned technical problems, one technical solution adopted by this invention is: providing a method for elastic scaling of Kubernetes Pods under resource-constrained conditions, characterized in that the method includes:
[0008] S1: Obtain resource metric data for the Kubernetes cluster using the container orchestration tool. The resource metric data includes historical resource metric data and current resource metric data.
[0009] S2: Clean the resource indicator data to obtain cleaned resource indicator data, which includes cleaned historical resource indicator data and cleaned current resource indicator data.
[0010] S3: Construct a Softmax classification model to predict future resource demand, which includes: stable, increasing, decreasing, resource surplus, and resource bottleneck.
[0011] S4: Input the cleaned current resource index data into the Softmax classification model to obtain the future resource demand;
[0012] S5: Construct the formula for calculating the cluster elastic scaling index, and calculate the cluster elastic scaling index;
[0013] S6: Combining the future resource requirements, cluster elastic scaling indicators, and cluster resource status, obtain the elastic scaling strategy for Kubernetes Pods. The cluster resource status includes: resource-constrained and resource-sufficient.
[0014] Further, S1 includes:
[0015] The historical resource metrics data include: cluster connection count, disk read / write activity, CPU utilization, network latency, number of available container scheduling units (Pods), and the time of the first five unstable results.
[0016] The current resource metrics data include: cluster connection count, disk read / write status, CPU utilization, network latency, number of available container scheduling units (Pods), and the time of the most recent unstable result.
[0017] Further, S2 includes:
[0018] The cleaning process involves filling null values into resource indicator data, grouping and aggregating the null-filled resource indicator data according to time periods, and finally performing time-series conversion and normalization on the indicator data within a time period after grouping and aggregating to obtain the cleaned resource indicator data.
[0019] The preferred duration of a given time period is 5 minutes.
[0020] Further, S3 includes:
[0021] The construction of the Softmax classification model involves dividing the cleaned historical resource index data into a training set and a test set, and then training and predicting the Softmax classification model separately.
[0022] The Softmax classification model has the following classification labels: stable, increasing, decreasing, resource surplus, and resource bottleneck.
[0023] The specific calculation formula for the Softmax classification model is as follows:
[0024]
[0025] in, Let i be the prediction function for the i-th cleaned historical resource index data. As input resource characteristics, For class tags, It is a row vector matrix of model parameters, which estimates the probability of the category to which each historical resource indicator data belongs after cleaning. , Features Classification weights It normalizes the probability distribution, making The sum of the probabilities of belonging to each category is 1, and k is the number of integer categories;
[0026] The loss function of the Softmax classification model is:
[0027]
[0028] Where m represents the number of samples, k represents the number of classes, and c represents the classification task containing instances of class c. Indicates category weight, It is the dot product of sample features and class weights, scale factor, and margin factor.
[0029] Further, S5 includes:
[0030] The Ela metric for elastic scaling of the computing cluster includes: the number of cluster connections. Disk read / write status Network latency CPU utilization Number of available container scheduling units (Pods) The calculation formula is as follows:
[0031]
[0032] Ela refers to the cluster's elastic scaling metric. Ela takes values in the range [0,1]. The parameters can be adjusted according to the importance of different clusters.
[0033] Further, S6 includes:
[0034] The elastic scaling strategy includes:
[0035] When future resource demand is stable, cluster resources are sufficient, cluster elastic scaling index Ela > 0.6 and CPU utilization δ > 0.6, the container scheduling unit Pod is scaled up; when cluster elastic scaling index Ela < 0.3 and CPU utilization δ < 0.3, the container scheduling unit Pod is scaled down; otherwise, it remains unchanged.
[0036] When future resource demand increases, cluster resources are sufficient, cluster elastic scaling index Ela>0.5 and CPU utilization δ>0.5, the container scheduling unit Pod is scaled up; otherwise, it remains unchanged.
[0037] When future resource demand decreases, and without considering cluster resource status, if the cluster elastic scaling index Ela < 0.5 and CPU utilization δ < 0.5, the container scheduling unit Pod will be scaled down; otherwise, it will remain unchanged.
[0038] When future resource demand is in the case of resource surplus, the container scheduling unit Pod is scaled down without considering the cluster resource status.
[0039] If future resource demand presents a resource bottleneck and cluster resources are sufficient, the container scheduling unit Pod will be scaled up; otherwise, it will remain unchanged.
[0040] Furthermore,
[0041] The term "shrinking the container scheduling unit Pod" refers to reducing the Pod unit by one within a prediction period.
[0042] Expanding the container scheduling unit Pod refers to adding one Pod unit within a prediction period.
[0043] The beneficial effects of this invention are:
[0044] 1) A method for elastic scaling of Kubernetes Pods under resource-constrained conditions. This method innovatively introduces the Softmax classification model into the resource prediction before elastic scaling of Kubernetes clusters, so that the algorithm can better understand the resource status of the system during scaling.
[0045] 2) A custom cluster elastic scaling metric, Ela, is proposed. The cluster elastic scaling metric includes the number of cluster connections, disk read / write status, CPU utilization, network latency, and the number of available container scheduling units (Pods). The cluster elastic scaling metric is significantly better than the existing default Kubernetes elastic scaling metric in terms of coverage dimensions. It takes into account the execution scheme under resource-constrained conditions, enabling the present invention to adapt to the resource-constrained conditions that may occur in Kubernetes clusters. Attached Figure Description
[0046] Figure 1 This is a system flowchart of a method for elastic scaling of Kubernetes Pods under resource-constrained conditions according to the present invention.
[0047] Figure 2 This is the left part of the Kubernetes Pod elastic scaling strategy structure diagram;
[0048] Figure 3 This is the right side of the Kubernetes Pod elastic scaling strategy structure diagram. Detailed Implementation
[0049] The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, so that the advantages and features of the present invention can be more easily understood by those skilled in the art, thereby providing a clearer and more explicit definition of the scope of protection of the present invention.
[0050] Please see Figure 1 , Figure 2 and Figure 3 The embodiments of the present invention include:
[0051] S1: Obtain resource metric data for the Kubernetes cluster, which includes historical resource metric data and current resource metric data;
[0052] S2: Clean the resource indicator data to obtain cleaned resource indicator data, which includes cleaned historical resource indicator data and cleaned current resource indicator data.
[0053] S3: Construct a Softmax classification model to predict future resource demand, which includes: stable, increasing, decreasing, resource surplus, and resource bottleneck.
[0054] S4: Input the cleaned current resource index data into the Softmax classification model to obtain the future resource demand;
[0055] S5: Construct the formula for calculating the cluster elastic scaling index, and calculate the cluster elastic scaling index;
[0056] S6: Combining the future resource requirements, cluster elastic scaling indicators, and cluster resource status, obtain the elastic scaling strategy for Kubernetes Pods. The cluster resource status includes: resource-constrained and resource-sufficient.
[0057] Further, S1 includes:
[0058] The historical resource metrics data include: cluster connection count, disk read / write activity, CPU utilization, network latency, number of available container scheduling units (Pods), and the time of the first five unstable results.
[0059] The current resource metrics data include: cluster connection count, disk read / write status, CPU utilization, network latency, number of available container scheduling units (Pods), and the time of the most recent unstable result.
[0060] Further, S2 includes:
[0061] The cleaning process involves filling null values into resource indicator data, grouping and aggregating the null-filled resource indicator data according to time periods, and finally performing time-series conversion and normalization on the indicator data within a time period after grouping and aggregating to obtain the cleaned resource indicator data.
[0062] The preferred duration of a given time period is 5 minutes.
[0063] Further, S3 includes:
[0064] The construction of the Softmax classification model involves dividing the cleaned historical resource index data into a training set and a test set, and then training and predicting the Softmax classification model separately.
[0065] The Softmax classification model has the following classification labels: stable, increasing, decreasing, resource surplus, and resource bottleneck.
[0066] The specific calculation formula for the Softmax classification model is as follows:
[0067]
[0068] in, Let i be the prediction function for the i-th cleaned historical resource index data. As input resource characteristics, For class tags, It is a row vector matrix of model parameters, which estimates the probability of the category to which each historical resource indicator data belongs after cleaning. , Features Classification weights It normalizes the probability distribution, making The sum of the probabilities of belonging to each category is 1, and k is the number of integer categories;
[0069] The loss function of the Softmax classification model is:
[0070]
[0071] Where m represents the number of samples, k represents the number of classes, and c represents the classification task containing instances of class c. Indicates category weight, It is the dot product of sample features and class weights, scale factor, and margin factor.
[0072] Further, S5 includes:
[0073] The Ela metric for elastic scaling of the computing cluster includes: the number of cluster connections. Disk read / write status Network latency CPU utilization Number of available container scheduling units (Pods) The calculation formula is as follows:
[0074]
[0075] Ela refers to the cluster's elastic scaling metric. Ela takes values in the range [0,1]. The parameters can be adjusted according to the importance of different clusters.
[0076] Further, S6 includes:
[0077] The elastic scaling strategy includes:
[0078] When future resource demand is stable, cluster resources are sufficient, cluster elastic scaling index Ela > 0.6 and CPU utilization δ > 0.6, the container scheduling unit Pod is scaled up; when cluster elastic scaling index Ela < 0.3 and CPU utilization δ < 0.3, the container scheduling unit Pod is scaled down; otherwise, it remains unchanged.
[0079] When future resource demand increases, cluster resources are sufficient, cluster elastic scaling index Ela > 0.5 and CPU utilization δ > 0.5, the container scheduling unit Pod is scaled up; otherwise, it remains unchanged.
[0080] When future resource demand decreases, and without considering cluster resource status, if the cluster elastic scaling index Ela < 0.5 and CPU utilization δ < 0.5, the container scheduling unit Pod will be scaled down; otherwise, it will remain unchanged.
[0081] When future resource demand is in the case of resource surplus, the container scheduling unit Pod is scaled down without considering the cluster resource status.
[0082] If future resource demand presents a resource bottleneck and cluster resources are sufficient, the container scheduling unit Pod will be scaled up; otherwise, it will remain unchanged.
[0083] Furthermore,
[0084] The term "shrinking the container scheduling unit Pod" refers to reducing the Pod unit by one within a prediction period.
[0085] Expanding the container scheduling unit Pod refers to adding one Pod unit within a prediction period.
[0086] Example 1:
[0087] A method for elastic scaling of Kubernetes Pods under resource-constrained conditions, characterized in that it includes:
[0088] S1: Obtain resource metric data for the Kubernetes cluster, which includes historical resource metric data and current resource metric data;
[0089] Historical resource metrics data for the cluster were input using the WordCount dataset for testing. Data was sent via Kafka, which irregularly sent WordCount data at speeds of 10MB / s, 20MB / s, and 40MB / s. Historical resource metrics data for the Kubernetes cluster were provided by third-party monitoring software.
[0090] Set the total time interval for Kafka data transmission to 30 minutes, changing every 5 minutes, with data transmission increasing and decreasing at a constant rate.
[0091] As shown below, the total frequency of Kafka data transmission is 30 minutes, changing every 5 minutes, with the data transmission changing in a uniformly increasing and then uniformly decreasing order.
[0092]
[0093] S2: Clean the resource indicator data to obtain cleaned resource indicator data, which includes cleaned historical resource indicator data and cleaned current resource indicator data.
[0094] The resource indicator data provided by the third-party monitoring software is cleaned and filled with null values to obtain the initial input data.
[0095] The initial format of historical resource indicator data is as follows:
[0096]
[0097] Here, "time" represents the time when cluster resources are acquired; This indicates the current number of connections in the cluster. This indicates the disk read / write rate at the current moment. This indicates the current network latency. This indicates the current CPU utilization percentage. This indicates the number of container scheduling units (Pods) available at the current moment.
[0098] The historical resource metrics obtained from the Kafka input data are as follows:
[0099]
[0100] S3: Construct a Softmax classification model to predict future resource demand, which includes: stable, increasing, decreasing, resource surplus, and resource bottleneck.
[0101] S4: Input the cleaned current resource index data into the Softmax classification model to obtain the future resource demand;
[0102] Historical resource metrics data are input into the Softmax model, which assigns different weights to different resource conditions; the weight for rapidly increasing resources is greater than the weight for stable resources. The obtained historical resource data is input into the model for training. After training is complete, the latest resource data information is input, which can provide information on future Kubernetes resource usage, including stable, increasing, decreasing, resource surplus, and resource bottleneck.
[0103] Historical resource data from 6 PCs and 5 expansion cards in a Kubernetes cluster were collected every 4 minutes. The following accuracy and recall rates were obtained using the Softmax model for prediction:
[0104]
[0105] Both Precision and Recall were tested under various conditions, including stability, increase, decrease, resource surplus, and resource bottleneck.
[0106] S5: Construct the formula for calculating the cluster elastic scaling index, and calculate the cluster elastic scaling index;
[0107] Based on the latest monitoring data output by the aforementioned third-party monitoring software, construct the cluster elastic scaling metric Ela.
[0108]
[0109] in , , , This indicates the cluster connection count, disk read / write speeds, network latency, and CPU utilization provided by the latest monitoring software. If the number of Pods in Kubernetes' container scheduling unit is also considered... A value less than 0 indicates that there are currently no available container scheduling unit Pods and expansion is not possible; expansion is only possible when there are available container scheduling unit Pods. The parameters are adjusted according to the importance of different clusters; the values used in this experiment are... .
[0110] S6: Combining future resource requirements, cluster elastic scaling metrics, and cluster resource status, obtain the elastic scaling strategy for Kubernetes Pods. The cluster resource status includes: resource-constrained and resource-sufficient.
[0111] By combining the results of custom elastic scaling metrics and predictions from the SoftMax model, elastic scaling of Kubernetes Pods is performed, and the latest monitoring data is input into the SoftMax model:
[0112] like Figure 2 , Figure 3 As shown, Figure 2 and Figure 3 The two diagrams are connected at the "connection point" to form the structure diagram of the elastic scaling strategy of Kubernetes Pods. When the future resource demand is stable, the cluster resource status is sufficient, the cluster elastic scaling index Ela > 0.6 and the CPU utilization δ > 0.6, the container scheduling unit Pod is scaled up. If the cluster elastic scaling index Ela < 0.3 and the CPU utilization δ < 0.3, the container scheduling unit Pod is scaled down. Otherwise, it remains unchanged.
[0113] When future resource demand increases, cluster resources are sufficient, cluster elastic scaling index Ela > 0.5 and CPU utilization δ > 0.5, the container scheduling unit Pod is scaled up; otherwise, it remains unchanged.
[0114] When future resource demand decreases, and without considering cluster resource status, if the cluster elastic scaling index Ela < 0.5 and CPU utilization δ < 0.5, the container scheduling unit Pod will be scaled down; otherwise, it will remain unchanged.
[0115] When future resource demand is in the case of resource surplus, the container scheduling unit Pod is scaled down without considering the cluster resource status.
[0116] If future resource demand presents a resource bottleneck and cluster resources are sufficient, the container scheduling unit Pod will be scaled up; otherwise, it will remain unchanged.
[0117] Furthermore,
[0118] The term "shrinking the container scheduling unit Pod" refers to reducing the Pod unit by one within a prediction period.
[0119] Expanding the container scheduling unit Pod refers to adding one Pod unit within a prediction period.
[0120] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.
Claims
1. A method for elastic scaling of Kubernetes Pods under resource-constrained conditions, characterized in that, The method includes: S1: Obtain resource metric data for the Kubernetes cluster, which includes historical resource metric data and current resource metric data; S2: Clean the resource indicator data to obtain cleaned resource indicator data, which includes cleaned historical resource indicator data and cleaned current resource indicator data. The cleaning process involves filling null values into resource indicator data, grouping and aggregating the null-filled resource indicator data according to time periods, and finally performing time-series conversion and normalization on the indicator data within a time period after grouping and aggregating to obtain the cleaned resource indicator data. The duration of the specified time period is 5 minutes; S3: Construct a Softmax classification model to predict future resource demand, which includes: stable, increasing, decreasing, resource surplus, and resource bottleneck. S4: Input the cleaned current resource index data into the Softmax classification model to obtain the future resource demand; S5: Construct the formula for calculating the cluster elastic scaling index, and calculate the cluster elastic scaling index; The cluster elastic scaling metrics include: number of cluster connections. Disk read / write status Network latency CPU utilization Number of available container scheduling units (Pods) The calculation formula is as follows: in, This refers to the cluster's elastic scaling performance, among which... , The value range of is [0,1], where The parameters can be adjusted according to the importance of different clusters; S6: Combining the future resource requirements, cluster elastic scaling indicators, and cluster resource status, obtain the elastic scaling strategy for Kubernetes Pods. The cluster resource status includes: resource-constrained and resource-sufficient. The elastic scaling strategy includes: When future resource demand is stable, cluster resources are sufficient, the cluster elastic scaling metric Ela > 0.6, and CPU utilization δ > 0.6, the container scheduling unit Pod is scaled up; if the cluster elastic scaling metric Ela < 0.3 and CPU utilization δ < 0.3, the container scheduling unit Pod is scaled down; otherwise, the status remains unchanged. When future resource demand increases, cluster resources are sufficient, cluster elastic scaling metric Ela > 0.5, and CPU utilization δ > 0.5, the container scheduling unit Pod is scaled up; otherwise, it remains unchanged. When future resource demand decreases, and without considering cluster resource status, if the cluster elastic scaling index Ela < 0.5 and CPU utilization δ < 0.5, the container scheduling unit Pod will be scaled down; otherwise, it will remain unchanged. When future resource demand is in the case of resource surplus, the container scheduling unit Pod is scaled down without considering the cluster resource status. If future resource demand presents a resource bottleneck and cluster resources are sufficient, the container scheduling unit Pod will be scaled up; otherwise, it will remain unchanged.
2. The method for elastic scaling of Kubernetes Pods under resource-constrained conditions as described in claim 1, characterized in that, S1 includes: The historical resource metrics data include: cluster connection count, disk read / write activity, CPU utilization, network latency, number of available container scheduling units (Pods), and the time of the first five unstable results. The current resource metrics data include: cluster connection count, disk read / write status, CPU utilization, network latency, number of available container scheduling units (Pods), and the time of the most recent unstable result.
3. The method for elastic scaling of Kubernetes Pods under resource-constrained conditions as described in claim 1, characterized in that, The S3 includes: The construction of the Softmax classification model involves dividing the cleaned historical resource index data into a training set and a test set, and then training and predicting the Softmax classification model separately. The Softmax classification model has the following classification labels: stable, increasing, decreasing, resource surplus, and resource bottleneck.
4. The method for elastic scaling of Kubernetes Pods under resource-constrained conditions as described in claim 1, characterized in that, The specific calculation formula for the Softmax classification model is as follows: in, Let i be the prediction function for the i-th cleaned historical resource index data. As input resource characteristics, For class tags, It is a row vector matrix of model parameters, which estimates the probability of the category to which each historical resource indicator data belongs after cleaning. Features Classification weights It normalizes the probability distribution. The number of categories; The loss function of the Softmax classification model is: Where m represents the number of samples, Indicates inclusion The task of classifying instances. Indicates category weight, It is the dot product of sample features and class weights, scale factor, and margin factor.
5. The method for elastic scaling of Kubernetes Pods under resource-constrained conditions as described in claim 1, characterized in that, The term "shrinking the container scheduling unit Pod" refers to reducing the Pod unit by one within a prediction period. Expanding the container scheduling unit Pod refers to adding one Pod unit within a prediction period.