A method, device, medium and product for scaling a K8S cluster

Abstract

The application provides a method, device, medium and product for scaling a K8S cluster. The method for scaling the K8S cluster comprises: obtaining monitoring data of a target K8S cluster and a plurality of sets of node resource information corresponding to a plurality of nodes in the target K8S cluster; determining load prediction information of the target K8S cluster based on the monitoring data by using a load prediction model; determining a resource fragmentation index of the target K8S cluster based on the plurality of sets of node resource information; determining a scaling scheme for the target K8S cluster based on the resource fragmentation index and the load prediction information; the scaling scheme comprises a vertical scaling decision, a horizontal scaling decision and a fragmentation management decision; and executing the scaling scheme on the target K8S cluster.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method, device, medium and product for scaling up and down a K8S cluster. Background Technology

[0002] In cloud computing environments, Kubernetes (K8s) provides powerful container management and orchestration capabilities, enabling core functions such as resource scheduling, service deployment, and elastic scaling. With dynamic changes in business workloads, achieving efficient and intelligent cluster scaling has become a key technical challenge in ensuring system stability and resource utilization.

[0003] In related technologies, Kubernetes primarily utilizes two tools for automatically scaling clusters and workloads: CA (Cluster Autoscaler) and HPA (Horizontal Pod Autoscaler). These tools automatically add or remove nodes based on current resource requirements to adapt to changes in application load. Specifically, a traffic threshold is set, and a scaling solution is determined based on a comparison of received traffic with that threshold. The Kubernetes cluster then processes the traffic based on the scaled-down version, thus reducing the efficiency of traffic processing. Summary of the Invention

[0004] This application provides a method, device, medium, and product for scaling up and down a K8S cluster, which can improve the efficiency of traffic processing.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a method for scaling up and down a Kubernetes cluster, the method comprising: Acquire monitoring data of the target K8S cluster and multiple sets of node resource information corresponding to multiple nodes in the target K8S cluster; Based on the monitoring data, the load prediction information of the target K8S cluster is determined using a load prediction model. Based on the aforementioned multiple sets of node resource information, the resource fragmentation index of the target K8S cluster is determined; Based on the resource fragmentation index and the load prediction information, a scaling up / down scheme for the target Kubernetes cluster is determined; the scaling up / down scheme includes vertical scaling decisions, horizontal scaling decisions, and fragmentation management decisions. The scaling up / down scheme is executed on the target K8s cluster.

[0006] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the scaling method for the K8S cluster provided in the embodiments of this application.

[0007] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implements the Kubernetes cluster scaling method provided in this application.

[0008] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the Kubernetes cluster scaling method provided in this application.

[0009] The embodiments of this application have the following beneficial effects: The scaling up / down device of the K8S cluster obtains the monitoring data of the target K8S cluster and multiple sets of node resource information corresponding to multiple nodes in the target K8S cluster. Based on the load prediction model and the monitoring data, it determines the load prediction information of the target K8S cluster. Based on the multiple sets of node resource information, it determines the resource fragmentation index of the target K8S cluster. Based on the resource fragmentation index and the load prediction information, it determines the scaling up / down scheme for the target K8S cluster and executes the scaling up / down scheme to obtain the scaled up / down target K8S cluster. This allows the received traffic to be processed directly based on the scaled up / down target K8S cluster, eliminating the need to determine the scaling up / down scheme again when the traffic is received. The scaled up / down target K8S cluster can be used directly to process the traffic when it is received, thus improving the efficiency of traffic processing. Attached Figure Description

[0010] Figure 1 This is a flowchart of a method for scaling up or down a K8S cluster provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the structural composition of an exemplary load prediction model provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating an exemplary process for determining resource fragmentation index provided in an embodiment of this application; Figure 4 This is a schematic diagram of an exemplary method for scaling up and down a K8S cluster provided in an embodiment of this application; Figure 5 This is a schematic diagram illustrating the composition of an exemplary K8S cluster scaling structure provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structural composition of a K8S cluster scaling device provided in an embodiment of this application; Figure 7This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application.

[0011] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] This application provides a method for scaling up and down a Kubernetes (K8S) cluster, which is applied to a K8S cluster scaling up and down device. Figure 1 A flowchart illustrating a method for scaling up or down a K8S cluster, as provided in this application embodiment, is shown below. Figure 1 As shown, the scaling methods for a Kubernetes cluster can include: S101. Obtain monitoring data of the target K8S cluster and multiple sets of node resource information corresponding to multiple nodes in the target K8S cluster.

[0014] The scaling method for a K8S cluster provided in this application is applicable to scenarios where a scaling scheme for a target K8S cluster is determined and executed.

[0015] In the embodiments of this application, the scaling device for a K8S cluster can be implemented in various forms. For example, the scaling device for a K8S cluster described in this application may include processors, controllers, servers, terminals, etc. The specific scaling device for a K8S cluster can be determined according to the actual situation, and the embodiments of this application do not limit it in this regard.

[0016] In this embodiment, the Kubernetes cluster scaling device serves as the execution entity for the Kubernetes cluster scaling method described in this application. It can also be a container orchestration management system deployed in a cloud platform or data center. Specifically, it can be a core component of the Kubernetes control plane, such as the API Server, Scheduler, Controller Manager, or a separately deployed elastic management service (such as the DEFPRAG-SCALE system) as the execution entity. The container orchestration management system communicates with the kubelet components of each node in the cluster to collect real-time runtime status data and obtains historical and current load metrics through monitoring tools such as Prometheus and Grafana, thereby obtaining complete monitoring data.

[0017] In this embodiment, the monitoring data is a set of dynamic indicators reflecting the overall operating status of the target Kubernetes cluster, including but not limited to CPU utilization, memory utilization, network I / O, disk I / O, number of Pods, request rate, error rate, and latency. Specific monitoring data can be determined based on actual conditions, and this embodiment does not limit this. Monitoring data is typically recorded in time-series format for analyzing load trends and abnormal fluctuations.

[0018] For example, in an online transaction system, monitoring data might include requests per second (QPS), average response time, database connections, cache hit rate, etc.; while in an AI inference service scenario, monitoring data might include GPU utilization, model inference latency, batch size, etc. The frequency of monitoring data collection can be set according to actual needs, such as once per second, per minute, or every 5 minutes; highly sensitive businesses can use millisecond-level sampling.

[0019] In the embodiments of this application, multiple nodes correspond one-to-one with multiple sets of node resource information, that is, one node corresponds to one set of node resource information.

[0020] It should be noted that multiple sets of node resource information can be specific parameters of the available resources on each physical or virtual node, including the total number of CPU cores, total memory capacity, total number of GPUs, remaining CPU cores, remaining memory, and remaining GPUs for each node.

[0021] It should also be noted that multiple sets of node resource information can be periodically reported to the API Server by the kubelet and stored in etcd for other components to query. For example, node A has 48 CPU cores, 128GB of memory, and 4 NVIDIA A100 GPU cards. Currently, 32 CPU cores, 64GB of memory, and 2 GPU cards have been allocated. Therefore, the remaining resources for node A are 16 CPU cores, 64GB of memory, and 2 GPU cards. These multiple sets of node resource information can be a collection of the above resource states for all nodes in the cluster (including 48 CPU cores, 128GB of memory, 4 GPU cards, 16 CPU cores, 64GB of memory, and 2 GPU cards), which can be used to calculate the resource fragmentation index later.

[0022] In this embodiment, a list of node statuses can be pulled from the Kubernetes API Server via the API interface, and monitoring data for a specified time period can be obtained by calling the Prometheus Query API. For large-scale clusters (such as hundreds of nodes), system overhead can be reduced by using sharded queries or streaming data collection.

