A resource management method for collaborative namespaces and control groups

Abstract

The present invention belongs to the technical field related to computer resource management, and discloses a resource management method for collaborative namespaces and control groups, including: creating a container of a shared namespace and adding an initialized linked list to the control group; when creating container resources, adding an index element for indexing the shared namespace where the resource is located to the linked list, and marking the resource as being controlled by the control group of the corresponding container; when exiting the container, finding the residual resources created by the exited container based on the linked list and the mark and managing them using the global control group; when creating resources again in a namespace with residual resources, giving priority to recycling the residual resources, and releasing those that cannot be recycled. Through the above method, the utilization rate of system resources can be improved, and the problem of certain resources being gradually exhausted during the operation of the host container service can be avoided.

Description

Technical Field

[0001] The present invention belongs to the technical field related to computer resource management, and more specifically, relates to a resource management method for collaborative namespaces and control groups. Background Art

[0002] Container technology has been widely applied in a wide range of fields, such as cloud computing, edge computing, and autonomous driving. Container technology has two cornerstones: namespaces and control groups (cgroups).

[0003] A namespace can isolate a group of processes and maintain resources specific to them, isolating them from global kernel resources. For example, a process namespace (PID) has a linked list independent of other PID namespaces. This linked list is used only to maintain all processes belonging to that PID namespace. When the last process in a namespace exits, the namespace disappears, and the kernel traverses all resources maintained by that namespace and destroys them.

[0004] Cgroups can implement statistics and limits on a set of resources (such as memory, I / O rate, network bandwidth, etc.). When a container is created, the runtime automatically creates a cgroup for the container. When a process is executed in the container, the container's own cgroup is used to limit the process's use of resources.

[0005] When using container technology in practice, problems with abnormal resource consumption may occasionally occur. That is, while the host is running the container service, some resources are gradually consumed, and the host may even crash, but the cgroup resource records of each container are not high. Summary of the Invention

[0006] In response to the above-mentioned defects or improvement needs of the existing technology, the present invention provides a detection method for container resource escape defects, the purpose of which is to detect whether there are problems with the container creation tool beforehand, so as to avoid resource exhaustion vulnerabilities during the use of container technology.

[0007] To achieve the above objectives, the present invention provides a resource management method for collaborative namespaces and control groups, comprising:

[0008] Creating a container in a shared namespace, generating a control group corresponding to the container, and adding an initialized linked list to the control group; creating a resource for the container in the shared namespace for the first time, adding an index element to the linked list for indexing the shared namespace where the resource is located, and marking the resource as being controlled by the control group of the corresponding container;

[0009] Exit the container, including:

[0010] Step S31: Determine whether the target linked list is empty. If so, jump to step S34. If not, execute step S32. The target linked list is the linked list corresponding to the currently exited container.

[0011] Step S32: traverse all resources in the shared namespace pointed to by the target linked list, find all resources controlled by the target control group according to the tag, and record them as residual resources; the target control group is the control group corresponding to the currently exited container;

[0012] Step S33: managing the residual resources using a global control group, where the global control group is a unique and globally shared control group in the kernel;

[0013] Step S34: exit the container and destroy the control group of the exited container;

[0014] Create resources again in the namespace with the remaining resources, including:

[0015] Step S41: Determine whether the residual resources are managed by the global control group. If so, execute step S42; if not, execute step S43.

[0016] Step S42: Determine whether the amount of the remaining resources exceeds the resource upper limit of the current container. If so, execute step S43; if not, execute step S44;

[0017] Step S43: Release the residual resources, apply for resources from the kernel, add an index element for indexing the shared namespace where the applied resources are located in the linked list corresponding to the current container, and mark the applied resources as being controlled by the control group of the current container; jump to step S45;

[0018] Step S44: transferring the management information of the residual resources in the global control group to the control group of the current container to use the residual resources as resources of the current container, thereby realizing recycling of the residual resources;

[0019] Step S45: End resource creation.

[0020] Preferably, the linked list includes one or more sub-linked lists, different sub-linked lists correspond to different types of namespaces, and elements in the same sub-linked list are used to index various namespaces belonging to the same type of namespace.

[0021] Preferably, the global control group has an initial resource upper limit that does not exceed a hard upper limit and the resource upper limit of the global control group is dynamically adjustable, and the hard upper limit is a fixed preset upper limit;

