A method and system for variable starting resource limit of Kubernetes cloud-native container

Abstract

The application discloses a method for variable starting resource limitation of Kubernetes cloud native containers, relates to the field of information technology, and solves the technical problem of resource waste in the container running process, and the method comprises the following steps: adding a limitation value parameter and a duration parameter in Pod.Spec.Containers[i].Resources in a container group API structure; creating a container group and setting the limitation value parameter and the duration parameter; binding the container group and a node; starting the container on the node by Kubelet, and configuring the number of cpu cores of the started container to be limited to the limitation value parameter of the container group; starting a timing executor, and performing resource scaling operation on the container cpu limitation value in the container group to the configuration value of limits in Pod.Spec.Containers[i].Resources after the timing executor timing reaches the duration parameter of the container group. The application further discloses a system for variable starting resource limitation of Kubernetes cloud native containers.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information technology, more particularly, it relates to a method and system for variable starting resource limit of Kubernetes cloud native container. BACKGROUND

[0002] In Kubernetes cloud native cluster, the requests and limits in the field Pod.Spec.Containers[i].Resources of the container group (Pod) are usually used to control the application value and limit value of resources respectively, but this controls the application value and limit value of resources in the whole life cycle of the container group, and once configured, the fixed configuration will be adopted from the birth to the disappearance of the container group.

[0003] In many business scenarios that are not particularly busy, such fixed resource configuration makes the cpu and memory resources of the node cannot be fully utilized, for example, the container group application started on some nodes with relatively sufficient resources, many applications will be in a relatively busy state during the startup phase, that is, the cpu and memory will occupy a high proportion. When the startup phase is completed, the occupation of cpu and memory will rapidly decrease.

[0004] In this scenario, if the resource limit is configured to be low, it may cause the application to start too slowly, or even cause the application to fail to start due to memory exceeding the limit value. When the resource limit is configured to be high, it may exceed the quota limit of the namespace, or cause waste of resources during running.

[0005] In Kubernetes cloud native cluster, VPA (Vertical Autoscaler) is usually used to dynamically change the resource application value requests of the container group, but it will not modify the resource limit value limits, and when the resource application value is automatically modified, the container will be restarted, causing the application business to be interrupted. SUMMARY

[0006] The technical problem to be solved by the present application is to solve the above-mentioned deficiencies of the prior art. The first object of the present application is to provide a method for variable starting resource limit of Kubernetes cloud native container.

[0007] The second object of the present application is to provide a system for variable starting resource limit of Kubernetes cloud native container.

[0008] In order to achieve the above-mentioned first object, the present application provides a method for variable starting resource limit of Kubernetes cloud native container, comprising:

[0009] Step 1. Add the limit value parameter and the duration parameter in Pod.Spec.Containers[i].Resources in the container group API structure;

[0010] Step 2. Create a container group according to the container group API structure, set the limit value parameter and the duration parameter of the container group, and send a new request to the application interface server api-server;

[0011] Step 3. The api-server receives the new request and stores it in the distributed database etcd. After pre-selection and optimization by the scheduler, the container group and the node are bound;

[0012] Step 4. After the node's Kubelet listens to the binding of the container group and the node, it starts to start the container on the node and configures the cpu core limit of the container start to the limit value parameter of the container group;

[0013] Step 5. When Kubelet detects that the container group has been successfully started and is running normally, it starts a timing executor. When the timing executor reaches the duration parameter of the container group, Kubelet modifies the cpu limit value of the container in the container group to the configuration value of limits in Pod.Spec.Containers[i].Resources through the UpdateContainerResources interface of CRI to perform resource scaling operation.

[0014] As a further improvement, the step 4 specifically comprises:

[0015] Step 41. After Kubelet listens to the binding of the container group and the node, it sends a request to start the container through the StartContainer interface of CRI;

[0016] Step 42. Kubelet notifies the container runtime that the cpu resource limit of the container is the limit value parameter of the container group through the CRI interface;

[0017] Step 43. The container runtime limits the cpu usage of the container through the cgroups system according to the request of Kubelet, and sets the upper limit to the limit value parameter of the container group.

[0018] Further, a state parameter is added in the container group API structure; in the step 4, the state parameter is configured as the limit value parameter of the container group; after the step 5, the state parameter is configured as the configuration value of limits in Pod.Spec.Containers[i].Resources; and the state parameter is output in real time.

[0019] Further, the limit value parameter of the container group is greater than the configuration value of limits in Pod.Spec.Containers[i].Resources.

