Kubernetes adaptive deployment method based on elastic resource scheduling

Abstract

The technical scheme of the invention discloses a Kubernetes self-adaptive deployment method based on elastic resource scheduling. By introducing resource monitoring, demand prediction, strategy decision and adaptive adjustment mechanisms, dynamic scheduling and deployment optimization of container resources are realized, so that the resource utilization rate and the system response capability are improved, the manual intervention and operation and maintenance cost are reduced, the stability and the intelligent level of the system are enhanced, and the service life of the system is prolonged. The method is widely applied to a multi-tenant cloud platform, an edge computing environment and a high-concurrency service scene.

Description

TECHNICAL FIELD

[0001] The application relates to a method for quickly clouding a service and realizing quick application and resource allocation between services, and belongs to the technical field of k8s cloud native cluster external tools, in particular to the technical field of quick release and deployment based on software industry front-end code. BACKGROUND

[0002] At present, container technology dominates cloud native architecture, and Kubernetes, as the core orchestration system, still faces major challenges in dynamic resource scheduling. Traditional schedulers (such as kube-scheduler) rely on static strategies (such as node resource margin and label affinity) for decision-making, and lack dynamic perception capabilities for real-time load fluctuations, heterogeneous hardware performance differences and multi-dimensional quality of service (QoS) indicators (such as network delay and storage IOPS). For example, when sudden traffic causes local resource contention among microservice instances, the fixed threshold horizontal scaling (HPA) and vertical scaling (VPA) mechanisms often cause resource over-allocation or service performance jitter due to response delay or prediction bias. In addition, in the mixed cloud scenario, the resource fragmentation problem across clusters is prominent, and existing scheduling algorithms are difficult to balance global resource utilization and cost efficiency, resulting in high enterprise infrastructure expenditure. Therefore, how to realize self-allocation between application scheduling resources has become the focus of attention.

[0003] A Chinese invention patent application with publication number CN118656173A discloses a Kubernetes cluster resource scheduling method, device, electronic equipment and storage medium, relating to the field of cloud computing technology. The method includes configuring a blocking factor for the Kubernetes cluster, configuring an unblocking value and a blocking value according to the blocking factor, setting a scheduling time frequency for the Kubernetes cluster, blocking and unblocking the node servers in the Kubernetes cluster according to the scheduling time frequency, setting a scheduling time period for the Kubernetes cluster, adjusting the applications of the node servers in the Kubernetes cluster according to the resource utilization of the node servers in the Kubernetes cluster within the scheduling time period, and finally setting an emergency node server to publish applications that meet the set importance and complexity to the emergency node server. The foregoing invention patent application introduces resource management and scheduling strategies to control resource allocation on node servers, solving the problem that the prior art cannot improve the utilization rate of Kubernetes resources and reduce the use cost of Kubernetes resources. However, the technical solution has the problem of manual configuration by professional technicians each time, which is relatively cumbersome. SUMMARY

[0004] The technical problem to be solved by the present application is that traditional Kubernetes systems mostly rely on static configuration and fixed strategies, which are difficult to cope with resource demand fluctuations generated by container applications in actual operation, and are prone to cause resource waste or service performance degradation.

[0005] In order to solve the above technical problems, the technical scheme of the present application discloses a Kubernetes adaptive deployment method based on elastic resource scheduling, which depends on a system including a Web front end, a Kubernetes Master node and a Worker node. When a user accesses a service, a request is initiated through the Web front end, the request is sent to the Kubernetes Master node, the service load is distributed to different Worker nodes by the Kubernetes Master node, and a number of Pods are run on each Worker node. The Pod is the smallest deployable computing unit. The Kubernetes adaptive deployment method comprises the following steps:

[0006] Step 1: periodically collecting resource usage data of each Pod;

[0007] Step 2: the HPA controller obtains the current usage currentUsage based on the resource usage data, and further calculates the size of the current usage currentUsage: if the size of the current usage currentUsage is not equal to the pre-set threshold value, step 3 is entered, otherwise, step 1 is returned;

[0008] Step 3: calculating the Pod replica number cR after expansion and contraction, as shown in the following formula:

[0009] rC=tanh(Wc·[h t-1 ,x t ]+b C )

[0010]

[0011] In the formula, rc is the expected value of the Pod replica number, Wc is used to combine the historical state and the current input to generate candidate memory content, the weight matrix, h t-1 is the past one-hour CPU continuous change rising period, x t represents the usage of current CPU, memory and network delay, b C is the baseline value of adjusting the candidate memory, ceil is the ceiling function, aP is the actual running Pod replica number, and eX is the target value of the Pod replica number that the system hopes to achieve in the ideal state;

