Method and device for vertical scaling of pods of a kubernetes cluster

Abstract

The application discloses a kind of kubernetes cluster's Pod vertical capacity expansion method and device, it is related to cloud computing technical field, wherein the method comprises: when listening to Pod needs vertical capacity expansion, the first resource quantity and the second resource quantity of the pod to be expanded are obtained;First resource quantity is existing resource quantity, and second resource quantity is required resource quantity;Create the placeholder pod corresponding to each pod to be expanded;The resource difference value of the first resource quantity and the second resource quantity of each pod to be expanded is calculated;For each placeholder pod, the resource quantity corresponding to resource difference value is applied;In the case where the resource quantity corresponding to resource difference value is successfully applied for each placeholder pod corresponding to each pod to be expanded, according to the resource quantity applied for each placeholder pod corresponding to each pod to be expanded, the first resource quantity of each pod to be expanded is updated.The application can realize vertical capacity expansion without affecting business continuity, and is compatible with open source K8S.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a method and apparatus for vertical scaling of Pods in a Kubernetes cluster. Background Technology

[0002] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] A key issue to address in the containerization of enterprise applications is how to improve the cluster's ability to handle sudden increases in business traffic load by adjusting the size of the container cluster, thereby enhancing user experience and ensuring high availability of system services.

[0004] To address the aforementioned issues, two scaling methods are typically used in Kubernetes (K8S) clusters: vertical scaling and horizontal scaling. Both methods are suitable for stateless applications; however, vertical scaling is necessary for stateful applications (databases, message queues, etc.).

[0005] However, among the existing vertical scaling methods, one type requires restarting the container every time scaling is performed, affecting business continuity; the other type of vertical scaling does not require restarting the container, but requires modifying the Kubernetes source code, which is highly intrusive to the Kubernetes source code and has a significant impact on subsequent Kubernetes version upgrades, and may not be compatible with the upgraded Kubernetes. Summary of the Invention

[0006] This invention provides a method for vertical scaling of Pods in a Kubernetes cluster, enabling online vertical scaling without restarting containers or modifying the Kubernetes source code. This method maintains business continuity and is compatible with open-source Kubernetes. The method includes:

[0007] When it is detected that multiple replica Pods of a service in a Kubernetes cluster need to be scaled up vertically, the first and second resource quantities of the multiple Pods to be scaled up are obtained. The first resource quantity is the existing resource quantity of the Pods to be scaled up, and the second resource quantity is the resource quantity required by the Pods to be scaled up.

[0008] Create a placeholder Pod for each Pod to be expanded; calculate the resource difference between the first and second resource amounts for each Pod to be expanded; request the resource amount corresponding to the resource difference for each placeholder Pod; wherein, the placeholder Pod is used for resource reservation and does not consume resources;

[0009] If the resource amount corresponding to the resource difference for each placeholder Pod to be expanded is successfully applied for, the first resource amount of each Pod to be expanded is updated according to the resource amount applied for for each placeholder Pod to be expanded, so that the updated first resource amount of each Pod to be expanded is the same as the second resource amount.

[0010] This invention also provides a Pod vertical scaling device for a Kubernetes cluster, which enables online vertical scaling without restarting containers or modifying the Kubernetes source code, ensuring business continuity and compatibility with open-source Kubernetes. The device includes:

[0011] The acquisition module is used to acquire the first and second resource quantities of multiple replica Pods of a service in a Kubernetes cluster when it is detected that multiple replica Pods need to be scaled up vertically. The first resource quantity is the existing resource quantity of the Pods to be scaled up, and the second resource quantity is the resource quantity required by the Pods to be scaled up.

[0012] The resource placeholder module is used to create a placeholder Pod for each Pod to be expanded; calculate the resource difference between the first and second resource amounts for each Pod to be expanded; and request the resource amount corresponding to the resource difference for each placeholder Pod; wherein, the placeholder Pod is used for resource placement and does not consume resources.

[0013] The expansion module is used to update the first resource quantity of each Pod to be expanded based on the resource quantity requested by the placeholder Pod corresponding to each Pod to be expanded, when the resource quantity corresponding to the resource quantity requested by the placeholder Pod is successfully applied for, so that the updated first resource quantity of each Pod to be expanded is the same as the second resource quantity.

[0014] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described method for vertical scaling of Pods in a Kubernetes cluster.

[0015] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for vertical scaling of Pods in a Kubernetes cluster.

