A Multi-Factor Combined Intelligent Scheduling Method for Virtual Container Clusters

Abstract

This application relates to the fields of cloud computing and container orchestration technology, and in particular to an intelligent scheduling method for multi-factor combined virtual container clusters. The method includes: performing feature engineering on the historical load dataset of the target cluster to obtain a training set; establishing a combined load prediction model based on LSTM and LightGBM models; iteratively training the combined load prediction model using the training set to obtain a trained model; using the trained model to predict the target cluster; and automatically scaling the target cluster based on the predicted values ​​and a load prediction-based autoscaling strategy; and reallocating the resources of the target cluster based on the resource usage of the target cluster and a TOPSIS-based multi-dimensional resource scheduling algorithm. Data collection, load prediction, node scaling, and resource scheduling are all implemented using a self-designed Kubernetes extended scheduler.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of cloud computing and container orchestration, and in particular to a multi-factor combined virtual container cluster intelligent scheduling method. BACKGROUND

[0002] With the continuous development of computer technology, cloud computing has become a popular computing model to support the processing of large amounts of data using commercial computer clusters, which mainly has three service modes, namely Iaas (Infrastructure as a Service), Paas (Platform as a Service) and Saas (Software as a Service). With the increase of application size and complexity, the disadvantages of traditional monolithic applications have gradually emerged, such as low stability and low reliability, etc. Therefore, when building an application, microservice architecture becomes a better choice.

[0003] Microservice architecture is a divide-and-conquer method based on decomposition proposed to solve the increasing complexity of software in cloud environment. It advocates decomposing an application into a series of small services, each of which focuses on a single business function and runs in an independent and isolated environment. In a large-scale application system based on microservices, due to the large number of microservices and the ability to continuously evolve online, the dependency relationship of microservice runtime is complex. These characteristics make the resource management of microservice runtime face new challenges. Microservices have different loads at different times, and their resource needs are also different. In order to prevent the decline of service quality and resource waste, it is necessary to continuously modify the resources allocated to microservices, so as to supply reasonable resources to meet the needs of customers in response speed when facing different load pressures.

[0004] Before the emergence of container technology, microservice architecture mainly used virtualization technology for system deployment. In this way, the cluster implements resource allocation, expansion or reduction of application programs by adding, removing or migrating virtual machines. Creating a virtual machine instance requires running a complete operating system to obtain resource isolation, which takes a long time to start and costs a lot. The emergence of container technology provides a new solution to improve the efficiency of cloud resources. Containers on the same host share the same host kernel, which reduces the overhead caused by virtual machines in CPU, memory, etc. Containers are more lightweight and start extremely fast. Docker, as a tool for creating containers, has developed rapidly in recent years, bringing new opportunities and challenges to the field of cloud computing. Since Docker is simple and convenient for application development and deployment, and starts and stops quickly and occupies less resources, many domestic and foreign manufacturers have made great investment in cloud platforms based on Docker. However, Docker cannot provide advanced container management functions, and can only provide image creation, download, upload and container lifecycle management, etc. With the continuous increase of business, container cluster management systems are needed to manage containers.

[0005] To cope with the problems related to container management, some open source orchestration tools have appeared in the industry, such as Mesos of Apache, Kubernetes of Google, Docker Swarm of Docker, etc. Among them, the Kubernetes framework is one of the most famous container orchestration frameworks in academic and industrial fields, and has become the most popular open source container cluster scheduling system in the Docker ecosystem. Kubernetes has strong container orchestration capabilities, follows the microservice architecture theory, and can provide resource scheduling, deployment and running, service discovery, elastic scaling, updating and upgrading, etc. for containerized applications.

[0006] In the actual environment, the cluster server often has unpredictable load demand, so when the application has a huge access volume, the number of nodes needs to be quickly increased, and when the traffic decreases, the number of nodes needs to be reduced to reduce the cost. The current automatic scaling strategy of Kubernetes has certain limitations, and adjusting the number of instances according to the current load has a lag, and there is no timely and effective response to the situation of sudden increase in access volume and dynamic change in load. The default scheduling strategy of Kubernetes also has many deficiencies, for example, it cannot guarantee that the load of the cluster is in a balanced state after the cluster is elastically scaled, a single resource bottleneck may occur, and it can only allocate resources to the initially deployed resource objects, lacking certain dynamic migration strategy, so a large amount of resource fragments will be generated with the creation and destruction of containers, causing waste of resources. SUMMARY

[0007] In order to solve the above technical problems, the embodiments of the present application propose a multi-factor combined virtual container cluster intelligent scheduling method, which optimizes and improves the scheduling strategy of Kubernetes, adds a cluster automatic scaling strategy based on load prediction, thereby improving the resource utilization of the cloud platform and improving the performance of the cluster.

[0008] In order to achieve the above object, the embodiment of the present application proposes a multi-factor combined virtual container cluster intelligent scheduling method, which is suitable for containers using Kubernetes orchestration, and the method comprises the following steps: performing feature engineering on a historical load data set of a target cluster to obtain a training set, establishing a combined load prediction model based on an LSTM (Long Short Term Memory) model and a LightGBM (Light Gradient Boosting Machine) model, iteratively training the combined load prediction model to convergence using the training set to obtain a trained combined load prediction model; using the trained combined load prediction model to predict the future load rate of the target cluster, based on the predicted value output by the trained combined load prediction model, combining an automatic scaling strategy based on load prediction to perform automatic scaling processing on the target cluster, the automatic scaling processing including predictive expansion and predictive contraction; obtaining the resource usage of the target cluster, based on the resource usage of the target cluster, combining a multi-dimensional resource scheduling algorithm based on TOPSIS (Technique for Order Preference by Similarity to Ideal Solution) to determine the score of each candidate node, based on the score of each candidate node, reallocating the resources of the target cluster, and selecting appropriate Pods (the smallest schedulable and manageable basic unit in a Kubernetes cluster) for redeployment; wherein the data collection, load prediction, automatic scaling and resource scheduling are realized by a self-designed Kubernetes extension scheduler.

[0009] In order to achieve the above object, the embodiment of the present application further proposes a computer readable storage medium storing a computer program, which can implement the multi-factor combined virtual container cluster intelligent scheduling method as described above when executed by a processor.

[0010] Optionally, the feature engineering on the historical load data set of the target cluster to obtain the training set comprises:

[0011] The historical load data set of the target cluster is preprocessed, including missing abnormality processing, repeated abnormality processing, splitting processing and dimensionality reduction processing, to obtain a preprocessed historical load data set;

[0012] The preprocessed historical load data set is subjected to feature engineering to obtain the training set; wherein the feature engineering constructs the training set from three aspects, namely time series features, cross features and aggregation features;

[0013] The combination load prediction model is established based on the LSTM model and the LightGBM model, the combination load prediction model is iteratively trained to convergence by using the training set, and the trained combination load prediction model is obtained, including:

[0014] The LSTM model and the LightGBM model are combined to establish the combination load prediction model, the LSTM model uses time sequence features as input for training, the LightGBM model uses network parameters after training of the LSTM model, time sequence features, cross features and aggregated features as input for training, and the trained combination load prediction model is obtained after both are trained to meet the preset convergence condition.

[0015] The network structure of the LSTM model is composed of an LSTM layer and multiple fully connected layers, and each layer is provided with BatchNorm normalization and DropOut regularization.

[0016] Optionally, the prediction type expansion includes:

[0017] The trained combination load prediction model is used to predict the load rate of the target cluster at five future time points, if the predicted values of at least three time points are greater than the preset upper threshold of the load rate, it is determined that the load rate of the future target cluster is too high, and expansion operation is needed.

[0018] Let the required number of nodes in the future be , the number of nodes to be added be , and are represented as:

[0019] ;

[0020] ;

[0021] wherein, represents the current number of nodes, represents the current load rate, represents the maximum value in the predicted values of the five future time points.

[0022] After determining the number of nodes to be added, the Pod migration queue needs to be further determined, the no-migration principle is adopted for the Pods with service state, and the partial migration principle is adopted for the Pods without service state.

[0023] Based on CPU (Central Processing Unit) utilization, memory utilization, disk utilization and bandwidth utilization, the node load rate of each node is calculated, and the node whose node load rate is greater than the average load rate of the cluster is determined as a high load node;

[0024] From each high load node, select Pods in a serviceless state, which The sum of the load rates of the selected Pods in a serviceless state is not greater than the absolute value of the difference between the load rate of the high load node and the average load rate of the cluster.

[0025] Sort all selected Pods in a serviceless state in descending order of load rate, and further select Pods in a serviceless state with a load rate in the top , to form a migration queue of Pods.

[0026] Optionally, the predictive scaling includes:

[0027] Using the trained combined load prediction model to predict the load rate of the target cluster at five future time points, if the predicted values at the five time points are all less than the preset lower load rate threshold, and the load rate at the current time point is also less than the preset lower load rate threshold, it is determined that the load rate of the future target cluster is too low, and scaling operation is needed;

[0028] Traverse each node of the target cluster, calculate the load rate of the target cluster after deleting the current node, if the load rate of the target cluster after deleting the current node is less than the preset upper load rate threshold, then migrate all pods running on the current node, and after migration, recycle the resources of the current node, complete the scaling of the current node;

[0029] When migrating Pods in a service state across nodes, first unload the Pods in a service state from the current node, then separate the disk directories Volumes that can be shared by multiple containers from the current node, then reattach the Volumes on the new node, and finally mount the Pods in a service state to the new node.

[0030] Optionally, the obtained resource usage of the target cluster includes CPU utilization, memory utilization, disk utilization, bandwidth utilization and node container quantity, a total of five indicators;

[0031] Based on the resource usage of the target cluster, combined with the multi-dimensional resource scheduling algorithm based on TOPSIS, the scores of each candidate node are determined, including:

[0032] Based on the number of network I / O requests made by the Pod and the network I / O usage of the cluster nodes, nodes with remaining bandwidth less than the preset remaining bandwidth threshold are filtered out, and the remaining nodes are selected as candidate nodes.

[0033] Construction by The decision matrix consists of the number of candidate nodes and 5 standard numbers. The five standard numbers correspond to the five indicators mentioned above, and the decision matrix is... This can be expressed by the formula:

[0034] ;

[0035] in, Indicates the first CPU utilization of each candidate node Indicates the first Memory utilization of each candidate node. Indicates the first Disk utilization of each candidate node, Indicates the first Bandwidth utilization of each candidate node, Indicates the first The number of containers within each candidate node;

[0036] Using the reciprocal method, the decision matrix is... The value of each item in the matrix is ​​positiveized to obtain the positiveized decision matrix. ;

[0037] The decision matrix after positive transformation The value of each item in the matrix is ​​normalized to obtain the normalized decision matrix. ;

[0038] The normalized decision matrix The scores are input into the TOPSIS algorithm to obtain the score matrix of each candidate node. Rating matrix This can be expressed by the formula:

[0039] ;

[0040] in, Indicates the first The scores of each candidate node, indicated in the upper right corner. This indicates the transpose operation.

[0041] Optionally, resources in the target cluster are reallocated based on the scores of each candidate node, and suitable Pods are selected for redeployment, including:

[0042] Define a variable representing the node with the highest score when a new Pod is created ;

[0043] Based on the score matrix Traverse each candidate node, if the score of the current candidate node is higher than , replace with the current candidate node, otherwise directly compare the next candidate node;

[0044] After completing the traversal of all candidate nodes, the optimal candidate node with the highest score is obtained, and the new Pod is deployed to the optimal candidate node.

[0045] Optionally, the extended scheduler is implemented in the form of a scheduling framework, which defines a set of extension points, supports customizing scheduling logic by implementing the interfaces defined by the extension points, and registers the extensions on the extension points;

[0046] Each time a Pod is scheduled, it is divided into two stages, namely the scheduling period and the binding period. The scheduling period is for Pod node selection, and the binding period is for applying the decision to the target cluster. The scheduling period and the binding period together are called the scheduling context.

[0047] The extension points include at least Filter extension points (filtering extension points) and Score extension points (score extension points). The Filter extension points are used to exclude nodes that cannot run the Pod, which is equivalent to the pre-selection stage. The Score extension points are used to score all candidate nodes, and the score result is an integer in a range, which is equivalent to the optimal selection stage. The same plugin is allowed to be registered on multiple extension points to perform complex or stateful tasks.

[0048] When initializing the scheduler, a profile is automatically created. The profile is a definition related to the scheduling configuration of the scheduler, and its implementation is KubeSchedulerProfile, which is the configuration passed in when generating a YAML file. To implement a custom scheduling plugin, you need to register the written custom algorithm in the target cluster and recompile the Scheduler. Finally, configure the KubeSchedulerConfiguration object in Kubernetes to insert the scheduling plugin to be used.

[0049] Optionally, the extended scheduler is independent of the default scheduler of Kubernetes, and is composed of four parts: a data collection module, a load prediction module, an automatic scaling module, and a resource scheduling module.

[0050] The data collection module is implemented by running Prometheus in the target cluster, and is responsible for load monitoring of the target cluster, including node resource usage monitoring and Pod container resource usage monitoring, obtaining resource usage of the target cluster, and collecting, analyzing and storing historical load data of the target cluster;

[0051] The load prediction module is packaged in the form of a container and runs in the target cluster, is responsible for feature engineering on a historical load data set of the target cluster to obtain a training set, iteratively trains a combined load prediction model using the training set until convergence, obtains a trained combined load prediction model, and uses the trained combined load prediction model to predict future load rates of the target cluster;