[0012] Step 4, if the size of the current usage currentUsage exceeds the set threshold, then perform the expansion operation based on the number of Pod replicas cR calculated in step 3, increase the number of Pod replicas, and return to step 1;

[0013] If the size of the current usage currentUsage is less than the set threshold, then perform the scaling operation based on the number of Pod replicas cR calculated in step 3, reduce the number of Pod replicas, and return to step 1.

[0014] Preferably, the API Server of the Kubernetes Master node is the unified entrance of the system, responsible for receiving and scheduling requests.

[0015] Preferably, in step 1, the collection period of each Pod resource usage data can be customized by the user.

[0016] Through the Kubernetes adaptive deployment method based on elastic resource scheduling disclosed by the application, application load and cluster resource usage can be analyzed in real time through algorithm scheduling, and the deployment strategy of the Pod is dynamically adjusted to improve resource utilization. Through historical data to predict traffic fluctuations, adaptive scaling is realized, and resource waste is reduced. Making full use of the resources of each node is the key to improving the utilization rate of cluster resources. Kubernetes, as the preferred system in the field of container orchestration, one of its main functions is to schedule jobs to appropriate nodes. Reasonable scheduling strategy can reduce the generation of resource fragmentation, improve node resource utilization, and reduce job waiting time.

[0017] The application realizes dynamic scheduling and deployment optimization of container resources by introducing resource monitoring, demand prediction, strategy decision and adaptive adjustment mechanism, thereby improving resource utilization and system response capability, reducing manual intervention and operation and maintenance cost, enhancing the stability and intelligent level of the system, and being widely applicable to multi-tenant cloud platforms, edge computing environments and high-concurrency business scenarios.

[0018] Compared with the prior art, the application can integrate tools, integrate k8s, manage containers, realize rapid resource deployment, and realize full life cycle management of tools. The main implementation tool monitors Pod resources, dynamically adjusts the number of Pod replicas and resource quotas, and realizes the monitoring of the overall execution process of the tool from the initial, construction and running stages, which has the following beneficial effects:

[0019] 1. Rapid service construction is realized, historical load data is analyzed through the integration of a dynamic time series regressor to predict future concurrency, and the normal operation of the business is ensured through rapid scaling of Pods services;

[0020] 2、The expansion and contraction mechanism is based on real-time monitoring indicators (such as CPU, usage rate, memory occupation, etc.) for dynamic adjustment, ensuring that the system can automatically expand in high load, avoiding service interruption or performance degradation due to insufficient resources, in this way, the system can maintain stability under different load conditions, improving overall availability and service stability;

[0021] 3、By calculating and predicting CPU usage, memory usage and other indicators, the system can intelligently predict future resource needs and adjust according to actual access volume, this intelligent adjustment mechanism can ensure rapid resource expansion when user access volume surges, avoiding service unavailability due to insufficient resources, ensuring smooth business operation;

[0022] 4、The system can automatically execute expansion and contraction decisions without manual intervention by operation and maintenance personnel, which not only greatly reduces the complexity of manual management, but also reduces the time cost brought by manual intervention, improving operation and maintenance efficiency. Operation and maintenance personnel only need to set the expected target and threshold, and the system can automatically adjust according to the actual situation, significantly improving work efficiency;

[0023] 5、By dynamically adjusting the number of Pod replicas, the system can flexibly allocate resources according to real-time load: when the system load is low, automatic contraction can reduce unnecessary resource consumption; when the load is high, automatic expansion ensures smooth business operation, greatly improving resource utilization efficiency and avoiding resource waste or deficiency. BRIEF DESCRIPTION OF DRAWINGS

[0024] Figure 1 The real-time overall architecture diagram for business access is shown in the figure;

[0025] Figure 2 The expansion method flowchart is shown in the figure. DETAILED DESCRIPTION

[0026] The present application will be further described below in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present application and not to limit the scope of the present application. In addition, it should be understood that after reading the content taught by the present application, those skilled in the art can make various modifications or modifications to the present application, and these equivalent forms also fall within the scope defined by the appended claims of the present application.