[0023] Understandably, this application comprehensively collects the target K8S cluster's operating status and resource distribution to provide an accurate and complete data foundation for subsequent predictive modeling and fragmentation analysis, ensuring the reliability and real-time nature of the decision-making basis.

[0024] S102. Using the load prediction model based on monitoring data, determine the load prediction information of the target K8S cluster.

[0025] In this embodiment of the application, after the scaling device of the K8S cluster obtains the monitoring data of the target K8S cluster, it uses the load prediction model to determine the load prediction information of the target K8S cluster based on the monitoring data.

[0026] In this embodiment, the load prediction model can be a model configured in the scaling device of the K8S cluster, a model transmitted from other devices to the scaling device of the K8S cluster, or a model obtained by the scaling device of the K8S cluster through other means. The specific way in which the scaling device of the K8S cluster obtains the load prediction model can be determined according to the actual situation, and this embodiment does not limit it.

[0027] For example, the load prediction model is a model trained on the scaling device of the Kubernetes cluster.

[0028] In this embodiment, the load prediction model can be a machine learning model or a statistical model, used to predict the load trend of a target Kubernetes cluster over a future period based on historical and real-time monitoring data. This application employs a hybrid prediction architecture, integrating long-term trend analysis, short-term correction, and burst compensation to improve prediction accuracy and response speed. The input to the load prediction model is a monitoring data matrix within a sliding window, and the output is the load prediction information for the next time point T (e.g., 5 minutes or 1 hour).

[0029] In this embodiment, the load prediction model can be deployed on a dedicated prediction service node or integrated into the control plane, employing a lightweight framework (such as TensorFlow Lite or ONNX Runtime) to reduce inference latency. Load prediction information can be sent to the decision engine via a message queue (such as Kafka), supporting parallel prediction by multiple models and result fusion.

[0030] Understandably, load prediction models can be used to accurately predict and respond to changes in the load of a target Kubernetes cluster, significantly reducing scaling delays. This is especially useful in scenarios with sudden traffic surges, preventing service degradation or timeouts due to delayed responses.

[0031] In this embodiment, the process by which the scaling up / down device of a K8S cluster determines the load prediction information of a target K8S cluster based on monitoring data using a load prediction model includes: acquiring historical load information and determining dynamic sliding window parameters based on the historical load information; determining initial load prediction information using the load prediction model based on the dynamic sliding window parameters and monitoring data; performing second derivative detection on the initial load prediction information using the load prediction model to obtain detection information; performing error correction using the load prediction model based on monitoring data to obtain correction information; and determining the load prediction information based on the initial load prediction information, detection information, and correction information.

[0032] In this embodiment, historical load information can be obtained from a database, from other devices, or through other means. The specific method of obtaining historical load information can be determined according to the actual situation, and this embodiment does not limit it.

[0033] It should be noted that historical load information is a record of load data generated during the actual operation of the target Kubernetes cluster over a past period, including multi-dimensional indicators such as CPU utilization, memory usage, network throughput, and GPU utilization. Historical load information is usually stored in time-series format to reflect the trend and fluctuation characteristics of system load over time. For example, historical load information may include hourly or minute sampling points from the past 7 days, 30 days, or even longer periods.

[0034] In this embodiment, the dynamic sliding window parameter is dynamically adjusted based on historical load information. This dynamic sliding window parameter is used to adapt to changes in load fluctuations and improve prediction sensitivity. The adjustment method of the dynamic sliding window parameter is shown in formula (1): (1) It should be noted that, This is a parameter for a dynamically sliding window, representing the current window size. The standard deviation of the load in the previous period. This is the historical baseline standard deviation (e.g., the average standard deviation of the past 30 days). When load fluctuations are significant... To increase, leading to Increasing the window size expands its range and enhances its ability to capture long-term trends; conversely, decreasing the window size when the load is stable... Decrease Reduce, and improve the speed of response to short-term changes.

[0035] For example, in a target Kubernetes cluster within an AI inference service scenario, if CPU utilization fluctuates drastically within the past hour (e.g., jumping from 20% to 80%), the dynamic sliding window parameter will automatically increase to incorporate more historical data to smooth out noise and avoid misjudging sudden traffic spikes. Conversely, during periods of low business activity, the dynamic sliding window parameter will decrease to focus on recent data and quickly respond to minor load changes. This dynamic adjustment mechanism effectively balances prediction stability and response agility, significantly improving prediction accuracy.

[0036] In this embodiment, the dynamic sliding window parameters are dynamically adjusted using historical load information, which can adapt to the data requirements under different load modes. This can enhance the sensitivity of the load prediction model to sudden changes and trend changes, thereby reducing prediction bias and improving the reliability of overall resource scheduling decisions.

[0037] In this embodiment of the application, the process of determining load prediction information based on initial load prediction information, detection information, and correction information includes fusing the initial load prediction information, detection information, and correction information to obtain load prediction information.

[0038] In this embodiment, the initial load prediction information is determined using a load prediction model based on dynamic sliding window parameters and monitoring data; the second derivative of the initial load prediction information is detected using the load prediction model to obtain detection information; error correction is performed using the load prediction model based on monitoring data to obtain correction information; the process of determining the load prediction information based on the initial load prediction information, detection information, and correction information is as shown in formula (2): (2) It should be noted that, This is initial load forecast information, specifically long-term trends. This is for correction information, specifically short-term correction. This is for detection information, specifically for emergency compensation. For dynamic window data matrix, The values ​​are AR coefficients, and 0.7 and 0.3 are weighting coefficients, which can be dynamically adjusted through online learning.

[0039] In this embodiment of the application, detection information is obtained through second-derivative burst detection. The process is shown in formula (3): (3) It should be noted that, This is a step function (output 1 if it is greater than 0). Using a threshold, it can detect sudden changes in traffic 50-200ms earlier than traditional first-order derivative detection. For time intervals, Let be the flow rate at time t. It is the second derivative of the time series.

[0040] An exemplary structural diagram of the load forecasting model is shown below. Figure 2 The diagram shows the process, which includes dynamic adjustment of the sliding window, time-series prediction, AR error correction, obtaining the predicted value H_t, burst detection, and output. The dynamic sliding window parameters can be determined based on historical load information in the original indicator stream. Dynamic adjustment of the sliding window is then implemented based on these parameters, and the adjusted sliding window parameters are the dynamic sliding window parameters. Time-series prediction can be performed based on the dynamic sliding window parameters and monitoring data in the original indicator stream to obtain initial load prediction information (i.e., the predicted value H_t). Second-order derivative detection (i.e., burst detection) is then performed based on the initial load prediction information to obtain detection information. AR error correction can be performed based on the monitoring data in the original indicator stream to obtain correction information. Therefore, based on the initial load prediction information, detection information, and correction information, the load prediction information is determined and output.

[0041] In this embodiment, the load prediction model improves prediction accuracy and burst traffic response speed through dynamic windowing, hybrid prediction, and second-order detection, thereby enhancing both resource consumption performance.

[0042] S103. Based on multiple sets of node resource information, determine the resource fragmentation index of the target K8S cluster.

[0043] In this embodiment of the application, after the scaling up and down device of the K8S cluster obtains multiple sets of node resource information corresponding to multiple nodes in the target K8S cluster, it determines the resource fragmentation index of the target K8S cluster based on the multiple sets of node resource information.