[0052] The automatic scaling module is responsible for automatic scaling processing of the target cluster based on the prediction value output by the trained combined load prediction model and a load prediction-based automatic scaling strategy, and the automatic scaling processing includes predictive scaling and predictive scaling;

[0053] The resource scheduling module is responsible for determining the scores of each candidate node based on the resource usage of the target cluster and a TOPSIS-based multi-dimensional resource scheduling algorithm, and reallocating resources of the target cluster based on the scores of each candidate node to select appropriate Pods for redeployment.

[0054] Optionally, the data collection module builds a resource monitoring component based on Prometheus, and monitors resources in a combination of Node-Exporter, cAdvisor, Prometheus and Grafana;

[0055] The Node-Exporter component is responsible for obtaining resource usage information of worker nodes in the target cluster, and the selected monitoring points include cpu, meminfo, diskstats and netstat, which monitor CPU utilization, memory utilization, disk utilization and bandwidth utilization, respectively. The cAdvisor component is responsible for monitoring and collecting container resources in the Pod. The InfluxDB time series database is used to implement persistent storage of load time series data. The Prometheus component is responsible for collecting node load index data, and sets the collection period by modifying the configuration file of Prometheus to periodically count and store in InfluxDB. The Grafana component is responsible for visualizing the monitoring data;

[0056] The Node-Exporter component is deployed in the worker nodes in the form of a DaemonSet, and cAdvisor is integrated in the Kubelet as the default startup item of Kubernetes. The data collected by the two is analyzed by Prometheus and stored in the time series database InfluxDB. The data obtained after analysis is displayed on the web page through Grafana.

[0057] When monitoring, data requests are made through the HTTP API interface provided by Prometheus. After receiving the data request, Prometheus processes the request and returns the request data in JSON format. The resource monitoring component then decodes, analyzes and stores the data for use by other components.

[0058] The multi-factor combined virtual container cluster intelligent scheduling method proposed by the embodiments of the present application has at least the following advantages compared with the default scheduling strategy of Kubernetes.

[0059] First, due to the complexity of the actual situation in the cloud environment, the cluster often suddenly faces a sharp increase in traffic. If not controlled, it is easy to cause problems such as insufficient cluster resources. The fundamental solution is to expand and shrink the node granularity to provide more server resources to maintain the stability of the entire cluster. Therefore, the load prediction proposed in the present application aims to provide a basis for the automatic scaling of the target cluster. The expansion is performed before the traffic arrives to ensure service quality, and the scaling is performed when the traffic is small to save resources. The present application combines the LightGBM model and the LSTM model to fully utilize the advantages of the two models, so that the prediction accuracy of the combined load prediction model is effectively improved, and the prediction performance can be guaranteed.

[0060] Second, TOPSIS is a multi-criteria decision analysis algorithm that can optimize the optimization stage. The present application comprehensively considers the CPU utilization, memory utilization, disk utilization, bandwidth utilization and node container quantity of the target cluster. Based on the multi-dimensional resource scheduling algorithm of TOPSIS, the score of each candidate node is determined, the resources of the target cluster are redistributed based on the score, and the appropriate Pod is selected for redeployment, effectively improving the overall resource balance of the target cluster and avoiding resource skew of the cluster nodes and single resource bottleneck.

[0061] Thirdly, the application designs and implements an extended scheduler of Kubernetes, the implementation of the extended scheduler provides running support for the scheduling method, and can effectively run in the cluster. After the architecture and modules of the scheduler are designed, the extended scheduler is developed using the Go language, and is successfully run in the built cluster. Since the extended scheduler can perform automatic scaling in advance, the cluster is more stable, and compared with the default scheduling of Kubernetes, the load balancing of the cluster can be effectively improved. BRIEF DESCRIPTION OF DRAWINGS

[0062] In order to more clearly illustrate the technical solutions in the embodiments of the application or the related art, the drawings needed to be used in the description of the embodiments of the application or the related art will be briefly introduced. Obviously, the following drawings are only some embodiments of the application, and for those skilled in the art, other drawings can be obtained without creative labor based on these drawings. The drawings described herein are only used to explain the application, and are not used to limit the application.

[0063] Figure 1 is a flowchart of a multi-factor combined virtual container cluster intelligent scheduling method provided in an embodiment of the application;

[0064] Figure 2 is a structure diagram of a combined load prediction model provided in an embodiment of the application;

[0065] Figure 3 is a general design diagram of a resource scheduling strategy provided in an embodiment of the application;

[0066] Figure 4 is a flowchart of cluster automatic scaling processing provided in an embodiment of the application;

[0067] Figure 5 is a schematic diagram of a scheduling context of a Pod and an extension point disclosed by a scheduling framework provided in an embodiment of the application;

[0068] Figure 6 is a whole architecture diagram of an extended scheduler provided in an embodiment of the application;

[0069] Figure 7 is a functional module division diagram of an extended scheduler provided in an embodiment of the application;

[0070] Figure 8 is an architecture diagram of a data collection module provided in an embodiment of the application;

[0071] Figure 9 is a working principle diagram of a load prediction module provided in an embodiment of the application;

[0072] Figure 10 is a working principle diagram of an automatic expansion module provided in an embodiment of the present application;

[0073] Figure 11 is a working principle diagram of a resource scheduling module provided in an embodiment of the present application. DETAILED DESCRIPTION

[0074] In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below with reference to the drawings. Those skilled in the art can understand that, in the embodiments of the present application, many technical details are proposed in order to make the readers better understand. However, the technical solutions claimed by the present application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present application. The following embodiments can be combined and referenced with each other without contradiction.

[0075] An embodiment of the present application proposes a multi-factor combined virtual container cluster intelligent scheduling method, which is suitable for containers using Kubernetes orchestration. The implementation details of the multi-factor combined virtual container cluster intelligent scheduling method proposed in the embodiment will be described in detail below. The following content only provides implementation details for easy understanding, and is not essential for implementing the present solution.

[0076] The specific process of the multi-factor combined virtual container cluster intelligent scheduling method proposed in the embodiment can be as shown in Figure 1 , including:

[0077] Step 11: Feature engineering is performed on the historical load data set of the target cluster to obtain a training set. A combined load prediction model is established based on an LSTM model and a LightGBM model. The training set is used to iteratively train the combined load prediction model until convergence, and a trained combined load prediction model is obtained.

[0078] In a specific implementation, the basis for resource scheduling is correct load prediction, and accurate load prediction needs to rely on a powerful combined load prediction model. Since the numerical variables in the data set have been rounded, the originally relatively dense variables become sparse, and the LightGBM model has a natural advantage for sparse variables, so the LightGBM model is selected to model the data. In addition, since the LSTM model has good ability to capture advanced time series data patterns, the embodiment selects advanced network parameters as features, and after training, the parameters in the network are put into the lightGBM model as features. First, collect the historical load data of the target cluster to form the historical load set of the target cluster. Then, feature engineering is performed on the historical load data set of the target cluster to obtain the training set. Next, based on the LSTM model and the LightGBM model, a combined load prediction model is established, and the training set is used to iteratively train the combined load prediction model until convergence, obtaining the trained combined load prediction model. Compared with the mainstream load prediction model, the prediction method combining the two models has higher accuracy.

