Method and device for automatically expanding Kubernetes static Pod

Abstract

The invention provides a method and a device for automatically expanding the capacity of a Kubernetes static Pod, which are used for judging whether the configuration of the static Pod comprises an automatic capacity expansion strategy or not through a host process in the static Pod to be expanded, and monitoring the overall load of the static Pod. And when the overall load exceeds the standard or is insufficient, the capacity is reduced or expanded, so that the dynamic adjustment of the number of the service containers in the static Pod is realized, and the flexibility of the system, the resource utilization rate and the operation stability are improved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of computer software, and particularly relates to a method and device for automatically expanding Kubernetes static Pods. BACKGROUND

[0002] In the existing container orchestration system, Kubernetes has become a de facto mainstream platform, and its core capability lies in scheduling and life cycle management of Pods through controllers such as Deployment, StatefulSet and DaemonSet, so as to realize replica management, load balancing and elastic scaling. However, for static Pods, their deployment mode depends on the kubelet configuration file on the node, which is directly managed by the node and is not subject to the scheduling and controller unified management of the Kubernetes control plane. Therefore, static Pods have the advantages of simple configuration and direct operation when guaranteeing key system services, operation and maintenance components or cluster basic functions, but their defects are also very obvious, that is, they lack automatic expansion and scaling capacity.

[0003] In the traditional scheme, the number of business containers of a static Pod is fixed in the configuration phase, and once the Pod is started, the number and resource specification of the internal containers cannot be adjusted according to the actual business load. This means that in the case of a sharp increase in business request volume, the limited number of business containers in the static Pod may quickly reach a resource bottleneck, resulting in request delay, service unavailability and even system crash. When the business load is low, the fixed number of containers will also cause resource waste and reduce the overall resource utilization of the cluster. In addition, since static Pods are not subject to the scheduling mechanism of Kubernetes controllers, they lack unified scheduling mechanisms for monitoring and adjusting CPU, memory, IO and other loads, and therefore cannot be combined with HPA (Horizontal Pod Autoscaler) or VPA (Vertical Pod Autoscaler) for elastic scaling like ordinary Pods.

[0004] Although some researches in the prior art attempt to indirectly manage the number of containers of static Pods through external scripts or third-party tools, these methods mostly rely on external system triggering or manual intervention, and have problems such as delayed response, lack of deep integration with container runtime, insufficient monitoring accuracy, etc., and are difficult to meet the requirements of high availability and real-time expansion and scaling. At the same time, these methods often lack fine-grained collection of container load indicators and cannot realize accurate perception and dynamic decision-making at the single container level.

[0005] Therefore, the prior art has the following problems to be solved urgently: static Pods lack built-in automatic scaling mechanism and cannot realize adaptive adjustment based on business load; high-precision container process monitoring means are lacking, and it is difficult to form real-time and reliable scaling judgment basis; the existing method relies on external tools, increasing system complexity and operation and maintenance cost. How to introduce automatic scaling capability for static Pods while maintaining their simplicity and stability, and improve resource utilization and system flexibility, is the core technical problem to be solved by the present application. SUMMARY

[0006] The main problem solved by the present application is how to automatically scale static Pods while maintaining their simplicity and stability, improve resource utilization and system flexibility, and provide a method and device for automatically scaling Kubernetes static Pods.

[0007] To solve the above technical problems, the technical solution adopted is: The present application provides a method for automatically scaling Kubernetes static Pods. When the main process of the static Pod to be scaled is started, it is determined whether the configuration of the static Pod to be scaled contains an automatic scaling policy. If it does, the main process of the static Pod monitors the overall load of the static Pod to be scaled according to the automatic scaling policy. When the scaling condition is reached, new business containers are built or business containers are released according to the business container part contained in the configuration of the static Pod to be scaled. The main process refers to the process set in the container of the static Pod to play a coordinating role.

[0008] Further, the automatic scaling policy includes: scaling indicators, scaling indicator thresholds, multi-business container indicator aggregation methods, scaling business container quantities, scaling business container name rules, scaling indicators, scaling indicator thresholds, business container release rules, and business container release quantities.