[0044] In this embodiment, the Resource Fragmentation Index (RFI) is a quantitative indicator used to assess the degree of resource dispersion in a target Kubernetes cluster. A higher RFI indicates more dispersed resources, making it difficult to meet the demand for contiguous resource blocks required by resource-intensive tasks (such as AI training tasks). The RFI is calculated based on multi-dimensional data from multiple sets of node resource information, including remaining node resources, total node resources, and resource allocation rate. It is derived through weighted aggregation of fragment counts and allocation rates, and supports dynamic threshold judgments to determine whether to initiate defragmentation or adjust scaling strategies.

[0045] For example, the resource fragmentation index calculation module can be deployed in the resource management service to periodically scan multiple sets of node resource information corresponding to multiple nodes and update the global resource fragmentation index value.

[0046] Understandably, by determining the resource fragmentation index of the target Kubernetes cluster, a quantitative assessment of the resource dispersion of the target Kubernetes cluster can be achieved, providing key input to the decision engine, effectively identifying potential scheduling failure risks, and improving the scheduling success rate of large resource tasks.

[0047] In this embodiment, the process by which the scaling device for a K8S cluster determines the resource fragmentation index of a target K8S cluster based on multiple sets of node resource information includes: obtaining from multiple sets of node resource information the remaining number of CPU cores, remaining memory, remaining GPUs, total CPU cores, total GPUs, and total memory of multiple nodes; determining multiple resource fragmentation counts for multiple nodes based on the remaining CPU cores, remaining memory, and remaining GPUs; determining multiple resource allocation rates for multiple nodes based on the remaining CPU cores, remaining memory, and remaining GPUs; determining multiple initial resource fragmentation indices for multiple nodes based on the multiple resource fragmentation counts and allocation rates; and aggregating the multiple initial resource fragmentation indices to obtain the resource fragmentation index.

[0048] In this application embodiment, the multiple sets of node resource information include the remaining number of CPU cores of multiple nodes, the remaining memory information of multiple nodes, the remaining number of GPU cards of multiple nodes, the total number of CPU cores of multiple nodes, the total number of GPU cards of multiple nodes, and the total memory information of multiple nodes.

[0049] It should be noted that each node corresponds to a set of node resource information, which includes the number of remaining CPU cores, the number of remaining memory, the number of remaining GPUs, the total number of CPU cores, the total number of GPUs, and the total memory of the node.

[0050] In this embodiment, the process of determining multiple resource fragment counts for multiple nodes based on the remaining CPU cores, remaining memory, and remaining GPUs of multiple nodes includes: determining a first resource fragment count for a first node based on the remaining CPU cores, remaining memory, and remaining GPUs of a first node; determining a second resource fragment count for a second node based on the remaining CPU cores, remaining memory, and remaining GPUs of a second node; ...; determining a last resource fragment count for the last node based on the remaining CPU cores, remaining memory, and remaining GPUs of the last node; and using the first, second, ..., and last resource fragment counts as multiple resource fragment counts.

[0051] It should be noted that the process of determining the first resource fragment count of the first node based on the remaining CPU cores, remaining memory, and remaining GPUs of the first node includes: obtaining the CPU core resource requirements, memory resource requirements, and GPU resource requirements of the smallest pod; determining the first quotient of the remaining CPU cores and the CPU core resource requirements of the smallest pod, and determining the difference between the rounded-down and rounded-up values ​​of the first quotient to obtain the first fragment information; determining the second quotient of the remaining memory and the memory resource requirements of the smallest pod, and determining the difference between the rounded-down and rounded-up values ​​of the second quotient to obtain the second fragment information; determining the third quotient of the remaining GPUs and the GPU resource requirements of the smallest pod, and determining the difference between the rounded-down and rounded-up values ​​of the third quotient to obtain the third fragment information; and finally, determining the first, second, and third fragment information as the first resource fragment count.

[0052] It should also be noted that the method for determining the count of the second resource fragment, the count of the third resource fragment, ..., and the count of the last resource fragment as multiple resource fragment counts is the same as the method for determining the count of the first resource fragment. For details, please refer to the method for determining the count of the first resource fragment, which will not be elaborated here.

[0053] For example, the process of determining the first resource fragment count of the first node based on the number of remaining CPU cores, the remaining memory information, and the remaining GPU cards of the first node is as shown in formula (4): (4) It should be noted that, That is, r represents the number of CPU cores, memory information, and the number of remaining GPU cards. This indicates the number of remaining CPU cores, remaining memory, and remaining GPU cards of the first node. This indicates the minimum CPU core requirements, minimum memory requirements, and minimum GPU card requirements for the smallest pod. This indicates the count of the first resource fragment.

[0054] In this embodiment, the process of determining multiple resource allocation rates for multiple nodes based on the remaining CPU cores, remaining memory, remaining GPUs, total CPU cores, total GPUs, and total memory of multiple nodes includes: determining a first resource allocation rate for a first node based on the remaining CPU cores, remaining memory, remaining GPUs, total CPU cores, total GPUs, and total memory of a first node; and determining a first resource allocation rate for a second node based on the remaining CPU cores, remaining memory, remaining GPUs, total CPU cores, total GPUs, and total memory of the second node. The second resource allocation rate of the second node is determined based on the remaining GPU cores, total CPU cores, total GPU cores, and total memory of the second node; ...; the last resource allocation rate of the last node is determined based on the remaining CPU cores, remaining memory, remaining GPU cores, total CPU cores, total GPU cores, and total memory of the last node; the first resource allocation rate, second resource allocation rate, ..., last resource allocation rate are used as multiple resource allocation rates.

[0055] It should be noted that the process of determining the first resource allocation rate of the first node based on the remaining CPU cores, remaining memory, remaining GPUs, total CPU cores, total GPUs, and total memory of the first node includes: determining the first difference between the total CPU cores and the remaining CPU cores, and determining the quotient between the first difference and the total CPU cores to obtain CPU allocation information; determining the second difference between the total memory and the remaining memory, and determining the quotient between the second difference and the total memory to obtain memory allocation information; determining the third difference between the total GPUs and the remaining GPUs, and determining the quotient between the third difference and the total GPUs to obtain GPU allocation information; and using the CPU allocation information, memory allocation information, and GPU allocation information as the first resource allocation rate.

[0056] It should also be noted that the method for determining the second, third, ... and last resource allocation rates is the same as the method for determining the first resource allocation rate. For details, please refer to the method for determining the first resource allocation rate, which will not be elaborated here.

[0057] For example, the process of determining the first resource allocation rate of the first node based on the remaining CPU cores, remaining memory, remaining GPUs, total CPU cores, total GPUs, and total memory of the first node is as shown in formula (5): (5) It should be noted that 'r' represents the number of CPU cores, memory information, and the number of remaining GPU cards; This indicates the number of remaining CPU cores, remaining memory, and remaining GPU cards of the first node. This indicates the total number of CPU cores, the total number of GPUs, and the total memory of the first node. The first resource allocation rate includes CPU allocation information (i.e., ), GPU allocation information (i.e. ) and memory allocation information (i.e. ).

[0058] In the embodiments of this application, multiple nodes correspond one-to-one with multiple initial resource fragmentation indices, that is, one node corresponds to one initial resource fragmentation index.

[0059] In this embodiment of the application, the process of determining multiple initial resource fragment indices corresponding to multiple nodes based on multiple resource fragment counts and multiple resource allocation rates includes determining a first initial resource fragment index of a first node based on a first resource fragment count and a first resource allocation rate of a first node; determining a second initial resource fragment index of a second node based on a second resource fragment count and a second resource allocation rate of a second node; ...; determining a last initial resource fragment index of a last node based on a last resource fragment count and a last resource allocation rate of a last node; and using the first initial resource fragment index, the second initial resource fragment index, ..., the last initial resource fragment index as multiple initial resource fragment indices.