[0022] In step S33, the residual resources are managed using a global control group, including:

[0023] Step S331: Determine whether the current resource limit of the global control group is greater than the resource limit of the control group to be destroyed. If so, jump to step S333; if not, execute step S332;

[0024] Step S332: adjusting the resource upper limit of the global control group to the smaller of the hard upper limit and the resource upper limit of the control group to be destroyed;

[0025] Step S333: Determine whether the global control group can fully accommodate the residual resources. If yes, execute step S338:

[0026] Step S338: Use the global control group to manage the residual resources, and jump to step S34.

[0027] Preferably, in step S333, if the global control group cannot fully accommodate the residual resources, at least part of the residual resources managed by the control group are released and it is determined again whether the global control group can fully accommodate the residual resources. If so, the global control group is used to manage the residual resources; if not, the residual resources are released.

[0028] Preferably, releasing at least part of the residual resources managed by the control group and determining again whether the global control group can fully accommodate the residual resources includes:

[0029] Step S334: Initialize the count value of the counter;

[0030] Step S335: releasing all residual resources in the global control group whose residual time is greater than or equal to the current count value, and reducing the count value by 1;

[0031] Step S336: Determine whether the global control group can fully accommodate the residual resources. If yes, execute step S338; if no, execute step S337;

[0032] Step S337: Determine whether the current count value is equal to -1. If so, release the residual resources and jump to step S34; if not, jump to step S335;

[0033] Step S338: Use the global control group to manage the residual resources, set the residual time of the newly added residual resources in the global control group to 0, add 1 to the residual time of the existing residual resources, and jump to step S34.

[0034] Preferably, in step S334, the count value is initialized to 5.

[0035] Preferably, a transfer instruction is added to the kernel function for accessing the namespace. When creating resources for the container in the namespace, the namespace is accessed through the kernel function with the transfer instruction added. When there are residual resources in the accessed namespace, the instruction is triggered to execute steps S41 to S45.

[0036] The present invention also provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any of the above methods when executing the computer program.

[0037] The present invention also provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of any of the above methods are implemented.

[0038] The present invention also provides a computer program product, comprising a computer program or instructions, which implement the steps of any of the above methods when executed by a processor.

[0039] In general, the above technical solutions conceived by the present invention have the following beneficial effects compared with the prior art:

[0040] 1. The present invention first discovered the problem of gradual resource exhaustion when using container technology. The reason is that when multiple containers share a namespace, during the container restart, the resources previously created by the container and the cgroup that manages the resources cannot be destroyed synchronously. Its cgroup can usually be cleared when the container is restarted, but the resources previously created are likely to still exist in the namespace. These resources are not managed by the cgroup, forming residual resources. As the number of container restarts increases, the residual resources gradually accumulate, leading to resource exhaustion. Based on the root cause of the problem found, the present invention proposes a resource management method for collaborative namespace and cgroup, adding a linked list in the cgroup, based on which the namespace where the container is located can be indexed, when creating resources for the container in the namespace, the created resources are marked, and through the added linked list and the added mark, it can be indexed which namespaces the container has created which resources; when the container exits, its corresponding cgroup will be destroyed, and the resources in the shared namespace managed by its cgroup may still remain in the namespace. Based on the linked list and the mark, the residual resources in the shared namespace can be found and managed by the global cgroup. In this way, after the container exits and its cgroup is destroyed, the global cgroup still manages the residual resources to avoid resource escape. When other containers in the shared namespace need to apply for resources, the residual resources managed by the global cgroup are recycled first to improve the utilization of system resources. When they cannot be recycled, the residual resources are released. In this way, the problem of certain resources being gradually exhausted during the operation of the container service on the host can be avoided.

[0041] 2. Furthermore, by designing the resource limit of the global cgroup, it is adjusted according to the resource limit of the current cgroup to be destroyed and will not exceed its hard limit. This ensures that the residual resources are always kept within a reasonable range and can prevent malicious attacks.

[0042] 3. Furthermore, a counter is set. When the remaining resource space of the global cgroup is insufficient, the counter is used to count and the residual resources managed by the global cgroup are released to a certain extent according to the first-in-first-out principle. If there is still not enough space to accommodate the residual resources after the release, it is considered that the residual resources may be subject to malicious attacks and are directly released to ensure system security. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 This is a flowchart of a method for detecting container resource escape defects in one embodiment of the present invention;