[0009] Further, the method for monitoring the overall load of the static Pod to be scaled is: the main process calculates the load indicator values of each business container of the current static Pod according to the multi-business container indicator aggregation method of the automatic scaling policy, obtains the aggregation values of each load indicator of all business containers of the static Pod, determines whether the aggregation values of each indicator exceed the scaling threshold of the indicator, and if the aggregation value of an indicator exceeds the scaling threshold of the indicator, expands a corresponding number of business containers according to the scaling business container quantity, and names the expanded business containers according to the scaling business container name rule. If the aggregated value of a certain index of all business containers of the static Pod reaches the scaling-in threshold of the index, a corresponding number of business containers are released according to the pre-set business container release rule and the number of released business containers.

[0010] The application further provides a Kubernetes static Pod automatic scaling device, comprising the following modules: The scaling judgment module is configured to judge whether the automatic scaling strategy is contained in the configuration of the static Pod to be scaled when the main process in the static Pod to be scaled is started. The monitoring module is configured to monitor the overall load of the static Pod to be scaled according to the automatic scaling strategy when the scaling judgment module judges that the automatic scaling strategy is contained. The scaling module is configured to build new business containers or release business containers according to the business container part contained in the configuration of the static Pod to be scaled when the overall load of the static Pod to be scaled reaches the scaling condition.

[0011] The technical scheme has the following beneficial effects: The method and device for automatically scaling the Kubernetes static Pod provided by the application judge whether the automatic scaling strategy is contained in the configuration of the static Pod through the main process in the static Pod to be scaled, and monitor the overall load of the static Pod. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 The method flowchart of the application is shown in the figure. DETAILED DESCRIPTION

[0013] The technical scheme of the application will be described clearly and completely in combination with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the application, rather than all the embodiments.

[0014] The application provides a method for automatically expanding Kubernetes static Pods, when a main process in a static Pod to be expanded starts, it is judged whether an automatic expansion strategy is contained in the configuration of the static Pod to be expanded; if the automatic expansion strategy is contained, the main process in the static Pod monitors the overall load of the static Pod to be expanded according to the automatic expansion strategy, when the expansion and contraction condition is reached, according to the business container part contained in the configuration of the static Pod to be expanded, a new business container is built or the business container is released, and the main process refers to a process arranged in a container in the static Pod and playing a coordinating role.

[0015] In the embodiment, the automatic expansion strategy is specified in the configuration file of the static Pod, the configuration file is set in the format of yaml, and the automatic expansion strategy is written in the configuration file. The automatic expansion strategy includes an expansion index, a threshold of each expansion index, a multi-business container index aggregation method, an expansion business container number, an expansion business container name rule, a contraction index, a threshold of each contraction index, a business container release rule and a business container release number. Generally, the automatic expansion strategy is defined by an operation and maintenance personnel or a system administrator in the configuration file YAML format file of the Pod, and the content includes but is not limited to: an expansion index (for example, CPU utilization, memory occupation rate, disk IO throughput, network delay and the like), an expansion index threshold (for example, CPU utilization is more than 80%, memory usage is more than 75% and the like), and a corresponding aggregation method of each index of the multi-business container (for example, taking an average value, a maximum value, a minimum value or a weighted average value), in the embodiment, the aggregation value of each load index is calculated according to the aggregation method of the index in the automatic expansion strategy, the aggregation method of each index may be different, some take an average value, some take a maximum value and the like, and the aggregation method is set by the operation and maintenance personnel according to needs. In addition, the setting of the expansion business container number (for example, one or two business container instances are newly added at a time) and the name rule of the expansion business container (for example, “service-container-number”, the naming is ensured not to conflict through the serial number increment method) are also contained.

[0016] The implementation process is as follows: when a static Pod is started, first, the initialization and scheduling of the Pod are completed by the Kubernetes container orchestration software, and the Pod contains a main process for coordination and monitoring in addition to the business container running the actual business logic. The main process is independently deployed in the form of a Sidecar container, and the monitoring and coordination functions are realized through the program in the Sidecar container. After the main process is started, the configuration information of the static Pod is loaded first, and it is determined whether the related fields of the automatic scaling strategy are included. If the automatic scaling strategy is not configured, the main process only maintains the basic operation of the static Pod; if the automatic scaling strategy is found, the main process enters the scaling monitoring mode to monitor whether the total load reaches the scaling threshold to perform scaling.