[0060] It should be noted that the process of determining the first initial resource fragment index of the first node based on the first resource fragment count and the first resource allocation rate of the first node is as shown in formula (6): (6) It should be noted that 'r' represents the number of CPU cores, memory information, and the number of remaining GPU cards; The first resource allocation rate; Count the first resource fragment; This is the fragmentation penalty factor; when j is 1, This is the first initial resource fragment index corresponding to the first node.

[0061] It should also be noted that the fragmentation penalty factor can be a parameter configured in the scaling device of the K8S cluster, a parameter transmitted from other devices to the scaling device of the K8S cluster, or a parameter obtained by the scaling device of the K8S cluster through other means. The specific way in which the scaling device of the K8S cluster obtains the fragmentation penalty factor can be determined according to the actual situation, and this application embodiment does not limit it.

[0062] In this embodiment of the application, the method for determining the second initial resource fragment index, the third initial resource fragment index, ..., the last initial resource fragment index is the same as the method for determining the first initial resource fragment index. For details, please refer to the method for determining the first initial resource fragment index, which will not be elaborated here.

[0063] In this embodiment of the application, the process of aggregating multiple initial resource fragmentation indices to obtain a resource fragmentation index is shown in formula (7): (7) It should be noted that, Here, N represents the resource fragmentation index, and N is the number of nodes in the target Kubernetes cluster. Let be the initial resource fragmentation index corresponding to the j-th node.

[0064] For example, in the resource fragmentation index If the resource fragmentation index is [0, 0.3), then scheduling training tasks is allowed, within the range of [0, 0.3]. If the resource fragmentation index is [0.3, 0.5), then preventative fragmentation can be initiated. If the value is [0.5, 1], scheduling can be stopped until the sorting is complete.

[0065] For example, the process of determining the resource fragmentation index of a target Kubernetes cluster is as follows: Figure 3As shown: First, obtain multiple sets of node resource information corresponding to multiple nodes in the target Kubernetes cluster (i.e., obtain node resources); from the multiple sets of node resource information, obtain the remaining CPU cores, remaining memory, remaining GPUs, total CPU cores, total GPUs, and total memory of multiple nodes; based on the remaining CPU cores, remaining memory, remaining GPUs, total CPU cores, total GPUs, and total memory of multiple nodes, determine multiple resource allocation rates for multiple nodes (i.e., calculate allocable resources); based on the remaining CPU cores, remaining memory, and remaining GPUs of multiple nodes, determine multiple resource fragment counts for multiple nodes (i.e., calculate fragment counters); based on the multiple resource fragment counts and multiple resource allocation rates, determine multiple initial resource fragmentation indices corresponding to multiple nodes (i.e., calculate RFI); aggregate the multiple initial resource fragmentation indices to obtain the resource fragmentation index (cluster RFI summary).

[0066] S104. Based on the resource fragmentation index and load prediction information, determine the scaling up or down scheme for the target K8s cluster.

[0067] In this embodiment of the application, the scaling up / down device of the K8S cluster determines the resource fragmentation index of the target K8S cluster based on multiple sets of node resource information, and then determines the scaling up / down scheme of the target K8S cluster based on the resource fragmentation index and load prediction information.

[0068] It should be noted that the scaling up and down schemes include vertical scaling up decisions, horizontal scaling up decisions, and fragmentation management decisions.

[0069] In this embodiment, the scaling up / down scheme includes scaling up decisions and scaling down decisions. The scaling up decisions include vertical scaling up decisions, horizontal scaling up decisions, etc., and the specific scaling up decisions can be determined according to the actual situation; this embodiment does not limit this. By comprehensively considering load forecasting information and resource fragmentation index in determining the scaling up / down scheme for the target Kubernetes cluster, it is possible to ensure that resource utilization efficiency is maximized while meeting business performance requirements.

[0070] Understandably, this application determines the scaling up / down scheme for the target K8s cluster based on resource fragmentation index and load prediction information, realizing the coordinated optimization of scaling up / down decision and resource fragmentation status, avoiding resource waste or scheduling failure caused by simply relying on load indicators, and significantly improving the resource utilization and task success rate of the target K8S cluster.

[0071] In this embodiment, the process by which the scaling up / down device of a K8S cluster determines a scaling up / down scheme for a target K8S cluster based on resource fragmentation index and load prediction information includes: when the resource fragmentation index is less than a first preset index and the load prediction value corresponding to the load prediction information is greater than a dynamic threshold, obtaining the remaining CPU cores, remaining memory, and continuously available GPUs of multiple nodes; determining scaling up parameters based on the remaining CPU cores, remaining memory, and continuously available GPUs of multiple nodes; determining vertical scaling up as the scaling up scheme when the scaling up parameters are greater than or equal to the preset scaling up parameters; determining horizontal scaling up and fragmentation management as the scaling up scheme when the scaling up parameters are less than the preset scaling up parameters; and determining scaling down as the scaling down scheme when the resource fragmentation index is less than the first preset index and the load prediction value is less than or equal to the dynamic threshold.

[0072] In this embodiment, the first preset index can be information configured in the scaling device of the K8S cluster, information transmitted from other devices to the scaling device of the K8S cluster, or information obtained by the scaling device of the K8S cluster through other means. The specific way in which the scaling device of the K8S cluster obtains the first preset index can be determined according to the actual situation, and this embodiment does not limit it.

[0073] It should be noted that the first preset index can be 0.3, or it can be other parameter values. The specific parameter value of the first preset index can be determined according to the actual situation, and this application embodiment does not limit it.

[0074] In this embodiment, the dynamic threshold can be information set in the scaling device of the K8S cluster, information transmitted from other devices to the scaling device of the K8S cluster, or information obtained by the scaling device of the K8S cluster through other means. The specific way in which the scaling device of the K8S cluster obtains the dynamic threshold can be determined according to the actual situation, and this embodiment does not limit it.

[0075] It should be noted that the parameter value of the dynamic threshold can be determined according to the actual situation, and this application embodiment does not limit it.

[0076] In this embodiment, the remaining CPU cores, remaining memory, and continuously available GPUs of multiple nodes can be obtained from multiple nodes. Alternatively, these parameters can be obtained through other means. The specific method for obtaining these parameters can be determined based on actual circumstances, and this embodiment does not limit it.

[0077] In this embodiment, the process of determining expansion parameters based on the remaining CPU cores of multiple nodes, the remaining memory information of multiple nodes, and the number of continuously available GPUs of multiple nodes includes: determining the first node expansion parameters of the first node based on the remaining CPU cores of the first node, the remaining memory information of the first node, and the number of continuously available GPUs of the first node; determining the second node expansion parameters of the second node based on the remaining CPU cores of the second node, the remaining memory information of the second node, and the number of continuously available GPUs of the second node; ...; determining the last node expansion parameters of the last node based on the remaining CPU cores of the last node, the remaining memory information of the last node, and the number of continuously available GPUs of the last node; and summing the expansion parameters of the first node, the second node, ..., and the last node to obtain the expansion parameters.

[0078] It should be noted that the process of determining the first node expansion parameters based on the remaining CPU cores, remaining memory, and continuously available GPUs of the first node includes determining the product of the remaining CPU cores, remaining memory, and continuously available GPUs of the first node to obtain the first node expansion parameters.

[0079] It should also be noted that the method for determining the expansion parameters of the second node, the third node, ..., and the last node is the same as the method for determining the expansion parameters of the first node. For details, please refer to the method for determining the expansion parameters of the first node, which will not be elaborated here.