[0079] In one example, the structure of the combined load prediction model is as shown in Figure 2 The data processing includes pre-processing of the data and mining of effective feature combinations (feature engineering). First, the historical load data set of the target cluster is pre-processed, including missing anomaly processing, repeated anomaly processing, splitting processing and dimensionality reduction processing, to obtain the pre-processed historical load data set. Next, feature engineering is performed on the pre-processed historical load data set to obtain the training set. Feature engineering constructs the training set from three aspects: time series features, cross features, and aggregation features. In terms of model combination, the LSTM model and the LightGBM model are combined to establish a combined load prediction model. The LSTM model uses time series features as input for training, and the LightGBM model uses network parameters from the LSTM model after training, time series features, cross features and aggregation features as input for training. After both are trained to meet the preset convergence condition, the trained combined load prediction model is obtained.

[0080] The network structure of the LSTM model is composed of an LSTM layer and multiple fully connected layers. In this embodiment, 7 fully connected layers are added to the LSTM model. Although this increases the fitting ability of the LSTM model for nonlinear models, the convergence speed during training is also slowed down as the network depth increases. This is because the activation input value before nonlinear transformation of the deep neural network gradually deviates or changes during the training process as the network depth increases. The reason for slow training convergence is that the overall distribution gradually approaches the upper and lower limits of the value range of the nonlinear function, resulting in gradient disappearance of the low-level neural network during back propagation. This is the essential reason for the slow convergence of deep neural networks. Therefore, BatchNorm normalization is added to each layer of the network in this embodiment. BatchNorm normalization normalizes the distribution of input values of any neuron in each layer of the neural network to a standard normal distribution with a mean of 0 and a variance of 1, so that the activation input value falls in the region where the nonlinear function is sensitive to input. Therefore, small changes in input will result in large changes in loss function, thus greatly improving the training speed, accelerating the convergence process, simplifying the parameter adjustment process, and reducing the training difficulty of the LSTM model. In addition, to prevent overfitting of the LSTM model, DropOut regularization is added to each layer. DropOut regularization is a neural network regularization technique that temporarily discards neural network units from the network according to a specified probability during model training. During training, the PReLu activation function can avoid the problem of gradient disappearance caused by deep networks. The initial learning rate is set to 0.001, and the Adam optimizer is used to adjust the learning rate to avoid the model falling into a local minimum.

[0081] In the control and optimization process of the LightGBM model, the number of leaves num_leaves, learning rate, minimum data amount in leaves, metric function, number of parallel threads num_threads, bagging fraction (sample sampling), feature fraction (feature subsampling), and other parameters are controlled, among which feature_fraction and bagging_fraction can speed up the training and control the overfitting phenomenon.

[0082] Step 12, using the trained combined load prediction model to predict the load rate of the target cluster, based on the prediction value output by the trained combined load prediction model, combining the automatic scaling strategy based on load prediction, to perform automatic scaling processing on the target cluster.

[0083] In a specific implementation, after the historical load data of the target cluster is analyzed, the predicted value of the load is used to automatically scale the target cluster. After the cluster is scaled up or scaled down, more reasonable utilization of cluster resources is achieved. Therefore, the Pod resource object in the cluster needs to be redeployed, that is, migrated to a more suitable node. Therefore, the embodiment designs a suitable resource scheduling strategy (as shown in FIG. 8) for the two problems of automatic scaling and Pod migration. In step 12, the automatic scaling part is first introduced. After obtaining the trained combined load prediction model, the trained combined load prediction model can be used to predict the load rate of the target cluster. Based on the predicted value output by the trained combined load prediction model, the automatic scaling strategy based on load prediction is used to automatically scale the target cluster. The automatic scaling process includes predicted expansion and predicted contraction. Figure 3

[0084] When facing a traffic flood, the load of resources will also rise, which can easily cause access congestion or system crash and other problems, thereby causing huge losses. When the system access volume decreases, resource idling may occur, causing waste of resources. Therefore, the cluster needs to be able to dynamically respond to changes in load. The elastic scaling mode is usually divided into increase or decrease of resources at the Pod level and the node level. When elastic scaling is needed, the capacity planning at the application level is changed first. After the new container replica is deployed to the node, the resources of the node may sometimes fluctuate sharply. In this case, if the container replica is not limited, CPU, memory and other resources may be consumed, thereby causing the server to crash. Therefore, when the cluster faces a sudden traffic surge, resource shortage and other problems may occur. To solve the problem of resource changes when the cluster cannot cope with the sudden traffic surge, the fundamental solution is to scale the cluster from the node granularity to provide more server resources and maintain the stability of the entire cluster.

[0085] To cope with the upcoming sudden traffic surge, the resource scheduling strategy proposed in the embodiment is based on the automatic scaling technology of the cluster, which provides more resources for the container platform from the node granularity scaling, thereby fundamentally solving the problem of resource shortage caused by the sudden traffic surge.

[0086] The cluster automatic scaling strategy based on load prediction is the basis for realizing dynamic resource scheduling. According to the output result of the combined load prediction model, the future cluster load situation is analyzed to determine whether scaling up or down is needed. For scaling up, the number of scaling up is calculated based on the result of load prediction. For scaling down, only one node is selected for removal at a time. After the cluster is increased in nodes and before the node is removed, the Pod needs to be selected for migration to maintain the balanced use of cluster resources.

[0087] ​Generally, before the cluster is automatically scaled, a trigger signal needs to be given to the CA component, i.e., when the scaling of the cluster is triggered. After the cluster is automatically scaled, the number of nodes is increased or decreased, and when the number of nodes in the cluster is increased or decreased, the problem of pod migration and pod target node selection needs to be considered inevitably.

[0088] The cluster needs to reach the corresponding scaling condition, and the scaling trigger condition set in the embodiment is that the load metric value of a certain worker node reaches a set threshold. The cluster load threshold can be adjusted manually. When the predicted load metric value reaches the upper threshold, the cluster needs to be expanded, and when the lower threshold is reached, the cluster needs to be contracted. The principle and process of the cluster automatic scaling processing can be as shown in Figure 4

[0089] In an example, when the predicted cluster load rate triggers the upper threshold, it indicates that the resources in the cluster will be consumed soon, and the cluster needs to be expanded. However, there is a certain difference between the predicted cluster load and the real cluster load, and triggering the threshold at a time point may cause the cluster load to suddenly reach a peak value at a future moment, but it will soon drop to a normal range, and in this case, the cluster does not need to be expanded.