[0016] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for vertical scaling of Pods in a Kubernetes cluster.

[0017] In this embodiment of the invention, when it is detected that multiple replica Pods of a service in a Kubernetes cluster need to be scaled vertically, the first and second resource quantities of the multiple Pods to be scaled are obtained. The first resource quantity is the existing resource quantity of the Pods to be scaled, and the second resource quantity is the resource quantity required by the Pods to be scaled. A placeholder Pod is created for each Pod to be scaled. The resource difference between the first and second resource quantities of each Pod to be scaled is calculated. The resource quantity corresponding to the resource difference is requested for each placeholder Pod to be scaled. The placeholder Pod is used for resource reservation and does not consume resources. If the request for the resource quantity corresponding to the resource difference for each placeholder Pod to be scaled is successful, the first resource quantity of each Pod to be scaled is updated according to the resource quantity requested for each placeholder Pod to be scaled, so that the updated first resource quantity of each Pod to be scaled is the same as the second resource quantity. Compared to existing vertical scaling solutions, this method creates placeholder Pods corresponding to the Pod to be scaled. These placeholder Pods are used only for resource allocation and do not consume resources. The resource quantity of the placeholder Pod is the difference between the first and second resource quantities of the corresponding Pod to be scaled. The first resource quantity of each Pod to be scaled is updated based on the resource quantity of the placeholder Pod corresponding to each Pod to be scaled. In this way, online vertical scaling can be achieved without restarting the container or modifying the Kubernetes source code. This allows for compatibility with open-source Kubernetes without affecting business continuity. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0019] Figure 1 This is a flowchart illustrating a method for vertical scaling of Pods in a Kubernetes cluster, as provided in an embodiment of the present invention.

[0020] Figure 2 This is a schematic diagram of a vertical scaling scheme for Pods in a Kubernetes cluster provided in an embodiment of the present invention.

[0021] Figure 3 This is a flowchart of another method for vertical scaling of Pods in a Kubernetes cluster provided in an embodiment of the present invention;

[0022] Figure 4This is a schematic diagram of a Pod vertical scaling device for a Kubernetes cluster provided in an embodiment of the present invention;

[0023] Figure 5 This is a schematic diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0025] In the description of this specification, the terms "comprising," "including," "having," and "containing" are open-ended terms, meaning that they include but are not limited to. The terms "an embodiment," "a specific embodiment," "some embodiments," and "for example," etc., refer to specific features, structures, or characteristics described in connection with that embodiment or example that are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. The order of steps involved in the various embodiments is used to illustrate the implementation of this application, and the order of steps is not limited and can be adjusted appropriately as needed.

[0026] Research has revealed a key issue that needs to be addressed during the containerization of enterprise applications: how to improve the cluster's ability to handle sudden increases in business traffic load by adjusting the size of the container cluster, thereby enhancing user experience and ensuring high availability of system services.

[0027] To address the aforementioned issues, two common scaling methods are used in Kubernetes cluster applications:

[0028] 1. Horizontal scaling, which means increasing the number of Pods to improve the overall service capacity of the application;

[0029] 2. Vertical scaling, which means increasing the resources of a single Pod to improve its service capabilities.

[0030] The two scaling methods described above are well-suited for stateless applications, offering great flexibility and ease of scaling up and down with minimal impact on business operations. However, they do not provide adequate support for stateful applications (databases, message queues, etc.). Currently, stateful applications (databases, message queues, etc.) require vertical scaling. However, existing vertical scaling methods have two main approaches: one requires restarting the container for each scaling operation, impacting business continuity; the other, while not requiring container restarts, necessitates modification of the Kubernetes source code, resulting in significant intrusion and substantial impact on subsequent Kubernetes version upgrades, potentially leading to incompatibility with upgraded Kubernetes versions.

[0031] To address the problems with existing vertical scaling methods, this invention provides a solution for achieving online vertical scaling without modifying the Kubernetes source code, which neither affects business continuity nor is compatible with open-source Kubernetes.

[0032] like Figure 1 The diagram shows a flowchart of a method for vertical scaling of Pods in a Kubernetes cluster according to an embodiment of the present invention. This method may include the following steps:

[0033] Step 101: When it is detected that multiple replica Pods of a service in the Kubernetes cluster need to be scaled up vertically, obtain the first resource quantity and the second resource quantity of the multiple Pods to be scaled up. The first resource quantity is the existing resource quantity of the Pods to be scaled up, and the second resource quantity is the resource quantity required by the Pods to be scaled up.