[0080] In this embodiment, the preset scaling parameters can be information configured in the scaling device of the K8S cluster, information transmitted from other devices to the scaling device of the K8S cluster, or information obtained by the scaling device of the K8S cluster through other means. The specific way in which the scaling device of the K8S cluster obtains the preset scaling load can be determined according to the actual situation, and this embodiment does not limit it.

[0081] In this embodiment, the previous load prediction information obtained from the previous prediction can be obtained, and the preset expansion parameters can be determined based on the difference between the load prediction information and the previous load prediction information; other methods can also be used to determine the speech rate and expansion parameters based on the load prediction information. The specific implementation method can be determined according to the actual situation, and this embodiment does not limit it.

[0082] In this embodiment of the application, the conditions for vertical scaling decision are as follows: based on the remaining CPU cores of multiple nodes, the remaining memory information of multiple nodes, and the number of continuously available GPU cards of multiple nodes, the scaling parameters are determined; if the scaling parameters are greater than or equal to the preset scaling parameters, the scaling scheme is determined as the vertical scaling decision in the scaling decision.

[0083] For example, the conditions for vertical expansion decisions are shown in formula (8): (8) It should be noted that, Let be the number of remaining CPU cores in the j-th node. This refers to the remaining memory information for the j-th node. Let N be the number of consecutively available GPUs in the j-th node (you can count only physically contiguous GPU groups), and N be the number of nodes. The preset expansion parameters, i.e. the predicted load increment, are determined based on load prediction information.

[0084] For example, The determination method is shown in formula (9): (9) It should be noted that g represents the number of GPUs that are continuously available.

[0085] For example, a vertical scaling decision involves adjusting the resource allocation of a pod, such as increasing the CPU and memory of a single pod from 250M to 1000M.

[0086] In this embodiment, the horizontal scaling decision and fragmentation management decision are to increase the number of pods and migrate the migrateable pods on the high RFI node (first node) to the second node. Fragmentation management is to migrate the migrateable pods on the high RFI node (first node) to the second node.

[0087] In the embodiments of this application, the scaling down decision is the decision in the prior art that can achieve the scaling down purpose. The specific scaling down decision can be determined according to the actual situation, and the embodiments of this application do not limit it.

[0088] In this embodiment, when the resource fragmentation index is less than a first preset index and the load prediction value corresponding to the load prediction information is greater than the dynamic threshold, the scaling device of the K8S cluster will also obtain historical load information before obtaining the remaining CPU cores of multiple nodes, the remaining memory information of multiple nodes, and the number of continuously available GPU cards of multiple nodes. Based on the historical load information, the historical load mean and the historical load standard deviation are determined. Based on the historical load mean and the historical load standard deviation, the dynamic threshold is determined.

[0089] In this embodiment, historical load information can be obtained from a database, from other devices, or through other means. The specific method of obtaining historical load information can be determined according to the actual situation, and this embodiment does not limit it.

[0090] For example, the load of the target K8S cluster can be recorded in real time and written to the database, so that historical load information can be obtained from the database.

[0091] In the embodiments of this application, the method of determining the historical load mean and historical load standard deviation based on historical load information is the prior art, and the specific embodiments of this application will not be described in detail here.

[0092] In this embodiment of the application, the process of determining a dynamic threshold based on the historical load mean and the historical load standard deviation includes obtaining a first fusion coefficient and a second fusion coefficient, and fusing the historical load mean and the historical load standard deviation based on the first fusion coefficient and the second fusion coefficient to obtain the dynamic threshold.

[0093] For example, the process of determining the dynamic threshold based on the historical load mean and historical load standard deviation is shown in formula (10): (10) It should be noted that, For dynamic thresholds, This is the historical average load. , where is the historical load standard deviation, 0.7 is an exemplary first fusion coefficient, and 0.3 is an exemplary second fusion coefficient.

[0094] In the embodiments of this application, the dynamic threshold can also be determined in other ways based on the historical load average and the historical load standard deviation. The specific implementation method can be determined according to the actual situation, and the embodiments of this application do not limit it.

[0095] In this embodiment of the application, the process of determining the scaling scheme for the target K8S cluster based on the resource fragmentation index and load prediction information by the K8S cluster scaling device further includes: when the resource fragmentation index is greater than or equal to a first preset index, selecting a first node from the target K8S cluster whose initial resource fragmentation index is greater than or equal to a second preset index; selecting a migrateable pod from the first node; selecting a second node from the target K8S cluster; and migrating the pod to the second node.

[0096] In this embodiment, the second preset index can be information configured in the scaling device of the K8S cluster, information transmitted from other devices to the scaling device of the K8S cluster, or information obtained by the scaling device of the K8S cluster through other means. The specific way in which the scaling device of the K8S cluster obtains the second preset index can be determined according to the actual situation, and this embodiment does not limit it.

[0097] It should be noted that the parameter value of the second preset index can be 4, or it can be other values. The specific parameter value of the second preset index can be determined according to the actual situation, and this application embodiment does not limit it.

[0098] In this embodiment of the application, the process of selecting the first node from the target K8S cluster whose initial resource fragmentation index is greater than or equal to the second preset index is as shown in formula (11): (11) It should be noted that, Indicates the first node, This represents the initial resource fragmentation index of the j-th node, and 0.4 is the parameter value of the second preset index.

[0099] In this embodiment, pods that can be migrated can be selected in the first node based on the absence of node affinity constraints and pod priority. Alternatively, other methods can be used to select pods that can be migrated in the first node. The specific method for selecting pods that can be migrated in the first node can be determined according to the actual situation, and this embodiment does not limit it.

[0100] For example, the way to filter migrateable pods in the first node is as shown in formula (12): (12) It should be noted that, For a portable pod, For Pods without node affinity constraints, This indicates pod priority, where p represents the pod. The threshold parameter, such as the priority threshold, indicates that the pods that can be migrated are those without node affinity constraints and whose priority in the node is less than the priority threshold.

[0101] In this embodiment of the application, the process of selecting the second node in the target K8S cluster is as shown in formula (13): (13) It should be noted that, Indicates the second node, The value of RFI that minimizes k RFI values. express There are constraints. For specific constraints, multiple initial resource fragmentation indices corresponding to multiple nodes need to be less than 0.2, and the used CPU resources in the nodes need to be less than 60%. That is, among multiple nodes, at least one node with multiple initial resource fragmentation indices less than 0.2 and used CPU resources less than 60% is identified, and the node with the smallest RFI among the at least one node is the second node.

[0102] In this embodiment, the second node can also be selected in the target K8S cluster in other ways. The specific way to select the second node in the target K8S cluster can be determined according to the actual situation, and this embodiment does not limit it.

[0103] In this embodiment, the method of migrating the pod to the second node can be determined according to the actual situation, and this embodiment does not limit it.

[0104] For example, the process of migrating a pod to a second node is shown in formula (14): (14) It should be noted that 'p' represents a portable pod. Indicates the first node, Indicates the second node, Indicates migration.

[0105] S105. Execute the scaling up / down scheme on the target K8s cluster.

[0106] In this embodiment of the application, the scaling up / down device of the K8S cluster determines the scaling up / down scheme for the target K8S cluster based on the resource fragmentation index and load prediction information, and then executes the scaling up / down scheme for the target K8S cluster.