[0090] Based on this, the combined load prediction model trained is used to predict the load rate of the target cluster at five future time points, and if the predicted values corresponding to at least three time points are greater than the preset upper threshold of the load rate, it is determined that the load rate of the future target cluster is too high, and the expansion operation needs to be performed.

[0091] Let the number of nodes required in the future be , the number of nodes to be added be , and be represented as:

[0092] ;

[0093] ;

[0094] Among them, represents the current number of nodes, represents the current load rate, represents the maximum value in the predicted values corresponding to the five future time points.

[0095] ​After determining the number of nodes that need to be increased, it is further necessary to determine the migration queue of the pods, that is, which pods need to be migrated. There are stateful services and stateless services in Kubernetes. The stateless service does not store persistent data locally, and multiple service instances are completely consistent in responding to the same user request, so dynamically starting and stopping the pods of the stateless service will not affect other pods. The stateful service needs to store persistent data locally, and there is a dependent topology relationship between node instances. If any instance pod in the cluster is stopped, it may cause data loss. Therefore, two points need to be noted when migrating pods: first, the pods of stateful services and the pods of stateless services need to be distinguished. Since the migration process of the pods of stateful services takes a long time and needs to be performed on each affected container, in order to save the migration time, the principle of not migrating the pods of stateful services is adopted, and mainly the pods of stateless services are migrated; second, cluster resources need to be consumed when migrating pods, so as to select as few pods as possible for migration, and therefore the principle of partially migrating the pods of stateless services is adopted.

[0096] When determining the migration queue of the pods, first, the node load rate of each node is calculated based on the CPU utilization, memory utilization, disk utilization and bandwidth utilization, and the nodes with a node load rate greater than the average load rate of the cluster are determined as high-load nodes. Next, from each high-load node, a number of stateless pods are selected The sum of the load rates of the stateless pods is not greater than the absolute value of the difference between the load rate of the high-load node and the average load rate of the cluster. Finally, all the selected stateless pods are sorted in descending order of load rate, and the stateless pods with a load rate in the top are further selected to form the migration queue of the pods.

[0097] In an example, if the predicted values corresponding to the five time points are all less than the preset lower threshold of the load rate, and the load rate of the current time point is also less than the preset lower threshold of the load rate, it is determined that the load rate of the future target cluster is too low, and a scaling operation needs to be performed. At this time, each node of the target cluster is traversed, the load rate of the target cluster after deleting the current node is calculated, and if the load rate of the target cluster after deleting the current node is less than the preset upper threshold of the load rate, all the pods running on the current node are migrated, and after the migration is completed, the resources of the current node are recycled, and the scaling of the current node is completed.

[0098] When the Pod with service state is migrated across nodes, the Pod with service state is first unloaded from the current node, then the disk directory volumes shared by multiple containers are separated from the current node, then the volumes are reattached on the new node, and finally the Pod with service state is mounted on the new node.

[0099] Generally, in the process of automatic scaling of the cluster, first, the historical load data of the cluster is analyzed, and whether the conditions for expansion or contraction are reached is judged according to the predicted results. If the expansion condition is reached, first, the number of nodes to be increased is calculated, and the nodes in the node pool are added to the cluster as worker nodes, and then the target node selection of the Pod, the selection of the migrated Pod and the Pod migration are performed. If the contraction condition is reached, first, the load rate of each worker node in the cluster is calculated, and all the Pods in the nodes with a load rate less than the lower threshold are migrated, and the node resources are recycled after the migration is completed.

[0100] In step 13, the resource usage of the target cluster is obtained, the scores of the candidate nodes are determined based on the resource usage of the target cluster and the multi-dimensional resource scheduling algorithm based on TOPSIS, the resources of the target cluster are redistributed based on the scores of the candidate nodes, and appropriate Pods are selected for redeployment.

[0101] In a specific implementation, the resources in the cluster are diverse, in addition to CPU and memory, there are disk, network card bandwidth and other resources, and the default scheduling strategy of Kubernetes only considers CPU and memory, so it cannot be applied to more complex scenarios. In actual use, the multi-dimensional resource usage is considered comprehensively, and the balance of the utilization of each dimension resource is taken into account, so that a scientific scheduling decision can be made. The cluster scaling scheme is proposed from the node granularity, and the multi-dimensional resource scheduling algorithm based on TOPSIS is proposed. Through the collection and storage of the cluster load data, first, the load prediction is performed, then the automatic scaling of the cluster is performed in combination with the proposed cluster scaling scheme, and then the resource scheduling algorithm based on TOPSIS is combined, the multi-dimensional resource usage is considered comprehensively, that is, the CPU utilization, memory utilization, disk utilization, bandwidth utilization and the number of containers in the node and other multiple indexes of the candidate nodes are considered, the scores of the candidate nodes are determined according to the multi-dimensional resource allocation and the actual usage of each node, the resources of the target cluster are redistributed based on the scores of the candidate nodes, and appropriate Pods are selected for redeployment, so that the best node is selected for each newly created or migrated Pod, and the load balancing and resource utilization of the cluster are improved.

[0102] In one example, node filtering is the first step. Based on the Pod's network I / O requests and the network I / O usage of cluster nodes, nodes with remaining bandwidth less than a preset remaining bandwidth threshold are filtered out. To prevent excessively high usage of any metric on a node, CPU utilization, memory utilization, disk utilization, and bandwidth utilization are also filtered. An upper limit of 80% is set for the utilization of each resource. If the utilization of any resource on a node exceeds the upper limit, that node is filtered out, and the remaining nodes are the candidate nodes.

[0103] In applying the TOPSIS algorithm, the core step is to construct an input matrix for the five indices and then perform standardization calculations. First, a matrix is ​​constructed from the five indices... The decision matrix consists of the number of candidate nodes and 5 standard numbers. The five standard numbers correspond to the five indicators mentioned above, and the decision matrix is... This can be expressed by the formula:

[0104] ;

[0105] in, Indicates the first CPU utilization of each candidate node Indicates the first Memory utilization of each candidate node. Indicates the first Disk utilization of each candidate node, Indicates the first Bandwidth utilization of each candidate node, Indicates the first The number of containers within each candidate node.

[0106] Next, we will use the reciprocal method to process the decision matrix. The value of each item in the matrix is ​​positiveized to obtain the positiveized decision matrix. .

[0107] Then, the decision matrix after positive transformation... The value of each item in the matrix is ​​normalized to obtain the normalized decision matrix. The decision matrix after normalization. This can be expressed by the formula:

[0108] ;

[0109] in, Indicates the first CPU utilization after normalization of candidate nodes Indicates the first Memory utilization of the i-th candidate node after normalization, Disk utilization of the i-th candidate node after normalization, Bandwidth utilization of the i-th candidate node after normalization, Node container quantity of the i-th candidate node after normalization, Node container quantity of the i-th candidate node after normalization, Node container quantity of the i-th candidate node after normalization, Node container quantity of the i-th candidate node after normalization.