[0034] Step 102: Create a placeholder Pod for each Pod to be expanded; calculate the resource difference between the first and second resource amounts for each Pod to be expanded; request the resource amount corresponding to the resource difference for each placeholder Pod; wherein, the placeholder Pod is used for resource reservation and does not consume resources.

[0035] Step 103: If the resource amount corresponding to the resource difference for each placeholder Pod to be expanded is successfully applied for, the first resource amount of each Pod to be expanded is updated according to the resource amount applied for by the placeholder Pod to be expanded, so that the updated first resource amount of each Pod to be expanded is the same as the second resource amount.

[0036] In this embodiment of the invention, when it is detected that multiple replica Pods of a service in a Kubernetes cluster need to be scaled vertically, the first and second resource quantities of the multiple Pods to be scaled are obtained. The first resource quantity is the existing resource quantity of the Pods to be scaled, and the second resource quantity is the resource quantity required by the Pods to be scaled. A placeholder Pod is created for each Pod to be scaled. The resource difference between the first and second resource quantities of each Pod to be scaled is calculated. The resource quantity corresponding to the resource difference is requested for each placeholder Pod to be scaled. The placeholder Pod is used for resource reservation and does not consume resources. If the request for the resource quantity corresponding to the resource difference for each placeholder Pod to be scaled is successful, the first resource quantity of each Pod to be scaled is updated according to the resource quantity requested for each placeholder Pod to be scaled, so that the updated first resource quantity of each Pod to be scaled is the same as the second resource quantity. Compared to existing vertical scaling solutions, this method creates placeholder Pods corresponding to the Pod to be scaled. These placeholder Pods are used only for resource allocation and do not consume resources. The resource quantity of the placeholder Pod is the difference between the first and second resource quantities of the corresponding Pod to be scaled. The first resource quantity of each Pod to be scaled is updated based on the resource quantity of the placeholder Pod corresponding to each Pod to be scaled. In this way, online vertical scaling can be achieved without restarting the container or modifying the Kubernetes source code. This allows for compatibility with open-source Kubernetes without affecting business continuity.

[0037] like Figure 2 The diagram shown illustrates the principle of the Pod vertical scaling method for a Kubernetes cluster provided in this embodiment of the invention. The following section combines... Figure 2 right Figure 1 The method for vertical scaling of Pods in a Kubernetes cluster is explained in detail.

[0038] First, it's important to note that a Pod is the smallest resource object in a Kubernetes cluster, and Pods can be created using a PodTemplate. Furthermore, to facilitate control over Pods in a Kubernetes cluster, a Stable Model can be created to manage the Pod's lifecycle. The Stable Model is a workload model created based on actual needs and is a financial-grade stable deployment model.

[0039] In this embodiment of the invention, a corresponding StableModel can be created for each Pod. If the application resources of multiple replica Pods included in a service are insufficient and expansion is required, the PreResize field in the specification of the StableModel corresponding to each Pod can be updated.

[0040] In step 101 above, monitoring whether multiple replica Pods of a service in the Kubernetes cluster need vertical scaling can be done by configuring a StableModel controller to monitor the resources of each StableModel. For example... Figure 2 As shown, the StableModel controller listens to each StableModel through the kube-apiserver. If an update is detected in the StableModel, it compares the amount of resources required by the Pod corresponding to the StableModel (second resource amount) with the amount of resources the Pod currently has (first resource amount). If the second resource amount is greater than the first resource amount, it means that the Pod corresponding to the StableModel needs to be scaled up vertically.

[0041] In practice, the Pods corresponding to the multiple updated StableModels monitored by the StableModel controller can be identified as Pods to be scaled up, and the first and second resource quantities of each Pod to be scaled up can be obtained.

[0042] In practice, the second resource quantity for each Pod to be scaled up can be obtained through the PreResize field in the StableModel specification (spec):

[0043] PreResize / / Indicates the amount of resources to be pre-scaled for the Pod to be expanded.

[0044] In practice, the initial resource quantity of each Pod to be expanded can be obtained through the resource limit value in the Cgroup file of the Pod to be expanded. Alternatively, the initial resource quantity of each Pod to be expanded can be obtained in the following ways: if each Pod to be expanded is expanding for the first time, the initial resource quantity can be obtained through the native Resource field in the specification of the Pod to be expanded. If each Pod to be expanded has been expanded before and there is a placeholder Pod, the initial resource quantity can be obtained by adding the resource quantities obtained from the native Resource field in the specification of the Pod to be expanded and the existing placeholder Pod.