[0107] It is understood that the Kubernetes cluster scaling method provided in this application integrates a dynamic load prediction model with multi-dimensional resource fragmentation index calculation to achieve accurate prediction of the target Kubernetes cluster load and real-time perception of resource status. Then, through a unified decision engine, it intelligently generates scaling solutions by comprehensively considering load prediction information and resource fragmentation index. This allows for rapid response under high load and proactive resource reclamation under low load, while a fragmentation defragmentation mechanism ensures the success rate of large task scheduling. Ultimately, this significantly improves the resource utilization, system response speed, and task scheduling success rate of the target Kubernetes cluster. This solution breaks through the limitations of traditional fragmented optimization, achieving a paradigm shift from passive response to proactive prediction, from single indicators to multi-dimensional perception, and from independent decision-making to collaborative optimization.

[0108] In this embodiment, the process of the scaling up / down device of the K8S cluster executing a scaling up / down scheme on the target K8S cluster includes: when the scaling up / down scheme is a scaling down decision, after a preset time period, acquiring new monitoring data of the target K8S cluster at the current time; using a load prediction model based on the new monitoring data to determine new load prediction information; when the new load prediction value corresponding to the new load prediction information is less than or equal to a dynamic threshold, executing a scaling down decision on the target K8S cluster; and when the scaling up / down scheme is a scaling up decision, executing a scaling up decision on the target K8S cluster.

[0109] In this embodiment, the preset time period can be information configured in the scaling device of the K8S cluster, information transmitted from other devices to the scaling device of the K8S cluster, or information obtained by the scaling device of the K8S cluster through other means. The specific way in which the scaling device of the K8S cluster obtains the preset time period can be determined according to the actual situation, and this embodiment does not limit it.

[0110] It should be noted that the preset time period can be 15 minutes, 20 minutes, or other lengths. The specific length of the preset time period can be determined according to the actual situation, and this application embodiment does not limit it.

[0111] For example, if the preset time period is 15 minutes and the current time is 4:05, then after the preset time period, new monitoring data for the target K8S cluster at the current time will be obtained, that is, when 15 minutes are reached (i.e., 4:20), new monitoring data for the target K8S cluster will be obtained.

[0112] It should be noted that the new monitoring data is obtained by monitoring the target K8S cluster after the initial monitoring data is released.

[0113] In this embodiment, the method of determining new load prediction information based on new monitoring data using a load prediction model is the same as the method of determining the load prediction information of the target K8S cluster based on monitoring data using a load prediction model. For details, please refer to the method of determining new load prediction information based on new monitoring data using a load prediction model, which will not be elaborated here.

[0114] In this embodiment of the application, if the new load prediction value corresponding to the new load prediction information is less than or equal to the dynamic threshold, then a scaling-down decision is performed on the target K8s cluster.

[0115] It should be noted that the target Kubernetes cluster can also be continuously monitored within a preset time period to obtain continuous monitoring data. Based on the comparison between this continuous monitoring data and the dynamic threshold, a decision is made on whether to scale down the target Kubernetes cluster. If the continuous monitoring data is all less than or equal to the dynamic threshold, then a scaling down decision is made for the target Kubernetes cluster; or if most of the continuous monitoring data (e.g., more than 50% of the monitoring data) is less than or equal to the dynamic threshold, then a scaling down decision is made for the target Kubernetes cluster.

[0116] Understandably, by introducing a preset time period and acquiring new monitoring data before making a scaling-down decision, it is possible to effectively filter out misjudgments caused by a brief drop in load, thereby improving the accuracy of scaling-down decisions and reducing the risk of service interruption due to the misrelease of resources.

[0117] In this embodiment of the application, when the scaling up or down scheme is determined to be a scaling up decision (such as a vertical scaling up decision or a horizontal scaling up decision and a fragmentation management decision), the scaling up decision can be executed on the target K8s cluster immediately without waiting for a preset time period.

[0118] It should be noted that the Kubernetes cluster scaling method in this application is a fusion of dynamic load forecasting and elastic decision-making for container clusters. This includes processing multi-dimensional data, multi-level dynamic resource optimization, and model data feedback, dynamically adjusting the cluster based on predicted resource requirements. This application also proposes a three-in-one collaborative control architecture integrating dynamic load forecasting and elastic decision-making, a multi-resource fragmentation quantification model, and a vertical scaling-first elastic strategy. The instruction interaction protocol between the decision engine, fragmentation manager, and load balancer is based on an RFI-based preventative fragmentation triggering process.

[0119] Understandably, this application fully considers the need for multi-dimensional data in actual dynamic load forecasting and is capable of handling multi-dimensional and heterogeneous data input. The DEFPRAG-SCALE system proposed in this application effectively solves industry pain points such as response lag and static decision-making in cloud computing container clusters under elastic scaling scenarios, scheduling inefficiency caused by resource fragmentation, and efficiency bottlenecks caused by fragmented resource management. Through a closed-loop system of dynamic perception, intelligent decision-making, and continuous optimization, it defines a new management paradigm for elastic resources in the cloud-native era, providing a new elastic scaling solution with millisecond-level response, zero-fragmentation interference, and fully automatic collaboration for scenarios such as AI computing power infrastructure and large-scale microservices. In comparison, the technical solution in this application is more adaptable to complex and ever-changing real-world application scenarios, providing more accurate and efficient container cluster elastic scaling solutions for different types of business needs, enhancing resource utilization efficiency and cluster stability, and making it more competitive and practical in dynamic resource optimization solutions.