[0017] In the embodiment, the method for monitoring the overall load of the static Pod to be scaled is as follows: the main process respectively calculates the load index values of each business container of the current static Pod according to the multi-business container index aggregation method of the automatic scaling strategy, obtains the aggregation values of each load index of all business containers of the static Pod, determines whether the aggregation values of each index exceed the scaling threshold of the index, if the aggregation value of an index exceeds the scaling threshold of the index, a corresponding number of business containers are expanded according to the number of scaled business containers, and the expanded business containers are named according to the scaling business container name rule; if the aggregation value of an index of all business containers of the static Pod reaches the scaling threshold of the index, a corresponding number of business containers are released according to the release number of business containers according to the pre-set business container release rule.

[0018] In this embodiment, after reading these policy parameters, the main process starts to collect and analyze the indicators. By calling the interface of the container runtime software (such as docker, runc, cri-o, etc.), or directly accessing the / proc / [pid] directory, top command, ps command, or using eBPF probes, the key processes in the business container are collected in real time. CPU, memory, IO and other load data. Based on the eBPF program, the system call, CPU scheduling, memory allocation and IO behavior of each business process are captured at the container runtime bottom layer, so as to obtain fine-grained CPU utilization, memory occupancy and disk / network IO load and other indicators. This method has less impact on system performance and can provide high-precision real-time data. The CPU and memory occupancy of the process can be obtained by traditional methods such as top and ps commands, or by directly reading the stat, status, io and other files in the / proc / [pid] directory. The load information of the container process can also be obtained. These two methods can be flexibly selected or combined according to the capabilities of the deployment environment and monitoring requirements. The collected indicator data of each business container is calculated according to the aggregation method corresponding to each indicator in the policy to generate the aggregation value corresponding to each indicator of all business containers of the Pod. The main process compares the aggregation value corresponding to each indicator with the threshold value in the scaling policy.

[0019] This embodiment uses the main process to load the scaling policy and initialize the monitoring logic in the early stage of the static Pod running, which lays the foundation for the subsequent automatic expansion or reduction of business containers. This embodiment ensures that the static Pod maintains simple configuration and high stability while having the ability to automatically perceive load and prepare for scaling. The static Pod can maintain dynamic perception of overall resource consumption and form accurate total load indicators in the case of parallel running of multiple business containers. Not only does it provide a scientific basis for subsequent scaling, but it also ensures the coordination and controllability of multiple container running inside the Pod, significantly improving the adaptive ability and resource utilization efficiency of the static Pod in complex business scenarios, and breaking through the limitations of traditional static Pods that cannot be elastically scaled.

[0020] In this embodiment, expanding a new service container is to create a new service container instance directly according to the service container part in the Pod configuration file by the main process in the static Pod to be expanded. The configuration of the service container includes: container name, image address, mounted volume, resource specification, environment variable, etc. The specific process of expansion is: during the running process of the static Pod, the main process continuously collects and calculates the index values of each load under each service container of the static Pod according to the established monitoring logic. When the load values of all service containers of the static Pod corresponding to the indexes calculated by the aggregation method reach or exceed the expansion threshold of each index set in the automatic expansion strategy (for example, CPU utilization exceeds 80% or memory occupancy exceeds 75%), the main process immediately enters the expansion decision stage. At this time, the main process calls the container runtime interface (such as docker, runc, cri-o, etc.) to create a new service container instance according to the description of the service container part in the static Pod configuration file to cope with the sudden surge of load pressure. The configuration parameters of the newly created service container are pre-set in the service container part of the Pod configuration file, including container name (which can be automatically generated according to the expansion name rule, such as “service-container-1” “service-container-2”), image address (such as service image stored in enterprise private image warehouse), mounted volume (used for sharing log, configuration file or persistent storage), resource specification (such as CPU quota, memory upper limit) and environment variable (such as service port, dependent service address, etc.). When creating a new container, the main process will operate according to the “number of expanded service containers” defined in the expansion strategy, for example, increase 2 container instances at a time, and automatically generate unique names according to the “expansion service container name rule” to avoid conflicts with existing containers. The newly created service container automatically joins the existing static Pod business processing system after startup, undertakes part of the calculation or service request, and reduces the load pressure of the existing service container, and cooperates with the original service container to process the request. At the same time, the main process will continue to collect the CPU, memory, IO and other load indicators of the new and old containers in real time through the eBPF probe or / proc interface, and calculate the aggregated values of each index after using the multi-service container index aggregation method.