[0045] In step 102 above, when the StableModel controller detects that multiple replica Pods of a service in the Kubernetes cluster need to be scaled up vertically, it can create a placeholder Pod for each Pod to be scaled up and calculate the resource difference between the first and second resource amounts for each Pod to be scaled up; and apply for the resource amount corresponding to the resource difference for each placeholder Pod corresponding to the Pod to be scaled up.

[0046] Placeholder Pods consume almost no resources and only serve to reserve resources for subsequent scaling. Placeholder Pods need to be scheduled to the node where the Pod to be scaled is running, and their ownerReferences are the Pod to be scaled. The purpose is to allow the placeholder Pod to be deleted in a cascading manner when the Pod to be scaled is deleted, thus releasing the reserved resources.

[0047] In specific implementation, step 102 above can be as follows: Figure 2 As shown, the StableModel controller listens to the StableModel through the kube-apiserver, creates a placeholder Pod, and performs the pre-scaling process. During pre-scaling, the scaling status of the Pod to be scaled can be updated from the scaling phase ResizePhase to the pre-scaling phase PreResizing.

[0048] Specifically, the scaling status of a Pod to be scaled up can be represented by the following fields, and the ResizePhase field can be updated to PreResizing:

[0049] ResizePhase / / Indicates the current state of the Pod to be expanded during online expansion.

[0050] In practice, if the resource amount corresponding to the resource difference for each placeholder Pod to be expanded is successfully requested, it means that the pre-expansion is successful. The ResizePhase field in the expansion status field of the Pod to be expanded can be updated to PreResized.

[0051] In this embodiment of the invention, if the placeholder Pod corresponding to any Pod to be expanded fails to request the resource amount corresponding to the resource difference, the following steps can be performed:

[0052] If it fails to apply for the resource difference corresponding to any placeholder Pod that is to be expanded, the application for the resource difference corresponding to the placeholder Pod that is to be expanded will be repeated until the preset expansion time is reached, at which point a rollback operation will be performed or the resource amount of the node corresponding to the Pod that is to be expanded will be increased.

[0053] In practice, if a placeholder Pod fails to apply for the corresponding resources due to insufficient resources on the node corresponding to any Pod to be expanded, it can retry until the preset expansion time is reached (pre-expansion timeout). Alternatively, a rollback operation can be performed to cancel the pre-expansion, or the resources on the node corresponding to the Pod to be expanded can be increased.

[0054] In this embodiment of the invention, multiple Pods to be expanded for a service should ensure that all pre-expansion is successful (i.e., the placeholder Pods corresponding to the Pods to be expanded successfully apply for the resource amount corresponding to the resource difference) before the actual expansion can be carried out. This is to avoid the subsequent expansion failure due to insufficient resources of any placeholder Pods to be expanded, thereby improving the expansion efficiency.

[0055] In this embodiment of the invention, after pre-scaling is completed, the resize resource amount in the spec of the StableModel corresponding to the Pod to be scaled needs to be set to be consistent with the pre-scaling resource amount PreResize. Then, when the StableModel controller detects that the resize resource amount in the StableModel's spec is consistent with the pre-scaling resource amount PreResize, it can perform the following steps:

[0056] Set the expansion flag of the placeholder Pod corresponding to each Pod to be expanded to allow expansion.

[0057] In practice, the expansion labels of placeholder Pods can be represented by the following fields:

[0058] "alcor.io / resized" / / Indicates whether online scaling is performed for placeholder Pods and their Pods to be scaled. If the StableModel controller detects that the scaling resource amount Resize in the StableModel spec is consistent with the pre-scaling resource amount PreResize, it can set "alcor.io / resized" to true for each placeholder Pod corresponding to the Pod to be scaled (scaling is allowed).

[0059] In this embodiment of the invention, after setting "alcor.io / resized" to true for each placeholder Pod to be scaled up, the StableModel controller can also add the field "alcor.io / resources-pod" to the Pod to be scaled up. "alcor.io / resources-pod" represents the expected resource amount of the Pod to be scaled up after scaling (also representing the expected resource limit value in the Cgroup file of each Pod to be scaled up). Simultaneously, the ResizePhase of the scaling up status of the aforementioned Pod to be scaled up needs to be updated to Resizing. At this point, the process can proceed as follows: Figure 2 The expansion process is shown below.