[0120] For example, such as Figure 4 As shown: First, acquire monitoring data of the target Kubernetes cluster and multiple sets of node resource information corresponding to multiple nodes in the target Kubernetes cluster; then, use a load prediction model based on the monitoring data to determine the load prediction information of the target Kubernetes cluster (obtain the predicted load); based on the multiple sets of node resource information, determine the resource fragmentation index of the target Kubernetes cluster (…). ), in the resource fragmentation index ( ) is less than the first preset index ( If the load prediction value (predicted load) corresponding to the load prediction information is greater than the dynamic threshold (YES), obtain the remaining CPU cores, remaining memory, and continuously available GPUs of multiple nodes. Based on the remaining CPU cores, remaining memory, and continuously available GPUs of multiple nodes, determine the scaling parameters (scaling decision). If the scaling parameters are greater than or equal to the preset scaling parameters (vertical scaling feasible, YES), determine the scaling solution as the vertical scaling decision. If the scaling parameters are less than the preset scaling parameters (vertical scaling feasible, No), determine the scaling solution as the horizontal scaling decision and fragmentation management decision (horizontal scaling + fragmentation constraint). If the scaling solution is a scaling decision, execute the scaling decision (execute vertical scaling or horizontal scaling decision and fragmentation management decision) on the target K8s cluster. When the resource fragmentation index is less than the first preset index ( If the load prediction value is greater than or equal to the dynamic threshold (No), the scaling-down solution is determined to be a scaling-down decision. If the scaling-down solution is a scaling-down decision, after a preset time period (delayed 15 minutes), new monitoring data for the target K8S cluster is obtained; based on the new monitoring data, the load prediction model is used to determine new load prediction information; if the new load prediction value corresponding to the new load prediction information is less than or equal to the dynamic threshold (load remains low, YES), a scaling-down decision is executed on the target K8S cluster (scaling down is executed); if the new load prediction value corresponding to the new load prediction information is greater than the dynamic threshold (load remains low, NO), monitoring continues. If the resource fragmentation index is greater than or equal to the first preset index (No), the scaling-down decision is executed. If the initial resource fragmentation index is greater than or equal to the second preset index (YES), then defragmentation is performed. Specifically, the first node (high RFI node) is selected from the target Kubernetes cluster; the migrateable pods are selected from the first node; the second node is selected from the target Kubernetes cluster (target node is found); and the pods are migrated to the second node (migration is performed).

[0121] It should be noted that after performing a migration operation, or a scaling up operation, or a scaling down operation, the state of the target Kubernetes cluster is updated (i.e., the cluster state is updated).

[0122] For example, such as Figure 5 As shown, the scaling device for a Kubernetes (K8S) cluster includes modules such as a dynamic load prediction module, an elastic scaling executor, a resource fragmentation manager, a load balancer controller, and a DEFPRAG-SCALE decision engine. The dynamic load prediction module includes a load prediction model. This application obtains monitoring data of the target K8S cluster (i.e., the K8S cluster itself) and multiple sets of node resource information corresponding to multiple nodes in the target K8S cluster. Then, based on the monitoring data, the load prediction model can be used to determine the load prediction information of the target K8S cluster. Based on the multiple sets of node resource information, the resource fragmentation manager can determine the resource fragmentation index of the target K8S cluster. Based on the resource fragmentation index and load prediction information, the DEFPRAG-SCALE decision engine can determine the scaling scheme for the target K8S cluster. The elastic scaling executor executes the scaling scheme on the target K8S cluster. Afterwards, the load balancer controller transmits the received traffic to the target K8S cluster after the scaling scheme has been executed through load balancing.

[0123] It should be noted that before using the scaling device of the K8S cluster, large-scale cluster monitoring data indicators can be collected and used as model input to train the dynamic load prediction model. The resource fragmentation index (RFI) is calculated by the resource fragmentation management module, and the scaling scheme is dynamically determined by the DEFPRAG-SCALE decision engine. The scaling scheme is executed by the elastic scaling executor. Each scaling result is fed back to the monitoring layer to optimize subsequent decisions, forming a closed-loop control, thereby continuously optimizing the model parameters.

[0124] In this embodiment, all decisions in this application are coordinated by a unified decision engine to avoid conflicts between multiple modules. Scaling up and down, defragmentation, and load balancing are incorporated into a unified decision framework to dynamically adjust resource allocation.

[0125] Understandably, this application addresses a series of practical problems in Kubernetes elastic scaling, such as response lag, resource fragmentation, and fragmented optimization. It proposes a Kubernetes cluster scaling device, namely the Kubernetes Elastic Scaling Collaboration System (DEFPRAG-SCALE) based on fragmentation awareness and prediction-driven scaling. This system integrates a prediction-driven scaling module, a resource fragmentation management module, and vertical scaling. Through this three-in-one collaboration, it significantly improves response speed and the success rate of AI training task scheduling, effectively reduces fragmentation risks, greatly improves resource utilization, and ensures service stability and performance. In other words, this application effectively solves the industry pain points of response lag and static decision-making in cloud computing container clusters under elastic scaling scenarios, scheduling inefficiencies caused by dimensional resource fragmentation, and efficiency bottlenecks caused by fragmented resource management. Through a closed-loop system of dynamic awareness, intelligent decision-making, and continuous optimization, it redefines the elastic resource management paradigm of the cloud-native era, providing millisecond-level response, zero-fragmentation interference, and fully automated collaborative elastic scaling solutions for AI computing power infrastructure, large-scale microservices, and other scenarios.

[0126] Understandably, the scaling mechanism of a Kubernetes (K8S) cluster acquires monitoring data of the target K8S cluster and multiple sets of node resource information corresponding to multiple nodes within the target K8S cluster. Based on the load prediction model and the monitoring data, it determines the load prediction information of the target K8S cluster. Based on the multiple sets of node resource information, it determines the resource fragmentation index of the target K8S cluster. Then, based on the resource fragmentation index and the load prediction information, it determines a scaling plan for the target K8S cluster and executes the scaling plan to obtain a scaled-down target K8S cluster. This allows the received traffic to be processed directly based on the scaled-down target K8S cluster, eliminating the need to determine a scaling plan upon receiving traffic. This improves the efficiency of traffic processing.

[0127] Based on the same inventive concept as the above-mentioned scaling method for K8S clusters, this application provides a scaling device 1 for K8S clusters, corresponding to a scaling method for K8S clusters. Figure 6 A schematic diagram of the composition structure of a Kubernetes cluster scaling device provided in this application embodiment. Figure 1 The scaling device 1 of the K8S cluster may include: The acquisition unit 11 is used to acquire monitoring data of the target K8S cluster and multiple sets of node resource information corresponding to multiple nodes in the target K8S cluster. The determining unit 12 is used to determine the load prediction information of the target K8S cluster based on the monitoring data using a load prediction model; determine the resource fragmentation index of the target K8S cluster based on the multiple sets of node resource information; and determine the scaling up / down scheme for the target K8S cluster based on the resource fragmentation index and the load prediction information; the scaling up / down scheme includes vertical scaling up decision, horizontal scaling up decision, and fragmentation management decision. Execution unit 13 is used to execute the scaling up / down scheme on the target K8s cluster.

[0128] In some embodiments of this application, the acquisition unit 11 is used to acquire the number of remaining CPU cores, the remaining memory information, and the number of continuously available GPU cards of the multiple nodes when the resource fragmentation index is less than a first preset index and the load prediction value corresponding to the load prediction information is greater than a dynamic threshold. The determining unit 12 is configured to determine expansion parameters based on the remaining CPU cores of the plurality of nodes, the remaining memory information of the plurality of nodes, and the number of continuously available GPU cards of the plurality of nodes; if the expansion parameters are greater than or equal to preset expansion parameters, determine the expansion / shrinkage scheme as a vertical expansion decision in the expansion decision; if the expansion parameters are less than the preset expansion parameters, determine the expansion / shrinkage scheme as a horizontal expansion decision and a fragmentation management decision in the expansion decision; and if the resource fragmentation index is less than a first preset index and the load prediction value is less than or equal to the dynamic threshold, determine the expansion / shrinkage scheme as a shrinkage decision.

[0129] In some embodiments of this application, the acquisition unit 11 is used to acquire historical load information; The determining unit 12 is used to determine the historical load mean and historical load standard deviation based on the historical load information; and to determine the dynamic threshold based on the historical load mean and historical load standard deviation.

[0130] In some embodiments of this application, the acquisition unit 11 is used to acquire new monitoring data of the target K8S cluster at the current time after a preset time period when the scaling-up scheme is the scaling-down decision. The determining unit 12 is used to determine new load prediction information based on the new monitoring data using the load prediction model; The execution unit 13 is configured to execute the scaling-down decision on the target K8s cluster when the new load prediction value corresponding to the new load prediction information is less than or equal to the dynamic threshold; and to execute the scaling-up decision on the target K8s cluster when the scaling-up scheme is the scaling-up decision.

[0131] In some embodiments of this application, the apparatus further includes an aggregation unit; The acquisition unit 11 is used to acquire the remaining CPU cores of multiple nodes, the remaining memory information of multiple nodes, the remaining GPU card number of multiple nodes, the total CPU cores of multiple nodes, the total GPU card number of multiple nodes, and the total memory information of multiple nodes from the multiple sets of node resource information. The determining unit 12 is configured to: determine multiple resource fragment counts for the multiple nodes based on the remaining CPU cores, remaining memory information, and remaining GPU cards of the multiple nodes; determine multiple resource allocation rates for the multiple nodes based on the remaining CPU cores, remaining memory information, remaining GPU cards of the multiple nodes, total CPU cores, total GPU cards, and total memory information of the multiple nodes; and determine multiple initial resource fragment indices corresponding to the multiple nodes based on the multiple resource fragment counts and the multiple resource allocation rates. The aggregation unit is used to aggregate the multiple initial resource fragmentation indices to obtain the resource fragmentation index.

[0132] In some embodiments of this application, the device further includes a detection unit and a calibration unit; The acquisition unit 11 is used to acquire historical load information and determine dynamic sliding window parameters based on the historical load information. The determining unit 12 is used to determine initial load prediction information based on the dynamic sliding window parameters and the monitoring data using the load prediction model; and to determine the load prediction information based on the initial load prediction information, the detection information, and the correction information. The detection unit is used to perform second-order derivative detection on the initial load prediction information using the load prediction model to obtain detection information. The correction unit is used to perform error correction based on the monitoring data using the load prediction model to obtain correction information.

[0133] In some embodiments of this application, the apparatus further includes a screening unit and a migration unit; The filtering unit is configured to, when the resource fragmentation index is greater than or equal to a first preset index, filter out a first node from the target K8S cluster whose initial resource fragmentation index is greater than or equal to a second preset index; filter out migrateable pods from the first node; and filter out a second node from the target K8S cluster. The migration unit is used to migrate the pod to the second node.

[0134] It should be noted that, in practical applications, the aforementioned acquisition unit 11, determination unit 12, and execution unit 13 can be implemented by a processor 21 on an electronic device, specifically a CPU (Central Processing Unit), MPU (Microprocessor Unit), DSP (Digital Signal Processor), or Field Programmable Gate Array (FPGA), etc.; the aforementioned data storage can be implemented by a memory 22 on an electronic device.

[0135] This application also provides an electronic device, such as... Figure 7 As shown, the electronic device includes a processor 21, a memory 22, and a communication bus 23. The memory 22 communicates with the processor 21 through the communication bus 23. The memory 22 stores programs executable by the processor 21. When the program is executed, the processor 21 executes the scaling method of the K8S cluster as described above.

[0136] In practical applications, the aforementioned memory 22 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the processor 21.

[0137] This application provides a computer-readable storage medium having a computer program thereon, which, when executed by a processor 21, implements the scaling up and down method of the K8S cluster as described above.

[0138] This application also provides a computer program product, including a computer program that can be executed by a processor 21 in a K8S cluster scaling device to complete the steps described in the aforementioned K8S cluster scaling method.

[0139] Understandably, the scaling mechanism of a Kubernetes (K8S) cluster acquires monitoring data of the target K8S cluster and multiple sets of node resource information corresponding to multiple nodes within the target K8S cluster. Based on the load prediction model and the monitoring data, it determines the load prediction information of the target K8S cluster. Based on the multiple sets of node resource information, it determines the resource fragmentation index of the target K8S cluster. Then, based on the resource fragmentation index and the load prediction information, it determines a scaling plan for the target K8S cluster and executes the scaling plan to obtain a scaled-down target K8S cluster. This allows the received traffic to be processed directly based on the scaled-down target K8S cluster, eliminating the need to determine a scaling plan upon receiving traffic. This improves the efficiency of traffic processing.

[0140] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0141] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0142] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0143] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0144] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for scaling up and down a Kubernetes cluster, characterized in that, The method includes: Acquire monitoring data of the target K8S cluster and multiple sets of node resource information corresponding to multiple nodes in the target K8S cluster; Based on the monitoring data, the load prediction information of the target K8S cluster is determined using a load prediction model. Based on the multiple sets of node resource information, the resource fragmentation index of the target K8S cluster is determined; Based on the resource fragmentation index and the load prediction information, a scaling up / down scheme for the target Kubernetes cluster is determined; the scaling up / down scheme includes vertical scaling decisions, horizontal scaling decisions, and fragmentation management decisions. The scaling up / down scheme is executed on the target K8s cluster.