[0027] The present application aims to solve the limitations of existing Kubernetes deployment methods in resource scheduling and elastic scaling, and proposes an adaptive deployment method based on elastic resource scheduling. Figure 1As shown, the business access real-time overall architecture of the system relied on by the present application includes a Web front end, a Kubernetes Master node and a Worker node. When a user accesses a business, a request is first initiated through the Web layer, and the request is sent to the APIServer on the Kubernetes Master node. The API Server serves as the unified entrance of the system, is responsible for receiving and scheduling requests, and further distributes business loads to different Worker nodes. This design can realize unified management and scheduling of requests, thereby improving the scalability and reliability of the system.

[0028] The Worker node is where the business actually runs, and one or more Pods run on each node. Each Pod contains a Controller, a Kubelet, a Kubelet-proxy and an actual business container inside. The Controller is responsible for managing and controlling the life cycle of the Pod. The Kubelet is the core component for communication between the Worker node and the Kubernetes Master node, and is responsible for receiving instructions and managing the running state of the container. The Kubelet-proxy is used to realize network proxying and load balancing, ensuring that services can communicate normally. Through this modular design, the system can be flexibly extended to support high-availability business deployment and operation and management, and full-life-cycle monitoring and management.

[0029] As shown in Figure 2 The Kubernetes adaptive deployment method based on elastic resource scheduling disclosed by the present application specifically includes the following steps.

[0030] Step 1: Collect resource usage data of each Pod, such as CPU usage, regularly by Metrics Server or Prometheus. In the embodiment of the present application, user-defined configuration is supported, and corresponding frequency is collected according to the configured period to obtain corresponding index parameters, facilitating subsequent business to realize elastic resource expansion and reduction.

[0031] Step 2: The HPA Controller obtains the current CPU usage, and obtains the current usage currentUsage according to the current CPU resource usage.

[0032] The working principle of HPA Controller: when the CPU usage or other monitoring indicators of the Pod exceed the set threshold, Kubernetes will automatically trigger the scaling operation to increase the number of Pods; on the contrary, when these indicators are below the set range, the system will automatically scale down to reduce the number of Pods. Through this dynamic resource adjustment mechanism, the system can flexibly adjust resource allocation according to actual load conditions, improve the availability and stability of applications, and avoid the complexity and time cost brought by manual intervention. This mechanism greatly optimizes the operation and maintenance efficiency, ensuring that the system always runs in the best state under different loads.

[0033] Further, when a user request is detected, the CPU usage will dynamically change according to the user access data volume.

[0034] Step 3, HPA Controller calculates the size of the current usage currentUsage and compares it with the previously set threshold size. In the embodiment of the present application, the threshold preset value is the parameter default value set by the operation and maintenance personnel before the application accesses externally.

[0035] Step 4, if the size of the current usage currentUsage exceeds the set threshold, the resource will be adjusted according to the current dynamic Pod replica number resource adjustment formula to realize the prediction of resources, and then the scaling will be performed. If the current user volume is small, the resources can be reduced. If the access is high in a certain period of time, the corresponding resource adjustment pod number can be performed in advance to ensure that the business system can normally access externally, realize dynamic scheduling of resource use, and reduce unnecessary resource waste.

[0036] In the embodiment of the present application, the current dynamic Pod replica number resource adjustment formula is:

[0037] rC=tanh(Wc·[h t-1 ,x t ]+b C )

[0038]

[0039] In the formula, rC is the expected value of a Pod replica number; Wc is used to combine historical state and current input to generate candidate memory content, a weight matrix; h t-1 is the past one-hour Cpu continuous change rising period; x t represents the current Cpu, memory, and network delay usage; and b CTo adjust the reference value of the candidate memory, prevent the predicted value of all Pods in the initial stage from being the same; cR is the desired Pod replica number after scaling, which represents the desired replica number calculated by the system according to load and other factors, the desired Pod replica number after scaling, and is used to guide the scaling operation; ceil is the ceiling function; aP is the current Pod replica number, which refers to the actual number of Pod instances currently running; eX is the desired value, which represents the target value of the desired Pod replica number in the ideal state of the system.

[0040] rC=tanh(Wc·[h t-1 ,x t ]+b C ) wherein: Wc·[h t-1 ,x t ] is to increase the cpu memory capacity, generate the original memory proposal, tanh() is to compress the output to [-1, 1], enhance the nonlinear expression capability, calculate whether the current capacity value exceeds the threshold, and convert tanh into a % value. The desired value dM is obtained through rC=tanh(Wc·[h t-1 ,x t ]+b C ), and the target value of the current resource quantity is realized through the formula .