[0021] When the system enters the low load stage, the main process will detect that the total load index of the static Pod is continuously lower than the shrinkage threshold (such as CPU utilization is lower than 30%, memory usage is lower than 40%). At this time, the main process starts the shrinkage logic, and selects part of the service containers to release according to the “shrinkage number” and “shrinkage priority” set in the strategy. For example, the main process can preferentially recycle the latest created instance according to the container creation time sequence, or select the instance with less overall impact according to the running weight of the container to terminate. The released container will exit by calling the container runtime interface (docker, runc, cri-o, etc.).

[0022] Through the dynamic scaling mechanism, the static Pod can automatically increase the number of containers during the business peak to guarantee the service performance, and automatically reduce the number of containers during the business valley to save system resources. Compared with the traditional static Pod running mode with fixed number of containers, the embodiment enables the static Pod to have the elastic scheduling capability of the advanced controller such as Deployment, without relying on additional orchestration logic, thereby maintaining the lightweight and flexible configuration advantages of the static Pod, and effectively improving the high availability and resource utilization of the system.

[0023] The application further provides a Kubernetes static Pod automatic scaling device, comprising the following modules. The scaling judgment module is configured to judge whether the automatic scaling strategy is contained in the configuration of the static Pod to be scaled when the main process in the static Pod to be scaled is started. The monitoring module is configured to monitor the overall load of the static Pod to be scaled according to the automatic scaling strategy when the scaling judgment module judges that the automatic scaling strategy is contained. The scaling module is configured to build new business containers or release business containers according to the business container part contained in the configuration of the static Pod to be scaled when the overall load of the static Pod to be scaled reaches the scaling condition.

[0024] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the application, and not to limit them; although the application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the application.

Claims

1. A method for automatically scaling up static Pods in Kubernetes, characterized in that, When the main process in the static Pod to be expanded starts, it determines whether the configuration of the static Pod to be expanded includes an automatic scaling policy. If it does, the main process in the static Pod monitors the overall load of the static Pod to be expanded according to the automatic scaling policy. When the scaling conditions are met, it expands a new business container or releases a business container according to the business container part included in the configuration of the static Pod to be expanded. The main process refers to the process set up in the container in the static Pod that plays a coordinating role.

2. The method according to claim 1, characterized in that, The automatic scaling strategy includes: scaling indicators, thresholds for each scaling indicator, aggregation method for multi-service container indicators, number of service containers to be scaled up, naming rules for service containers to be scaled up, scaling down indicators, thresholds for each scaling down indicator, rules for releasing service containers, and number of service containers to be released.

3. The method according to claim 2, characterized in that, The method for monitoring the overall load of the static Pod to be expanded is as follows: The main process calculates the load index value of each service container of the current static Pod according to the multi-service container index aggregation method of the automatic expansion strategy, obtains the aggregated value of each load index under all service containers of the static Pod, and determines whether the aggregated value of each index exceeds the expansion threshold of the index. If the aggregated value of a certain index exceeds the expansion threshold of the index, the corresponding number of service containers are expanded according to the number of service containers to be expanded, and the expanded service containers are named according to the naming rules of the expanded service containers. If the aggregate value of a certain metric under all business containers of a static Pod reaches the scaling-down threshold of that metric, then according to the pre-set business container release rules, the corresponding number of business containers will be released.

4. An automatic scaling device for static Pods in Kubernetes, characterized in that, Includes the following modules: Expansion Judgment Module: Used to determine whether the configuration of the static Pod to be expanded includes an automatic expansion policy when the main process of the static Pod to be expanded starts. Monitoring module: When the expansion judgment module determines that an automatic expansion policy is included, the main process in the static Pod to be expanded will monitor the overall load of the static Pod to be expanded according to the automatic expansion policy. The scaling module is used to either add new business containers or release business containers based on the business container portion of the configuration of the static Pod to be scaled up when the overall load of the static Pod to be scaled up reaches the scaling conditions.

Images