[0060] In step 103 above, if the resource amount corresponding to the resource difference for each placeholder Pod to be expanded is successfully applied for, the first resource amount of each Pod to be expanded can be updated according to the resource amount applied for by each placeholder Pod to be expanded.

[0061] In specific implementation, such as Figure 2 As shown, the Cgroup controller is an agent component that runs on each node. It is used to listen for placeholder Pods scheduled to the current node and update the first resource amount of each Pod to be scaled up based on the resource amount requested by the placeholder Pod corresponding to each Pod to be scaled up.

[0062] In practice, the Cgroup controller first needs to filter out placeholder Pods on each node using the following fields:

[0063] "alcor.io / preresize-pod" / / Indicates whether it is a placeholder pod

[0064] Then, the container runtime is invoked (e.g., by calling...). Figure 2 (Docker), based on the resource amount requested by the placeholder Pod corresponding to each Pod to be expanded, update the first resource amount of each Pod to be expanded.

[0065] In this embodiment of the invention, step 103 may specifically include:

[0066] If the expansion flag of the placeholder Pod corresponding to each Pod to be expanded is set to allow expansion, the first resource quantity of each Pod to be expanded is updated by modifying the resource limit value in the Cgroup file of each Pod to be expanded, based on the resource quantity requested by the placeholder Pod corresponding to each Pod to be expanded.

[0067] In practice, the Cgroup controller can check if the "alcor.io / resized" field of the placeholder Pod corresponding to each Pod to be scaled up is true. If not, the scaling is skipped; otherwise, it is executed. Figure 2 The Cgroup update process shown is to use Docker to modify the resource limit value in the Cgroup file of each Pod to be scaled up, based on the resource amount requested by the placeholder Pod corresponding to each Pod to be scaled up.

[0068] In this embodiment of the invention, each Pod to be expanded may include multiple containers, and the resources requested in the placeholder Pod corresponding to each Pod to be expanded may be allocated to the containers in the Pod to be expanded.

[0069] In embodiments of the present invention, such as Figure 3As shown, based on the resource amount requested by the placeholder Pod corresponding to each Pod to be expanded, the first resource amount of each Pod to be expanded is updated by modifying the resource limit value in the Cgroup file of each Pod to be expanded. Specifically, this may include the following steps:

[0070] Step 301: Determine the amount of resources to be allocated to each container of each Pod to be expanded based on the pre-configured resource requirements of each container of each Pod to be expanded and the resource requests of the placeholder Pod corresponding to each Pod to be expanded.

[0071] Step 302: Modify the resource limit value in the Cgroup file corresponding to each container of each Pod to be expanded, based on the amount of resources to be allocated to each container of each Pod to be expanded.

[0072] In practice, the resource allocation amount for each container of each Pod to be scaled up can be calculated based on the pre-configured resource requirements for each container of each Pod to be scaled up and the resource allocation requested by the placeholder Pod corresponding to each Pod to be scaled up. Then, when the container runtime is invoked, the resource limit value in the Cgroup file corresponding to each container of each Pod to be scaled up is modified according to the resource allocation amount for each container of each Pod to be scaled up. Specifically, the Cgroup controller adds the field "alcor.io / resources-pod-current" to each Pod to be scaled up. "alcor.io / resources-pod-current" represents the actual resource amount of the Pod to be scaled up after the scaling is performed (which also represents the resource limit value in the Cgroup file of each Pod to be scaled up after scaling).

[0073] In this embodiment of the invention, after the Cgroup controller adds the field "alcor.io / resources-pod-current" to each Pod to be scaled up, the StableModel controller checks whether the fields "alcor.io / resources-pod-current" and "alcor.io / resources-pod" of each Pod to be scaled up are consistent. If they are consistent, it means that the online scaling up is complete, and the ResizePhase field in the scaling up status field of the above-mentioned Pod to be scaled up can be updated to Resized. If they are inconsistent, the next round of scaling up checks is required.