[0044] Figure 2 is a flow chart of steps for managing the residual resources in one embodiment of the present invention;

[0045] Figure 3 It is a flow chart of the steps for managing the residual resources in another embodiment of the present invention. DETAILED DESCRIPTION

[0046] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the present invention and are not intended to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

[0047] When creating multiple containers simultaneously, there are two scenarios: one in which the containers share a namespace and the other in which they do not. When containers do not share a namespace, each container has its own namespace and cgroup, and the coordination between the namespace and cgroup is reasonable. The namespace and cgroup are destroyed simultaneously when the container exits. All cgroup resource records and cgroup limits applied by the container disappear with the destruction of the cgroup, and the resources in the namespace itself also disappear with the destruction of the namespace. When multiple containers share the same namespace, the namespace is not destroyed when one container exits because it is still in use by other containers.

[0048] Research has found that when multiple containers share a namespace, the resources created in the namespace before the container exits may still exist in the namespace after the container exits, and the cgroup resource record value of the container may be cleared or reduced due to the exit of the container. That is, the actual resources existing in the namespace exceed the cgroup resource record value of all containers in the namespace, and the resources not recorded by the cgroup resource are escaped resources. Therefore, as the container is restarted (each restart performs an exit and reconstruction), the escaped resources increase, and the resources actually requested by the container far exceed its cgroup resource record value, resulting in resource exhaustion.

[0049] Based on the above findings, the present invention proposes the following solutions.

[0050] like Figure 1FIG2 is a flowchart of a method for collaborative namespace and control group resource management in one embodiment of the present invention, and each step is introduced below.

[0051] Step S1: Create a container that shares a namespace, generate a control group corresponding to the container, and add an initialized linked list to the control group.

[0052] This step is the stage of creating a container, and the container is created according to the user's instructions.

[0053] Typically, when a container is created, a corresponding control group (cgroup) is automatically generated. The created container often corresponds to multiple different namespaces to run different system calls in different namespaces. The cgroup is used to limit the amount of resources created by the container in different namespaces.

[0054] Under the existing framework, the implementation of cgroups and namespaces is independent of each other. This makes it impossible for cgroups to identify the namespace in which the resources managed by cgroups are located. When cgroups exit, they are also unable to identify which resources need to be released. To this end, the present invention expands the cgroup data structure by adding linked lists. Specifically, each element of the linked list can be a pointer to a specific namespace. These namespaces are the namespaces where all processes in the cgroup are located. This method can bind a cgroup to a specific namespace, such as the IPC, network, and PID namespace. These linked lists are dynamically updated as processes join the cgroup.

[0055] In this step, the container's cgroup data structure is improved so that each cgroup also contains a linked list that is used to index the shared namespaces in which the resources managed by the cgroup are located. Specifically, due to the different types of namespaces, such as the process namespace (PID namespace), the inter-process communication namespace (IPC namespace), the network namespace (Network namespace), and the mount namespace (Mount namespace), the linked list can contain multiple sub-linked lists, each corresponding to a different type of namespace. There can be multiple namespaces of each type, and the elements in the sub-linked lists are used to index which shared namespace within the corresponding type of namespace. These linked lists are initialized during the cgroup creation process. When subsequent virtual resources are created, a non-duplicate namespace element will be inserted into the specific cgroup instance.

[0056] It should be noted that for non-shared namespaces, that is, a namespace has only one container, the namespace will be destroyed along with the container exit, and the resources in the namespace will be released directly. Therefore, there will be no residual resources and no additional management is required.

[0057] Step S2: initially creating a resource for the container in the shared namespace, adding an index element for indexing the shared namespace where the resource is located in the linked list, and marking the resource as being controlled by the control group of the corresponding container.

[0058] This step is to create resources in the shared namespace for the first time according to the user's instructions. At this point, there are no remaining resources in the namespace.

[0059] When a container executes a system call, it must create the virtual resources required to execute that system call, such as memory, I / O speed, and network bandwidth, in the corresponding namespace. To enable subsequent collaborative management, the present invention incorporates a marking operation when creating resources for a container, marking the created resources as being controlled by the corresponding container's cgroup. For example, a cgroup pointer can be added to all virtual resources (such as shared memory in an IPC namespace). This pointer points to the cgroup that manages and limits the resource, and is assigned a value when the virtual resource is created.