[0110] Finally, the normalized decision matrix is input into the TOPSIS algorithm to obtain the scoring matrix of each candidate node , and the scoring matrix is expressed by the formula as follows:

[0111] ;

[0112] wherein, the score of the i-th candidate node is represented by , and the upper right corner mark represents the transpose operation.

[0113] When a new Pod is created, a variable representing the node with the highest score is defined . Subsequently, based on the scoring matrix , each candidate node is traversed, and if the score of the current candidate node is higher than , the current candidate node is replaced by , otherwise the next candidate node is directly compared. After completing the traversal of all candidate nodes, the optimal candidate node with the highest score is obtained, and the new Pod is deployed to the optimal candidate node.

[0114] To support the resource scheduling strategy proposed in this embodiment, the Kubernetes extension scheduler is also designed and developed by the embodiment based on the implementation manner of the Kubernetes extension scheduler, so as to realize data collection, load prediction, automatic scaling and resource scheduling.

[0115] The embodiment realizes the extension scheduler (customized scheduler) in the manner of scheduling framework. The scheduling framework defines a set of extension points, supports customizing scheduling logic by implementing the interface defined by the extension point, and registers the extension on the extension point, Figure 5 which shows the Pod scheduling context and the extension point in the scheduling framework.

[0116] Scheduling one Pod at a time is divided into two stages, namely the scheduling period and the binding period. The scheduling period is for Pod to select a node, and the binding period is for applying the decision to the target cluster. The scheduling period and the binding period together are called the scheduling context. ​​​

[0117] The extension points include at least a Filter extension point and a Score extension point, the Filter extension point is used to exclude nodes that cannot run the Pod, which is equivalent to the pre-selection stage, and the Score extension point is used to score all candidate nodes, and the score result is an integer in a range, which is equivalent to the preferred stage, and the same plug-in allows registration on multiple extension points to perform complex or stateful tasks.

[0118] When the scheduler is initialized, a profile is automatically created, the profile is a definition related to the scheduling configuration of the scheduler, and the implementation is KubeSchedulerProfile, that is, the configuration passed in when the YAML file is generated, to implement a custom scheduling plug-in, the custom algorithm written needs to be registered in the target cluster and the Scheduler is recompiled, and finally the KubeSchedulerConfiguration object is configured in Kubernetes to insert the scheduling plug-in to be used. This process can be as shown in Figure 6 .

[0119] The extended scheduler is independent of the default scheduler of Kubernetes, as shown in Figure 7 , and is composed of four parts of a data collection module, a load prediction module, an automatic scaling module and a resource scheduling module.

[0120] The data collection module is implemented by running Prometheus in the target cluster, and is responsible for load monitoring of the target cluster, including node resource usage monitoring and Pod container resource usage monitoring, obtaining resource usage of the target cluster, and collecting, analyzing and storing historical load data of the target cluster.

[0121] To realize load prediction of the container cluster and automatic scaling based on the prediction, the first step is to monitor the container cluster. By monitoring the cluster load indicators, historical load data can be stored to provide data support for load prediction and automatic scaling.

[0122] Since the embodiment studies node granularity scaling, it is necessary to monitor the resource usage information of the cluster nodes. There are many mature solutions for node monitoring, such as Nagios, Zabbix, etc. Zabbix is more suitable for monitoring physical machine environments, and Prometheus is more suitable for monitoring cloud environments. Therefore, the embodiment selects to build a resource monitoring system based on Prometheus.

[0123] In order to make the monitoring system as complete as possible, the embodiment adopts the combination of Node-Exporter, cAdvisor, Prometheus, Grafana and other components to monitor the resources.

[0124] The Node-Exporter component is responsible for obtaining the resource usage information of the worker nodes in the target cluster, and the selected monitoring points include cpu, meminfo, diskstats and netstat, which monitor CPU utilization, memory utilization, disk utilization and bandwidth utilization respectively. The cAdvisor component is responsible for monitoring and collecting data of container resources in the Pod. The InfluxDB time series database is used to realize the persistent storage of load time series data. The Prometheus component is responsible for collecting node load index data, and the collection period is set by modifying the configuration file of Prometheus, so as to periodically count and store in InfluxDB. The Grafana component is responsible for visualizing the monitoring data.

[0125] The overall architecture of the data collection module is shown in Figure 8 The Node-Exporter component is deployed in the worker node in the form of DaemonSet, and cAdvisor is integrated in Kubelet as the default startup item of Kubernetes. The data collected by the two is analyzed by Prometheus and stored in the time series database InfluxDB. The data obtained after analysis is displayed through Grafana from the web end. During monitoring, data requests are made through the HTTP API interface provided by Prometheus. After receiving the data request, Prometheus processes the request and returns the request data in JSON format. The resource monitoring component decodes, analyzes and stores the data for use by other components.

[0126] The load prediction module is packaged in the form of a container and runs in the target cluster. It is responsible for feature engineering on the historical load data set of the target cluster to obtain a training set. The training set is used to iteratively train the combined load prediction model until convergence to obtain a trained combined load prediction model. The trained combined load prediction model is used to predict the future load rate of the target cluster.

[0127] The load prediction module reads the historical load data of the cluster from InfluxDB. InfluxDB is written in GO language, and the database is operated through the SQL-like statements of InfluxDB. After obtaining the historical load data of the cluster, the prediction is performed according to the load prediction algorithm proposed in the embodiment. The prediction result is used by the automatic scaling module to calculate the number of scaling nodes. The prediction process is shown in Figure 9The load prediction module is packaged in the form of a container and runs in the cluster. The module performs data preprocessing on the historical load data obtained, trains the model, predicts the resource load of the cluster at the next five time points, and finally stores the prediction results in a time series database for the automatic scaling module to obtain and call.

[0128] The automatic scaling module is responsible for automatically scaling the target cluster based on the prediction values output by the trained combined load prediction model and the automatic scaling strategy based on load prediction. The automatic scaling process includes predictive scaling and predictive scaling.

[0129] The automatic scaling module reads the results of the load prediction module in the database, calculates using the automatic scaling strategy proposed in this embodiment, and performs automatic scaling on the cluster using the CA component according to the calculation results. After scaling, the pods running in the node need to be migrated. Similarly, before removing the node, i.e., scaling down, all pods on the node also need to be migrated. The specific process is as shown in Figure 10 .

[0130] The resource scheduling module is responsible for determining the scores of each candidate node based on the resource usage of the target cluster and the multi-dimensional resource scheduling algorithm based on TOPSIS, and reallocating the resources of the target cluster based on the scores of each candidate node to select appropriate pods for redeployment.