[0074] In this way, by using the above method for vertical scaling of Pods in a Kubernetes cluster, placeholder Pods are created for the Pod to be scaled. The placeholder Pods are only used to reserve resources and do not consume resources. The resource quantity of the placeholder Pod is the difference between the first and second resource quantities of the corresponding Pod to be scaled. The first resource quantity of each Pod to be scaled is updated by using the resource quantity of the placeholder Pod corresponding to each Pod to be scaled. In this way, online vertical scaling can be achieved without restarting the container or modifying the Kubernetes source code, thus ensuring compatibility with open source Kubernetes without affecting business continuity.

[0075] This invention also provides a device for vertical scaling of Pods in a Kubernetes cluster, as described in the following embodiments. Since the principle behind this device is similar to the method for vertical scaling of Pods in a Kubernetes cluster, its implementation can be found in the implementation of the method for vertical scaling of Pods in a Kubernetes cluster; details that are repeated will not be elaborated upon.

[0076] like Figure 4 The diagram shown is a schematic of a Pod vertical scaling device for a Kubernetes cluster according to an embodiment of the present invention. The device may include:

[0077] The acquisition module 401 is used to acquire the first and second resource quantities of multiple replica Pods of a service in a Kubernetes cluster when it is detected that multiple replica Pods need to be scaled up vertically. The first resource quantity is the existing resource quantity of the Pods to be scaled up, and the second resource quantity is the resource quantity required by the Pods to be scaled up.

[0078] The resource placeholder module 402 is used to create a placeholder Pod for each Pod to be expanded; calculate the resource difference between the first resource amount and the second resource amount of each Pod to be expanded; and apply for the resource amount corresponding to the resource difference for each placeholder Pod to be expanded; wherein, the placeholder Pod is used for resource placeholder and does not consume resources.

[0079] The expansion module 403 is used to update the first resource quantity of each Pod to be expanded according to the resource quantity requested by the placeholder Pod corresponding to each Pod to be expanded, so that the updated first resource quantity of each Pod to be expanded is the same as the second resource quantity.

[0080] In this embodiment of the invention, a setting module may also be included, used before the expansion module updates the first resource amount of each Pod to be expanded based on the resource amount requested by the placeholder Pod corresponding to each Pod to be expanded:

[0081] Set the expansion flag of the placeholder Pod corresponding to each Pod to be expanded to allow expansion.

[0082] In this embodiment of the invention, the expansion module can specifically be used for:

[0083] If the expansion flag of the placeholder Pod corresponding to each Pod to be expanded is set to allow expansion, the first resource quantity of each Pod to be expanded is updated by modifying the resource limit value in the Cgroup file of each Pod to be expanded, based on the resource quantity requested by the placeholder Pod corresponding to each Pod to be expanded.

[0084] In this embodiment of the invention, each Pod to be expanded may include multiple containers;

[0085] The expansion module can also be used for:

[0086] Based on the pre-configured resource requirements of each container in each Pod to be expanded and the resource requests of the placeholder Pod corresponding to each Pod to be expanded, determine the resource allocation amount for each container in each Pod to be expanded.

[0087] Based on the amount of resources to be allocated to each container of each Pod to be scaled up, modify the resource limit value of each container in the Cgroup file corresponding to each container of each Pod to be scaled up.

[0088] In this embodiment of the invention, a processing module may be further included, used after the resource placeholder module requests the resource amount corresponding to the resource difference for each placeholder Pod to be expanded:

[0089] If it fails to apply for the resource difference corresponding to any placeholder Pod that is to be expanded, the application for the resource difference corresponding to the placeholder Pod that is to be expanded will be repeated until the preset expansion time is reached, at which point a rollback operation will be performed or the resource amount of the node corresponding to the Pod that is to be expanded will be increased.

[0090] This invention also provides a computer device, such as... Figure 5 The diagram shows a computer device in an embodiment of the present invention. The computer device 500 includes a memory 510, a processor 520, and a computer program 530 stored in the memory 510 and executable on the processor 520. When the processor 520 executes the computer program 530, it implements the above-mentioned method for vertical scaling of Pods in a Kubernetes cluster.

[0091] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for vertical scaling of Pods in a Kubernetes cluster.

[0092] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for vertical scaling of Pods in a Kubernetes cluster.