[0020] In order to achieve the above-mentioned purpose two, the application provides a system for variable starting resource limit of Kubernetes cloud native container, which comprises a container group API structure, an application program interface server api-server, a controller management control center Controller Manager, a scheduler Scheduler, a distributed database etcd, and a node Master Node.

[0021] The controller management control center Controller Manager creates a container group according to the container group API structure, and starts the container group to run according to the method.

[0022] Advantages

[0023] Compared with the prior art, the application has the following advantages:

[0024] The application adds a limit value parameter and a duration parameter in Pod.Spec.Containers[i].Resources in the container group API structure, so that a larger limit value parameter value can be independently configured in the resource limit value in the starting stage of the container group, which not only enables the container group with high load to be normally started, but also accelerates the starting speed of the application with more resources. BRIEF DESCRIPTION OF DRAWINGS

[0025] Fig. 1 The control flowchart of the method in the application is shown in the figure.

[0026] Fig. 2 The architecture diagram of the system in the application is shown in the figure.

[0027] Fig. 3 The architecture diagram of the container group and the node in the application. DETAILED DESCRIPTION

[0028] The application will be further described below with reference to the specific embodiments in the drawings.

[0029] Referring to Figs. 1-3 In the embodiment, three Master Nodes are used as control nodes, which are not responsible for running workloads, and only some components of Kubernetes run in the form of containers on them, including the application interface server API Server, the controller management control center Controller Manager, and the scheduler Scheduler.

[0030] In the embodiment, N Worker Nodes are used as work nodes, and each work node runs a Kubelet component and multiple container groups as workloads.

[0031] The API Server on each Master Node is connected with a distributed database etcd, which is used for storing various resource configurations and states in the cluster.

[0032] Each node contains a Kubelet component, which is used as a proxy for communication between the node and the Kubernetes cluster and is also used as a management component for the workload container groups on the node. Among them, the API Server is a control component of the Kubernetes cluster, which can receive requests for adding, modifying, deleting, and listening to resources such as Node, and reflect the modification to the etcd

[0033] The application provides a method for variable starting resource limitation of a Kubernetes cloud native container, which comprises the following steps:

[0034] Step 1. A limitation value parameter startupLimits is added in Pod.Spec.Containers[i].Resources in the container group API structure, the limitation value parameter startupLimits contains limitation values of cpu, memory, and a duration parameter initialDelaySeconds, and the duration parameter initialDelaySeconds is used for controlling the duration of the container starting resource limitation;

[0035] Step 2. Create a container group Pod1 according to the container group API structure, which contains the Pod.Spec.Containers[1].Resources parameter, sets the limit value parameter of the container group, the duration parameter, limits.cpu is configured as 1, startupLimits.cpu is configured as 2, startupLimits.initialDelaySeconds is configured as 60, indicating that the cpu limit of the container group in the normal running stage is 1 core, the cpu limit in the startup stage is 2 cores, and the duration of the startup stage is 60 seconds; the container group Pod1 sends a new request to the application interface server api-server;

[0036] Step 3. The api-server receives the new request sent by the container group Pod1 and stores it in the distributed database etcd. After pre-selection and optimization by the scheduler Scheduler, the container group Pod1 and the node Worker Node1 are bound;

[0037] Step 4. After the node Worker Node1 listens to the binding of the container group Pod1 and the node Worker Node1, it starts to start the container on the node Worker Node1 and configures the cpu core limit of the container startup as the limit value parameter startupLimits.cpu of the container group Pod1;

[0038] Step 5. When Kubelet detects that the container group Pod1 has been successfully started and is running normally, it starts a timing executor. When the timing executor timing reaches the duration parameter startupLimits.initialDelaySeconds of the container group Pod1, Kubelet modifies the cpu limit value of the container in the container group to the configuration value of limits.cpu in Pod.Spec.Containers[i].Resources through the UpdateContainerResources interface of CRI to perform resource scaling operation.

[0039] In step 4, it specifically includes:

[0040] Step 41. After Kubelet listens to the binding of the container group Pod1 and the node Worker Node1, it sends a request to start the container through the StartContainer interface of CRI;

[0041] Step 42. Kubelet notifies the container runtime that the cpu resource limit of the container is startupLimits.cpu of the container group Pod1 through the CRI interface.

[0042] Step 43. The container runtime limits the cpu usage of the container through the cgroups system according to the request of Kubelet, and sets the upper limit to the limit value parameter startupLimits.cpu of the container group Pod1.