[0131] The resource scheduling module is the core part of the extended scheduler developed in this embodiment, which is responsible for finding the optimal target node for the Pod queue. It can run a custom scheduling algorithm to return the results to the scheduler. The extended scheduler designed in this embodiment is mainly used to verify the scheduling algorithm proposed in this embodiment, so it can run the multi-dimensional resource scheduling algorithm based on TOPSIS. In addition, after the preselection and optimization algorithms of the resource scheduling module run, the most suitable node can be allocated for the Pod queue to be scheduled, and the allocation result can be written into ETCD (an open source distributed key-value storage system). The preselection stage can filter out nodes that do not meet the conditions at the beginning, and the optimization stage is used to score the nodes after preselection. The node with the highest score is the most suitable node to deploy pods, so the pods are bound to this node. The workflow of the resource scheduling module is as shown in Figure 11 .

[0132] The multi-factor combined virtual container cluster intelligent scheduling method proposed in this embodiment has at least the following advantages compared to the traditional Kubernetes default scheduling strategy.

[0133] Firstly, due to the actual situation in the cloud environment is more complex, the cluster will often suddenly face the surge of traffic, if not controlled, it is easy to appear cluster resource shortage and other problems, the fundamental solution is to carry out node granularity expansion and contraction, to provide more server resources to maintain the stability of the entire cluster. Therefore, the load prediction proposed in the application aims to provide the basis for the automatic scaling of the target cluster, to ensure service quality by expanding before traffic arrives, and to save resources by scaling down when traffic is small. The application combines LightGBM model and LSTM model, fully utilizes the advantages of the two models, so that the prediction accuracy of the combined load prediction model is effectively improved, and the prediction performance can be guaranteed.

[0134] Secondly, TOPSIS is a multi-criteria decision analysis algorithm that can optimize the optimization stage. The application comprehensively considers the CPU utilization, memory utilization, disk utilization, bandwidth utilization and node container quantity of the target cluster, determines the score of each candidate node based on the multi-dimensional resource scheduling algorithm of TOPSIS, reallocates the resources of the target cluster based on the score, selects appropriate Pods for redeployment, effectively improves the overall resource balance of the target cluster, and avoids resource tilt of the cluster nodes and single resource bottleneck.

[0135] Thirdly, the application designs and implements an extended scheduler of Kubernetes, and the implementation of the extended scheduler provides running support for the scheduling method and can effectively run in the cluster. After designing the architecture and modules of the scheduler, it is developed using Go language, and the extended scheduler is successfully run in the built cluster. Since the extended scheduler can perform automatic scaling in advance, the cluster is more stable, and compared with the default scheduling of Kubernetes, the load balancing of the cluster can be effectively improved.

[0136] The step division of the above methods is only for clear description, and can be combined into one step or some steps can be divided into multiple steps, as long as the same logical relationship is included, and all are within the protection scope of the application. Irrelevant modifications or irrelevant designs are added to the algorithm or process, but the core design of the algorithm and process is not changed, and all are within the protection scope of the application.

[0137] Another embodiment of the application provides a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement a multi-factor combined virtual container cluster intelligent scheduling method as described in the above method embodiment.