[0093] In this embodiment of the invention, when it is detected that multiple replica Pods of a service in a Kubernetes cluster need to be scaled vertically, the first and second resource quantities of the multiple Pods to be scaled are obtained. The first resource quantity is the existing resource quantity of the Pods to be scaled, and the second resource quantity is the resource quantity required by the Pods to be scaled. A placeholder Pod is created for each Pod to be scaled. The resource difference between the first and second resource quantities of each Pod to be scaled is calculated. The resource quantity corresponding to the resource difference is requested for each placeholder Pod to be scaled. The placeholder Pod is used for resource reservation and does not consume resources. If the request for the resource quantity corresponding to the resource difference for each placeholder Pod to be scaled is successful, the first resource quantity of each Pod to be scaled is updated according to the resource quantity requested for each placeholder Pod to be scaled, so that the updated first resource quantity of each Pod to be scaled is the same as the second resource quantity. Compared to existing vertical scaling solutions, this method creates placeholder Pods corresponding to the Pod to be scaled. These placeholder Pods are used only for resource allocation and do not consume resources. The resource quantity of the placeholder Pod is the difference between the first and second resource quantities of the corresponding Pod to be scaled. The first resource quantity of each Pod to be scaled is updated based on the resource quantity of the placeholder Pod corresponding to each Pod to be scaled. In this way, online vertical scaling can be achieved without restarting the container or modifying the Kubernetes source code. This allows for compatibility with open-source Kubernetes without affecting business continuity.

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

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

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

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

[0098] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for vertical scaling of Pods in a Kubernetes cluster, characterized in that, include: For each Pod, create a corresponding stable deployment model; the stable deployment model is a workload model that controls the lifecycle of the Pod. When it detects that multiple replica Pods of a service in a Kubernetes cluster need to be scaled up vertically, the stable deployment model controller identifies the Pods corresponding to the multiple updated stable deployment models detected by the kube-apiserver as the Pods to be scaled up. It then obtains the first and second resource quantities for each Pod to be scaled up. The first resource quantity is the existing resource quantity of the Pod to be scaled up, and the second resource quantity is the required resource quantity. The second resource quantity for each Pod to be scaled up is obtained through the PreResize field in the description of the stable deployment model. The first resource quantity for each Pod to be scaled up is obtained as follows: if this is the first time a Pod to be scaled up is being scaled up, the first resource quantity is obtained through the native Resources field in the description of the Pod to be scaled up; if this Pod to be scaled up has been scaled up before and there is a placeholder Pod, the first resource quantity is obtained by adding the resource quantities obtained through the descriptions of the Pod to be scaled up and the existing placeholder Pod. Create a placeholder Pod for each Pod to be expanded; Calculate the resource difference between the first and second resource amounts for each Pod to be expanded; request the resource amount corresponding to the resource difference for each placeholder Pod corresponding to the Pod to be expanded; wherein, the placeholder Pod is used for resource reservation and does not consume resources; the placeholder Pod needs to be scheduled to the node where the Pod to be expanded is running, and the ownerReferences of the placeholder Pod is the Pod to be expanded. When the Pod to be expanded is deleted, the placeholder Pod is deleted in a cascading manner; update the expansion status of the Pod to be expanded from the expansion phase ResizePhase to the pre-expansion phase PreResizing; only when the placeholder Pods corresponding to multiple Pods to be expanded for a service successfully request the resource amount corresponding to the resource difference can the actual expansion be performed; If the resource amount corresponding to the resource difference for each placeholder Pod to be expanded is successfully applied for, the first resource amount of each Pod to be expanded is updated according to the resource amount applied for by the placeholder Pod to be expanded, so that the first resource amount of each Pod to be expanded is the same as the second resource amount; the ResizePhase field in the expansion status field of the above-mentioned Pod to be expanded is updated to PreResized. Each Pod to be expanded includes multiple containers; If the resource difference corresponding to the resource allocation for each placeholder Pod to be expanded is successfully obtained, the first resource allocation for each Pod to be expanded is updated based on the resource allocation obtained by the placeholder Pod, including: Based on the pre-configured resource requirements of each container in each Pod to be expanded and the resource requests of the placeholder Pod corresponding to each Pod to be expanded, determine the resource allocation amount for each container in each Pod to be expanded. The Cgroup controller checks whether the expansion identifier field "alcor.io / resized" of the placeholder Pod corresponding to each Pod to be expanded is true. If not, the expansion is skipped. If it is true, the resource limit value in the Cgroup file corresponding to each container of each Pod to be expanded is modified according to the amount of resources to be allocated for each container of each Pod to be expanded. After allocating the resource difference corresponding to each placeholder Pod for the Pod to be expanded, the following steps are also included: If it fails to apply for the resource difference corresponding to any placeholder Pod that is to be expanded, the application for the resource difference corresponding to the placeholder Pod that is to be expanded will be repeated until the preset expansion time is reached, at which point a rollback operation will be performed or the resource amount of the node corresponding to the Pod that is to be expanded will be increased.