[0041] In the embodiment of the application, the decision-making process of scaling is as follows: first, the system obtains the key performance indicators from the monitoring server as the current reference value; then, according to the target value set by the user, the required Pod number cR is calculated in combination with the current indicators; finally, the expected Pod replica number cR calculated is compared with the actual number of replicas currently running, and if there is a difference, the scaling instruction is issued to the controller, and the specific scaling operation is performed by the controller.

[0042] Step 5, calculate the current desired Pod replica number cR according to the above formula, compare the current Pod number, if the current value is equal, no adjustment is needed, otherwise adjust accordingly.

[0043] The application relates to a Kubernetes adaptive deployment method based on elastic resource scheduling, which realizes automatic scaling operation by monitoring the real-time resource usage of each Pod and combining the expected value set by the user. First, the system periodically collects resource usage data of each Pod, such as CPU usage and memory occupation, through components such as Metrics Server or Prometheus. These data provide key reference for subsequent scaling decision. The collection period and indicator parameters are configured by the user to flexibly adjust according to actual business needs.

[0044] After obtaining real-time monitoring data, the HPA Controller calculates the actual usage rate based on the current resource usage (i.e., currentUsage) and compares it with the preset threshold. If the current resource usage exceeds the set threshold, the system will trigger the scaling operation to increase the number of Pod replicas; conversely, when the resource usage is below the threshold, the system will automatically scale down to reduce the number of Pod replicas, thereby optimizing resource utilization.

[0045] The key innovation of the present application is to dynamically adjust the algorithm according to the actual load and the change of user request volume, and flexibly adjust the number of Pods. Specifically, when the change of user request volume is monitored, the system calculates the expected number of Pods based on dynamically changing indicators such as CPU usage, memory occupation, network delay, etc., and compares it with the current actual number of Pods. If there is a difference between the two, the system will automatically issue scaling instructions, and the controller will perform the specific scaling operation.

[0046] In addition, the present application also introduces a formula-based resource adjustment prediction model, which accurately predicts future resource demand based on historical data and real-time feedback, avoiding unnecessary resource waste. Through this dynamic scheduling mechanism, the system can flexibly respond to load fluctuations, ensuring the high availability and stability of business applications, and efficiently running without human intervention, significantly improving the operation and maintenance efficiency and system flexibility.

[0047]

Claims

1. A Kubernetes adaptive deployment method based on elastic resource scheduling, the Kubernetes adaptive deployment method relies on a system comprising a web front end, a Kubernetes master node and a worker node, when a user accesses a service, a request is initiated through the web front end, the request is sent to the Kubernetes master node, the service load is distributed to different worker nodes by the Kubernetes master node, a plurality of pods are run on each worker node, and the pod is the smallest deployable computing unit, characterized in that, The Kubernetes adaptive deployment method comprises the following steps: Step 1, periodically collecting resource usage data of each Pod; Step 2, the HPA controller obtains the current usage currentUsage based on the resource usage data, and further calculates the size of the current usage currentUsage: if the size of the current usage currentUsage is not equal to the pre-set threshold, step 3 is entered, otherwise, step 1 is returned; Step 3, calculate the number of Pod replicas cR after scaling, as shown in the following formula: rC= tanh(Wc•[h t-1 ,x t ]+b C ) In the formula, rC is the expected value of the number of Pod replicas, Wc is the weight matrix, h t-1 is the rising period of the sustained change of the CPU in the past one hour, x t represents the current usage of CPU, memory, network delay, b C is the reference value of the adjustment candidate memory, ceil is the upward rounding function, aP is the actual number of running Pod replicas, eX is the target value of the number of Pod replicas that the system hopes to achieve in the ideal state; Step 4, if the size of the current usage currentUsage exceeds the set threshold, the scaling operation is performed based on the number of Pod replicas cR calculated in step 3, the number of Pod replicas is increased, and step 1 is returned; If the size of the current usage currentUsage is less than the set threshold, the scaling operation is performed based on the number of Pod replicas cR calculated in step 3, the number of Pod replicas is reduced, and step 1 is returned.

2. The Kubernetes adaptive deployment method based on elastic resource scheduling according to claim 1, wherein, The API Server of the Kubernetes Master node is the unified entrance of the system, responsible for receiving and scheduling requests.

3. The Kubernetes adaptive deployment method based on elastic resource scheduling of claim 1, wherein, In step 1, the collection period of the resource usage data of each Pod can be configured by the user.

Images