[0043] The method also includes adding a state parameter Pod.Status.ContainerStatuses[i].Resources in the container group API structure; in step 4, configuring the limits.cpu in the state parameter Pod.Status.ContainerStatuses[1].Resources to the limit value parameter startupLimits.cpu of the container group, that is, configuring it to 2, which indicates that the cpu resource limit value of the container in the current container group Pod1 is 2 cores; after step 5, configuring the limits.cpu in the state parameter Pod.Status.ContainerStatuses[1].Resources to the configuration value of limits in Pod.Spec.Containers[i].Resources, that is, configuring it to 1, which indicates that the cpu resource limit value of the container in the current container group Pod1 is 1 core; and outputting the limits.cpu in the state parameter Pod.Status.ContainerStatuses[1].Resources in real time, such as through audio or video output, to remind the state of the container cpu resource limit value.

[0044] The configuration value of the limit value parameter startupLimits.cpu of the container group Pod1 is greater than the configuration value of limits.cpu in Pod.Spec.Containers[i].Resources.

[0045] A system based on Kubernetes cloud-native container variable startup resource limit, comprising a container group API structure, an application program interface server api-server, a controller management control center Controller Manager, a scheduler Scheduler, a distributed database etcd, a node Master Node, the node Master Node comprising a Kubelet component, the container group API structure module setting a limit value parameter and a duration parameter;

[0046] The controller management control center Controller Manager creates a container group Pod1 according to the container group API structure, and starts the container group to run according to the above method.

[0047] The application can be applied to cloud host, web application service, continuous integration and continuous deployment, and micro-service architecture, so as to solve the slow starting problem of the applications.

[0048] The application provides a time window for starting the container group by introducing the method for starting the variable resource configuration, in the time window, the container group obtains higher resource limit values, that is, obtains more resources for running, the starting speed of the application is accelerated, and after the time window, the resource limit values in the normal running time are restored, so that the node resources can be fully utilized.

[0049] The above is only the preferred embodiment of the application, it should be pointed out that for those skilled in the art, without departing from the structure of the application, a number of variations and improvements can be made, which will not affect the effect of the application and the practicability of the patent.

Claims

1. A method for Kubernetes cloud-native container variable startup resource limit based on, characterized in that, The application relates to a method for dynamically adjusting the CPU resource limit of a container group. The method comprises the following steps: Step 1. Adding a limit value parameter and a duration parameter in Pod.Spec.Containers[i].Resources in a container group API structure; Step 2. Creating a container group according to the container group API structure, setting the limit value parameter and the duration parameter of the container group, and sending a new creation request of the container group to an application interface server api-server; Step 3. The api-server receives the new creation request and stores the request in an etcd distributed database; after preselection and optimization by a scheduler, the container group and a node are bound; Step 4. After the node listens to the binding of the container group and the node, the Kubelet of the node starts a container on the node and configures the number of cpu cores of the started container to be limited to the limit value parameter of the container group; Step 5. When the Kubelet detects that the container group has been successfully started and is running normally, a timing executor is started; when the timing executor reaches the duration parameter of the container group, the Kubelet modifies the cpu limit value of the container in the container group to the configuration value of limits in Pod.Spec.Containers[i].Resources by calling an UpdateContainerResources interface of CRI to perform resource scaling operation; The step 4 specifically comprises the following steps: Step 41. After the Kubelet listens to the binding of the container group and the node, a request of starting the container is sent by calling a StartContainer interface of CRI; Step 42. The Kubelet notifies a container runtime that the cpu resource limit of the container is the limit value parameter of the container group by calling a CRI interface; Step 43. The container runtime limits the cpu usage of the container by a cgroups system according to the request of the Kubelet and sets the upper limit to be the limit value parameter of the container group; 2. The method for Kubernetes cloud-native container variable startup resource limit based on claim 1, wherein, A state parameter is added in the container group API structure; in the step 4, the state parameter is configured to be the limit value parameter of the container group; after the step 5, the state parameter is configured to be the configuration value of limits in Pod.Spec.Containers[i].Resources; and the state parameter is output in real time. The limit value parameter of the container group is greater than the configuration value of limits in Pod.Spec.Containers[i].Resources.

3. A system based on Kubernetes cloud-native container variable startup resource limit, comprising a container group API structure, an application program interface server api-server, a controller management control center Controller Manager, a scheduler Scheduler, a distributed database etcd, a node Master Node, the node Master Node comprising a Kubelet component, characterized in that, The container group API structure module sets a limit value parameter and a duration parameter; The controller management control center Controller Manager creates a container group according to the container group API structure and starts the container group to run according to the method in any one of claims 1-2.

Images