2. The method of claim 1, wherein, Before updating the initial resource amount for each Pod to be expanded based on the resource amount requested by the placeholder Pod corresponding to each Pod to be expanded, the following steps are also included: Set the expansion flag of the placeholder Pod corresponding to each Pod to be expanded to allow expansion.

3. A pod vertical scaling device of a kubernetes cluster, characterized in that, include: The acquisition module is used to create a corresponding stable deployment model for each Pod. The stable deployment model is a workload model that controls the lifecycle of the Pod. When it detects that multiple replica Pods of a service in the Kubernetes cluster need to be scaled up vertically, the stable deployment model controller identifies the Pods corresponding to the multiple updated stable deployment models detected by the kube-apiserver as the Pods to be scaled up, and obtains the first and second resource quantities of the multiple Pods to be scaled up. The first resource quantity is the existing resource quantity of the Pod to be scaled up, and the second resource quantity is the resource quantity required by the Pod to be scaled up. The second resource quantity of each Pod to be scaled up is obtained through the PreResize field in the description of the stable deployment model. The first resource quantity of each Pod to be scaled up is obtained in the following ways: if each Pod to be scaled up is scaling up for the first time, the first resource quantity is obtained through the native Resource field in the description of the Pod to be scaled up. If each Pod to be scaled up has been scaled up before and there is a placeholder Pod, the first resource quantity is obtained by adding the resource quantity obtained through the description of the Pod to be scaled up and the resource quantity obtained through the native Resource field in the description of the existing placeholder Pod. The resource placeholder module is used to create a placeholder Pod for each Pod to be expanded; Calculate the resource difference between the first and second resource amounts for each Pod to be expanded; request the resource amount corresponding to the resource difference for each placeholder Pod corresponding to the Pod to be expanded; wherein, the placeholder Pod is used for resource reservation and does not consume resources; the placeholder Pod needs to be scheduled to the node where the Pod to be expanded is running, and the ownerReferences of the placeholder Pod is the Pod to be expanded. When the Pod to be expanded is deleted, the placeholder Pod is deleted in a cascading manner; update the expansion status of the Pod to be expanded from the expansion phase ResizePhase to the pre-expansion phase PreResizing; only when the placeholder Pods corresponding to multiple Pods to be expanded for a service successfully request the resource amount corresponding to the resource difference can the actual expansion be performed; The expansion module is used to update the first resource quantity of each Pod to be expanded, based on the resource quantity requested by the placeholder Pod corresponding to each Pod to be expanded, when the resource quantity corresponding to the placeholder Pod is successfully requested, so that the updated first resource quantity of each Pod to be expanded is the same as the second resource quantity; and to update the ResizePhase field in the expansion status field of the above-mentioned Pod to be expanded to PreResized. Each Pod to be expanded includes multiple containers; The expansion module is also used for: Based on the pre-configured resource requirements of each container in each Pod to be expanded and the resource requests of the placeholder Pod corresponding to each Pod to be expanded, determine the resource allocation amount for each container in each Pod to be expanded. The Cgroup controller checks whether the expansion identifier field "alcor.io / resized" of the placeholder Pod corresponding to each Pod to be expanded is true. If not, the expansion is skipped. If it is true, the resource limit value in the Cgroup file corresponding to each container of each Pod to be expanded is modified according to the amount of resources to be allocated for each container of each Pod to be expanded. The processing module is used after the resource placeholder module requests the resource amount corresponding to the resource difference for each placeholder Pod to be expanded: If it fails to apply for the resource difference corresponding to any placeholder Pod that is to be expanded, the application for the resource difference corresponding to the placeholder Pod that is to be expanded will be repeated until the preset expansion time is reached, at which point a rollback operation will be performed or the resource amount of the node corresponding to the Pod that is to be expanded will be increased.

4. The apparatus of claim 3, wherein, It also includes a settings module, used before the scaling module updates the initial resource amount of each Pod to be scaled based on the resource amount requested by the placeholder Pod corresponding to each Pod to be scaled: Set the expansion flag of the placeholder Pod corresponding to each Pod to be expanded to allow expansion.

5. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 2.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 2.

7. A computer program product, characterised in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 2.

Images