[0138] That is, a person skilled in the art can understand that all or part of the steps in the above method embodiments can be completed by programs instructing relevant hardware, the programs are stored in a storage medium, and the programs include a plurality of instructions for causing a device (such as a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the method described in the method embodiments of the present application. The foregoing storage medium includes a U disk, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk, and various media that can store program codes.

[0139] A person skilled in the art can understand that each of the above embodiments is a specific embodiment for implementing the present application, and in actual application, various changes can be made in form and details without departing from the spirit and scope of the present application. For those skilled in the art, a number of improvements and refinements can be made without departing from the principles of the present application, and these improvements and refinements are also considered within the protection scope of the present application.

Claims

1. A multi-factor combined virtual container cluster intelligent scheduling method, suitable for containers using Kubernetes orchestration, characterized in that, The method comprises: Feature engineering is performed on a historical load data set of a target cluster to obtain a training set, a combined load prediction model is established based on an LSTM model and a LightGBM model, and the combined load prediction model is iteratively trained based on the training set until convergence is achieved, thereby obtaining a trained combined load prediction model; The trained combined load prediction model is used to predict future load rates of the target cluster, and based on the predicted values output by the trained combined load prediction model, an automatic scaling strategy based on load prediction is combined to perform automatic scaling processing on the target cluster, which includes predictive scaling and predictive scaling; The resource usage of the target cluster is obtained, and based on the resource usage of the target cluster, a multi-dimensional resource scheduling algorithm based on TOPSIS is combined to determine the scores of each candidate node, and the resources of the target cluster are redistributed based on the scores of each candidate node, and appropriate Pods are selected for redeployment; Wherein, data collection, load prediction, automatic scaling and resource scheduling are realized by a self-designed extension scheduler of Kubernetes; Predictive scaling includes: The trained combined load prediction model is used to predict the load rates of the target cluster at five future time points, and if the predicted values of at least three time points are greater than the preset upper load rate threshold, it is determined that the load rate of the target cluster in the future is too high and scaling operation is needed; The number of nodes required for recording the future is , the number of nodes to be added is , and are expressed as: ； ； wherein, represents the current number of nodes, represents the current load rate, represents the maximum value among the predicted values corresponding to the future five time points; After determining the number of nodes to be added, the Pod migration queue needs to be further determined, and the no-migration principle is adopted for Pods with service status, and the partial migration principle is adopted for Pods without service status; Based on CPU utilization, memory utilization, disk utilization and bandwidth utilization, the node load rate of each node is calculated, and the nodes with a node load rate greater than the average load rate of the cluster are determined as high-load nodes; Select from each high-load node A Pod that is in a state of no service. The sum of the load rates of the Pods in a non-service state is no greater than the absolute value of the difference between the load rate of the high-load node and the average load rate of the cluster. Sort all the selected Pods in the no-service state according to the load rate from large to small, and further select the Pods with high load rate to form a Pod migration queue. Predictive scaling includes: The trained combined load prediction model is used to predict the load rates of the target cluster at five future time points, and if the predicted values of the five time points are all less than the preset lower load rate threshold, and the load rate of the current time point is also less than the preset lower load rate threshold, it is determined that the load rate of the target cluster in the future is too low and scaling operation is needed; Each node of the target cluster is traversed, and the load rate of the target cluster after deleting the current node is calculated, and if the load rate of the target cluster after deleting the current node is less than the preset upper load rate threshold, all the pods running on the current node are migrated, and the resources of the current node are recycled after migration, thereby completing the scaling of the current node; When migrating Pods with service status across nodes, first, the Pods with service status are unloaded from the current node, then the disk directories Volumes that can be shared by multiple containers are separated from the current node, then the Volumes are reattached on the new node, and finally the Pods with service status are mounted on the new node. 2.The multi-factor combined virtual container cluster intelligent scheduling method of claim 1, wherein, Feature engineering is performed on a historical load data set of a target cluster to obtain a training set, including: The historical load data set of the target cluster is preprocessed, including missing anomaly processing, duplicate anomaly processing, splitting processing and dimensionality reduction processing, to obtain a preprocessed historical load data set; Feature engineering is performed on the preprocessed historical load data set to obtain a training set; wherein the feature engineering constructs the training set from three aspects, namely time series features, cross features and aggregated features; A combined load prediction model is established based on the LSTM model and the LightGBM model, and the training set is used to iteratively train the combined load prediction model until convergence, to obtain a trained combined load prediction model, including: The LSTM model and the LightGBM model are combined to establish a combined load prediction model, the LSTM model uses time series features as input for training, and the LightGBM model uses network parameters from the LSTM model after training, time series features, cross features and aggregated features as input for training, and after both are trained to meet the preset convergence condition, a trained combined load prediction model is obtained; Wherein, the network structure of the LSTM model consists of one LSTM layer and multiple fully connected layers, each layer is provided with BatchNorm normalization and DropOut regularization. 3.The method of claim 1, wherein, The resource usage of the target cluster obtained includes CPU utilization, memory utilization, disk utilization, bandwidth utilization and node container quantity, a total of five indicators; Based on the resource usage of the target cluster, combined with the multi-dimensional resource scheduling algorithm based on TOPSIS, the scores of each candidate node are determined, including: According to the request amount of Pod to network IO and the network IO usage of cluster nodes, nodes with remaining bandwidth less than a preset remaining bandwidth threshold are filtered out, and the remaining nodes are used as candidate nodes; The structure is composed of A decision matrix consisting of the number of candidate nodes and 5 standard arrays , 5 standard numbers correspond to the five indicators respectively, the decision matrix Expressed by the formula; ； wherein, represents the CPU utilization of the th candidate node, represents the memory utilization of the th candidate node, represents the disk utilization of the th candidate node, represents the bandwidth utilization of the th candidate node, represents the number of node containers of the th candidate node; Using the reciprocal method, the decision matrix is... The value of each item in the matrix is ​​positiveized to obtain the positiveized decision matrix. ; The decision matrix after positive transformation The value of each item in the matrix is ​​normalized to obtain the normalized decision matrix. ; The normalized decision matrix is input into the TOPSIS algorithm to obtain a score matrix of each candidate node , the score matrix is expressed by the formula ； wherein, represents the score of the th candidate node, and the upper right corner denotes the transpose operation.

4. The multi-factor combined virtual container cluster intelligent scheduling method of claim 3, wherein, Based on the scores of each candidate node, the resources of the target cluster are redistributed, and appropriate Pods are selected for redeployment, including: Define a variable that represents the node with the highest score when a new Pod is created ; Based on the score matrix Traverse each candidate node, if the score of the current candidate node is higher than , then replace with the current candidate node, otherwise directly compare the next candidate node; After traversing all candidate nodes, the optimal candidate node with the highest score is obtained, and the new Pod is deployed to the optimal candidate node.

5. The multi-factor combined virtual container cluster intelligent scheduling method of claim 1, wherein, The extension scheduler is implemented in the form of a scheduling framework, which defines a set of extension points, supports customizing scheduling logic by implementing interfaces defined by extension points, and registers extensions to extension points; Each time a Pod is scheduled, it is divided into two stages, namely the scheduling period and the binding period, the scheduling period selects nodes for the Pod, and the binding period applies the decision to the target cluster, the scheduling period and the binding period together are called the scheduling context; The extension points include at least Filter extension points and Score extension points, the Filter extension points are used to exclude nodes that cannot run the Pod, which is equivalent to the pre-selection stage, and the Score extension points are used to score all candidate nodes, the score result is an integer within a range, which is equivalent to the optimization stage, the same plugin is allowed to be registered on multiple extension points to perform complex or stateful tasks; When initializing the scheduler, a profile is automatically created, which is a definition related to the scheduling configuration of the scheduler, and its implementation is KubeSchedulerProfile, that is, the configuration passed in when generating a YAML file. To implement a custom scheduling plug-in, you need to register the custom algorithm you have written in the target cluster and recompile the Scheduler, and finally insert the scheduling plug-in to be used by configuring the KubeSchedulerConfiguration object in Kubernetes. 6.The multi-factor combined virtual container cluster intelligent scheduling method of claim 1, wherein, The extended scheduler is independent of the default scheduler of Kubernetes, and is composed of four parts: data collection module, load prediction module, automatic scaling module and resource scheduling module; The data collection module is implemented by running Prometheus in the target cluster, responsible for load monitoring of the target cluster, including node resource usage monitoring and Pod container resource usage monitoring, obtaining resource usage of the target cluster, and collecting, analyzing and storing historical load data of the target cluster; The load prediction module is packaged in the form of a container and runs in the target cluster, responsible for feature engineering on the historical load data set of the target cluster to obtain a training set, iterative training of the combined load prediction model using the training set until convergence, and prediction of future load rate of the target cluster using the trained combined load prediction model; The automatic scaling module is responsible for automatic scaling of the target cluster based on the prediction value output by the trained combined load prediction model, combined with the load prediction-based automatic scaling strategy, including predictive expansion and predictive contraction. The resource scheduling module is responsible for determining the score of each candidate node based on the resource usage of the target cluster and the TOPSIS-based multi-dimensional resource scheduling algorithm, and reallocating resources of the target cluster based on the score of each candidate node to select appropriate Pods for redeployment.

7. The method of claim 6, wherein, The data collection module is based on Prometheus to build a resource monitoring component, which uses a combination of Node-Exporter, cAdvisor, Prometheus and Grafana to monitor resources; The Node-Exporter component is responsible for obtaining the resource usage information of the worker nodes in the target cluster, and the selected monitoring points include cpu, meminfo, diskstats and netstat, which monitor CPU utilization, memory utilization, disk utilization and bandwidth utilization respectively. The cAdvisor component is responsible for monitoring and collecting container resources in the Pod. The InfluxDB time series database is used to realize the persistent storage of load time series data. The Prometheus component is responsible for collecting node load index data. By modifying the configuration file of Prometheus, the collection period is set to periodically count and store in InfluxDB. The Grafana component is responsible for visualizing the monitoring data. The Node-Exporter component is deployed in the worker node in the form of DaemonSet, and cAdvisor is integrated in Kubelet as the default startup item of Kubernetes. The data collected by the two is analyzed by Prometheus and stored in the time series database InfluxDB. The data obtained after analysis is displayed through Grafana from the web end. During monitoring, data requests are made through the HTTP API interface provided by Prometheus. After receiving the data request, Prometheus processes the request and returns the request data in JSON format. The resource monitoring component then decodes, analyzes and stores the data for use by other components.

8. A computer readable storage medium storing a computer program, characterized in that, The computer program, when executed by a processor, can implement the multi-factor combined virtual container cluster intelligent scheduling method of any one of claims 1 to 7.

Images