[0060] Through the added linked list and the added tags, it is possible to index which resources the container has created in which shared namespaces.

[0061] Step S3: Exit the container.

[0062] This step exits certain containers based on user instructions. At this point, other containers in the shared namespace cannot be terminated because they still exist. The container to be exited is the target container, its linked list is the target linked list, and its control group is the target cgroup. The following describes the specific execution process.

[0063] Step S31: Determine whether the target linked list is empty. If it is empty, jump to step S34; if it is not empty, execute step S32.

[0064] It should be noted that the target linked list is empty, indicating that the created container is not in any shared namespace. In this case, exit the container directly without any additional operation.

[0065] Step S32: traverse all resources in the shared namespace pointed to by the target linked list, find all resources controlled by the target control group according to the tag, and record them as residual resources.

[0066] By combining the target list and the tag, we can find all the resources controlled by the target cgroup as residual resources.

[0067] Step S33: managing the residual resources using the global control group, which is the only and globally shared control group in the kernel.

[0068] Since when a container exits, the resources it creates will not be controlled by the cgroup and will become unmanageable residual resources, in order to circumvent this problem, the present invention sets up a global cgroup, which opens all subsystems by default to take over the residual resources in all namespaces. For example, a global variable pointer can be added to point to this global cgroup. Based on the settings of the linked list and mark in the above steps, the residual resources can be located and their management information can be recorded to the global cgroup. At this time, the global cgroup has the amount of residual resources and the linked list for indexing the namespace. Specifically, the original mark can be updated to the mark of the residual resource to facilitate the subsequent judgment of whether there are residual resources in the namespace.

[0069] When it is necessary to exit a container, the kernel function cgroup_rmdir will be used to release the cgroup corresponding to the container. In a specific embodiment, the cgroup_rmdir function can be used to check whether the cgroup has any residual resources. If so, these resources are transferred to the global cgroup and re-labeled as residual resources managed by the global cgroup, indicating that these resources will be managed and restricted by the global cgroup. At this time, the record of the cgroup to be destroyed also needs to be transferred to the global cgroup.

[0070] Step S34: Exit the container and destroy the control group of the exited container.

[0071] Step S4: Create resources again in the shared namespace with the remaining resources.

[0072] The specific steps are as follows.

[0073] Step S41: Determine whether the residual resources are managed by the global control group. If so, execute step S42; if not, execute step S43.

[0074] Step S42: Determine whether the amount of the remaining resources exceeds the resource upper limit of the current container. If so, execute step S43; if not, execute step S44.

[0075] Step S43: Release the remaining resources, apply for resources from the kernel, add an index element for indexing the shared namespace where the applied resources are located in the linked list corresponding to the current container, and mark the applied resources as being controlled by the control group of the current container; jump to step S45.

[0076] Specifically, if the remaining resources are too large, exceeding the cgroup limit of the current container, then the remaining resources cannot be transferred to the current container. In this case, the remaining resources are directly released from the namespace, and the released resources become available resources in the kernel. Similarly, the steps in step S2 are used to request resources from the kernel and mark the requested resources as being controlled by the cgroup of the current container.

[0077] Step S44: Transferring the management information of the residual resources in the global control group to the control group of the current container to use the residual resources as resources of the current container, thereby realizing the recycling of the residual resources.

[0078] Specifically, the management information corresponding to the residual resources in the global cgroup is directly moved to the cgroup of the current container, including the resource amount and the linked list. The residual resources after the transfer are used as the resources of the current container, and the mark of the residual resources is updated to the mark of the corresponding resources of the current container.

[0079] Step S45: End resource creation.

[0080] Specifically, when the container exits, the container exit may be performed according to the operation of step S3.

[0081] In a specific embodiment, a transfer instruction may be added to a kernel function for accessing a namespace. When resources are created for a container in a namespace, the namespace is accessed through the kernel function to which the transfer instruction is added. When there are residual resources in the accessed namespace, an instruction is triggered to execute steps S41 to S45.