2. The method according to claim 1, characterized in that, The step of determining the scaling up / down scheme for the target Kubernetes cluster based on the resource fragmentation index and the load prediction information includes: When the resource fragmentation index is less than the first preset index and the load prediction value corresponding to the load prediction information is greater than the dynamic threshold, the remaining CPU cores of the multiple nodes, the remaining memory information of the multiple nodes, and the number of continuously available GPU cards of the multiple nodes are obtained. Based on the remaining CPU cores of the multiple nodes, the remaining memory information of the multiple nodes, and the number of continuously available GPU cards of the multiple nodes, the expansion parameters are determined; If the expansion parameter is greater than or equal to the preset expansion parameter, the expansion / shrinkage scheme is determined to be a vertical expansion decision in the expansion decision-making process. If the expansion parameter is less than the preset expansion parameter, the expansion / shrinkage scheme is determined to be a horizontal expansion decision and a fragmentation management decision in the expansion decision-making process. If the resource fragmentation index is less than the first preset index and the load prediction value is less than or equal to the dynamic threshold, the scaling up / down scheme is determined to be a scaling down decision.

3. The method according to claim 2, characterized in that, Before obtaining the remaining CPU cores, remaining memory information, and continuously available GPU cards for the multiple nodes when the resource fragmentation index is less than a first preset index and the load prediction value corresponding to the load prediction information is greater than a dynamic threshold, the method further includes: Obtain historical load information; Based on the historical load information, determine the historical load mean and historical load standard deviation; The dynamic threshold is determined based on the historical load mean and the historical load standard deviation.

4. The method according to claim 2, characterized in that, The process of executing the scaling up / down scheme on the target Kubernetes cluster includes: When the scaling-up / scaling scheme is the scaling-down decision, new monitoring data for the target K8S cluster is acquired after a preset time period. Based on the new monitoring data, the load prediction model is used to determine new load prediction information; If the new load prediction value corresponding to the new load prediction information is less than or equal to the dynamic threshold, the scaling down decision is executed on the target K8s cluster. When the scaling-up / scaling scheme is the scaling-up decision, the scaling-up decision is executed on the target K8s cluster.

5. The method according to claim 1, characterized in that, The determination of the resource fragmentation index of the target Kubernetes cluster based on the multiple sets of node resource information includes: From the multiple sets of node resource information, obtain the remaining CPU cores of multiple nodes, the remaining memory information of multiple nodes, the remaining GPU card number of multiple nodes, the total CPU cores of multiple nodes, the total GPU card number of multiple nodes, and the total memory information of multiple nodes; Based on the remaining CPU cores, remaining memory, and remaining GPUs of the multiple nodes, the counts of multiple resource fragments of the multiple nodes are determined. Based on the remaining CPU cores, remaining memory, remaining GPUs, total CPU cores, total GPUs, and total memory of the nodes, multiple resource allocation rates for the nodes are determined. Based on the multiple resource fragment counts and the multiple resource allocation rates, multiple initial resource fragment indices corresponding to the multiple nodes are determined; The multiple initial resource fragmentation indices are aggregated to obtain the resource fragmentation index.

6. The method according to claim 1, characterized in that, The process of using a load prediction model to determine the load prediction information of the target Kubernetes cluster based on the monitoring data includes: Obtain historical load information and determine dynamic sliding window parameters based on the historical load information; The initial load prediction information is determined using the load prediction model based on the dynamic sliding window parameters and the monitoring data. The initial load prediction information is detected by performing second derivative detection using the load prediction model to obtain detection information. The load prediction model is used to perform error correction based on the monitoring data to obtain correction information. The load prediction information is determined based on the initial load prediction information, the detection information, and the correction information.

7. The method according to claim 1, characterized in that, The step of determining the scaling up / down scheme for the target Kubernetes cluster based on the resource fragmentation index and the load prediction information further includes: If the resource fragmentation index is greater than or equal to the first preset index, select a first node from the target K8S cluster whose initial resource fragmentation index is greater than or equal to the second preset index; Filter the migrateable pods in the first node; Select a second node in the target Kubernetes cluster; Migrate the pod to the second node.

8. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 7.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images