[0082] The present invention proposes a resource management method for collaborative namespace and cgroup. When creating a container, the generated cgroup includes a corresponding linked list. Based on the linked list, the namespace where the container is located can be indexed. When creating resources for the container in the namespace, the created resources are marked. Through the linked list added when creating the container and the mark added when creating the resource for the container, it can be indexed which namespaces the container has created which resources. When the container exits, its corresponding cgroup will be destroyed, and the resources in the shared namespace managed by its cgroup may still remain in the namespace. Based on the linked list and the mark, the residual resources in the shared namespace can be found and managed by the global cgroup. In this way, after the container exits and its cgroup is destroyed, the global cgroup still manages the residual resources, avoiding resource escape. When other containers in the shared namespace need to apply for resources, the residual resources managed by the global cgroup are first recovered to improve system resource utilization. When the residual resources cannot be recovered, the residual resources are released. In this way, the problem of certain resources being gradually exhausted during the operation of the container service on the host can be avoided.

[0083] In one embodiment, the global control group has an initial resource limit that does not exceed the hard limit, and the resource limit of the global control group is dynamically adjustable. The hard limit is a fixed preset limit. A feasible execution method for step S33 is further proposed, such as Figure 2 The figure shows a flow chart of the steps for managing residual resources in one embodiment of the present invention, which is described in detail below.

[0084] Step S331: Determine whether the current resource limit of the global control group is greater than the resource limit of the control group to be destroyed. If so, jump to step S333; if not, execute step S332;

[0085] Step S332: Adjust the resource upper limit of the global control group to the smaller of the hard upper limit and the resource upper limit of the control group to be destroyed;

[0086] Step S333: Determine whether the global control group can fully accommodate the remaining resources. If so, execute step S338:

[0087] Step S338: Use the global control group to manage the remaining resources.

[0088] In this embodiment, the resource upper limit of the global cgroup is designed so that it is adjusted according to the resource upper limit of the cgroup to be destroyed and does not exceed its hard upper limit. This ensures that the residual resources are always kept within a reasonable range and prevents malicious attacks.

[0089] Furthermore, the above embodiment can also be optimized, that is, in step S333, if the global control group cannot fully accommodate the residual resources, then at least part of the residual resources managed by the control group are released and it is judged again whether the global control group can fully accommodate the residual resources. If so, the global control group is used to manage the residual resources; if not, the residual resources are released.

[0090] like Figure 3 Shown is a flowchart of the steps for managing residual resources in another embodiment of the present invention, which is introduced in detail below.

[0091] Step S331: Determine whether the current resource limit of the global control group is greater than the resource limit of the control group to be destroyed. If so, jump to step S333; if not, execute step S332;

[0092] Step S332: Adjust the resource upper limit of the global control group to the smaller of the hard upper limit and the resource upper limit of the control group to be destroyed;

[0093] Step S333: Determine whether the global control group can fully accommodate the remaining resources. If so, execute step S338:

[0094] Step S334: Initialize the count value of the counter;

[0095] Step S335: Release all residual resources in the global control group whose residual time is greater than or equal to the current count value, and reduce the count value by 1;

[0096] Step S336: Determine whether the global control group can fully accommodate the remaining resources. If so, execute step S338; if not, execute step S337;

[0097] Step S337: Determine whether the current count value is equal to -1. If so, release the remaining resources and jump to step S34; if not, jump to step S335;

[0098] Step S338: Use the global control group to manage residual resources, set the residual time of newly added residual resources in the global control group to 0, add 1 to the residual time of existing residual resources, and jump to step S34.

[0099] Specifically, the initial count value of the counter may be 5. If it is still insufficient after releasing 6 times, the remaining resources of the exited container are directly released.

[0100] In this embodiment, a counter is further set. When the remaining resource space of the global cgroup is insufficient, the counter is used to count and the residual resources managed by the global cgroup are released to a certain extent according to the first-in-first-out principle. If the residual resources are still not enough to accommodate the remaining resources after the release, it is considered that the residual resources may be subject to malicious attacks and are directly released to ensure system security.

[0101] Example 2

[0102] The present invention also relates to an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0103] The electronic device may be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The processor may be a central processing unit (CPU), or other general-purpose processors, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The memory may be used to store computer programs and / or modules, and the processor may perform various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling the data stored in the memory.

[0104] Example 3

[0105] The present invention also relates to a computer-readable storage medium having a computer program stored thereon, which implements the steps of the above method when the computer program is executed by a processor.

[0106] Specifically, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage device.

[0107] Example 4

[0108] An embodiment of the present invention provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of the method of the above embodiment of the present invention.

[0109] The technical features of the above embodiments can be combined in any manner. To simplify the description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification. It should be noted that the phrases "in one embodiment", "for example", "and another example", etc. of the present invention are intended to illustrate the present invention and are not intended to limit the present invention.

[0110] The above embodiments merely illustrate several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, and all such variations and improvements fall within the scope of protection of the present invention.

Claims

1. A resource management method for collaborative namespaces and control groups, characterized in that: include: Create a container with a shared namespace, generate a control group corresponding to the container, and add an initialized linked list to the control group; When a container creates a resource for the first time in the shared namespace, an index element for indexing the shared namespace where the resource is located is added to the linked list, and the resource is marked as being controlled by the control group of the corresponding container; Exit the container, including: Step S31: Determine whether the target linked list is empty. If so, jump to step S34. If not, execute step S32. The target linked list is the linked list corresponding to the currently exited container. Step S32: traverse all resources in the shared namespace pointed to by the target linked list, find all resources controlled by the target control group according to the tag, and record them as residual resources; the target control group is the control group corresponding to the currently exited container; Step S33: managing the residual resources using a global control group, where the global control group is a unique and globally shared control group in the kernel; Step S34: exit the container and destroy the control group of the exited container; Create resources again in the namespace with the remaining resources, including: Step S41: Determine whether the residual resources are managed by the global control group. If so, execute step S42; if not, execute step S43. Step S42: Determine whether the amount of the remaining resources exceeds the resource upper limit of the current container. If so, execute step S43; if not, execute step S44; Step S43: Release the residual resources, apply for resources from the kernel, add an index element for indexing the shared namespace where the applied resources are located in the linked list corresponding to the current container, and mark the applied resources as being controlled by the control group of the current container; jump to step S45; Step S44: transferring the management information of the residual resources in the global control group to the control group of the current container to use the residual resources as resources of the current container, thereby realizing recycling of the residual resources; Step S45: End resource creation.

2. The resource management method according to claim 1, wherein: The linked list includes one or more sub-linked lists, different sub-linked lists correspond to different types of namespaces, and elements in the same sub-linked list are used to index various namespaces belonging to the same type of namespace.

3. The resource management method according to claim 1, wherein: The global control group has an initial resource upper limit that does not exceed a hard upper limit, and the resource upper limit of the global control group is dynamically adjustable, and the hard upper limit is a fixed preset upper limit; In step S33, the residual resources are managed using a global control group, including: Step S331: Determine whether the current resource limit of the global control group is greater than the resource limit of the control group to be destroyed. If so, jump to step S333; if not, execute step S332; Step S332: adjusting the resource upper limit of the global control group to the smaller of the hard upper limit and the resource upper limit of the control group to be destroyed; Step S333: Determine whether the global control group can fully accommodate the residual resources. If yes, execute step S338: Step S338: Use the global control group to manage the residual resources, and jump to step S34.

4. The resource management method according to claim 3, wherein: In step S333, if the global control group cannot fully accommodate the residual resources, at least part of the residual resources managed by the control group are released and it is determined again whether the global control group can fully accommodate the residual resources. If so, the global control group is used to manage the residual resources; if not, the residual resources are released.

5. The resource management method according to claim 4, wherein: The releasing at least part of the residual resources managed by the control group and determining again whether the global control group can fully accommodate the residual resources includes: Step S334: Initialize the count value of the counter; Step S335: releasing all residual resources in the global control group whose residual time is greater than or equal to the current count value, and reducing the count value by 1; Step S336: Determine whether the global control group can fully accommodate the residual resources. If yes, execute step S338; if no, execute step S337; Step S337: Determine whether the current count value is equal to -1. If so, release the residual resources and jump to step S34; if not, jump to step S335; Step S338: Use the global control group to manage the residual resources, set the residual time of the newly added residual resources in the global control group to 0, add 1 to the residual time of the existing residual resources, and jump to step S34.

6. The resource management method according to claim 4, wherein: In step S334, the count value is initialized to 5.

7. The resource management method according to claim 1, wherein: A transfer instruction is added to the kernel function for accessing the namespace. When creating resources for a container in the namespace, the namespace is accessed through the kernel function with the transfer instruction added. When there are residual resources in the accessed namespace, the instruction is triggered to execute steps S41 to S45.

8. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images