Container group creation method and device, computer equipment and readable storage medium

Abstract

The invention relates to the technical field of cluster management, in particular to a container group creation method and device, computer equipment and a readable storage medium. The method comprises the steps of selecting a target sandbox container environment from existing container sandbox environments of resource nodes in a cluster according to a Pod creation request under the condition that the Pod creation request of a container group is obtained; the existing container sandbox environment of each resource node is pre-established according to a sandbox environment establishment request sent by the scheduler to the resource node; and in the target sandbox container environment, creating a target Pod corresponding to the Pod creation request.

Description

Technical Field

[0001] The present application relates to the technical field of cluster management, and in particular to a method, apparatus, computer device, and readable storage medium for creating a container group. Background Art

[0002] In a Kubernetes cluster, a Pod is the smallest deployable computing unit. It is the smallest unit that can be created and managed, and is a collection of one or more containers. These containers share the same network namespace, meaning they can communicate using the same IP address and port space, and they also share the same storage volume, making it easy to share data between containers.

[0003] Pods are not persistent. When a Pod is deleted or expelled from the cluster for some reason, Kubernetes will automatically recreate new Pods to replace them as needed. In the traditional Pod creation process, each time a new Pod is started, the container runtime needs to create a new Sandbox environment.

[0004] However, the above process takes a lot of time, especially when a large number of Pods need to be started, which results in a slow container group creation time. Therefore, improvement is urgently needed. Summary of the Invention

[0005] Based on this, it is necessary to provide a container group creation method, apparatus, computer device and readable storage medium that can optimize the timeliness of container group creation in order to address the above technical issues.

[0006] In a first aspect, the present application provides a method for creating a container group, which is applied to a scheduler in a cluster. The method includes:

[0007] When a container group Pod creation request is received, the scheduler selects a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster based on the Pod creation request. The existing container sandbox environment of each resource node is pre-established based on the sandbox environment creation request sent by the scheduler to the resource node.

[0008] In the target sandbox container environment, create the target Pod corresponding to the Pod creation request.

[0009] In one embodiment, according to a Pod creation request, selecting a target sandbox container environment from existing container sandbox environments of each resource node in the cluster includes:

[0010] Match the resource configuration requirements carried in the Pod creation request with the resource amounts of the existing container sandbox environments of each resource node in the cluster to obtain at least one candidate container sandbox environment that meets the resource configuration requirements.

[0011] A target sandbox container environment is selected from the candidate container sandbox environments according to the environment attribute information of each candidate container sandbox environment.

[0012] In one embodiment, the environment attribute information includes at least health status, creation time, and resource utilization.

[0013] In one embodiment, an existing container sandbox environment of any resource node is created in the resource node according to a sandbox environment creation request sent by a scheduler; wherein the sandbox environment creation request includes at least one sandbox environment type and the number of sandbox environments corresponding to each sandbox environment type; the storage resources and computing resources occupied by the sandbox environments corresponding to each sandbox environment type are different.

[0014] In one embodiment, the sandbox environment creation request of each resource node is generated in the following manner:

[0015] Obtain the node resource limit and node load of each resource node;

[0016] Based on the node resource limit and node load of each resource node, and subject to the set planning conditions as constraints, determine the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type; the planning conditions at least include the load balancing conditions between each resource node and the security isolation conditions between different container sandbox environments in the same resource node;

[0017] A sandbox environment creation request for each resource node is generated according to the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type.

[0018] In one embodiment, the method further includes: sending a request for creating a sandbox environment of the resource node to an agent component in the resource node through the control component.

[0019] In a second aspect, the present application further provides a container group creation device, configured in a scheduler in a cluster, comprising:

[0020] The request acquisition module is used to select a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster based on the Pod creation request when a container group Pod creation request is obtained. The existing container sandbox environment of each resource node is pre-established based on the sandbox environment creation request sent by the scheduler to the resource node.

[0021] The container group creation module is used to create the target Pod corresponding to the Pod creation request in the target sandbox container environment.

[0022] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0023] When a container group Pod creation request is received, the scheduler selects a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster based on the Pod creation request. The existing container sandbox environment of each resource node is pre-established based on the sandbox environment creation request sent by the scheduler to the resource node.

[0024] In the target sandbox container environment, create the target Pod corresponding to the Pod creation request.

[0025] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the following steps:

[0026] When a container group Pod creation request is received, the scheduler selects a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster based on the Pod creation request. The existing container sandbox environment of each resource node is pre-established based on the sandbox environment creation request sent by the scheduler to the resource node.

[0027] In the target sandbox container environment, create the target Pod corresponding to the Pod creation request.

[0028] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, which, when executed by a processor, implements the following steps:

[0029] When a container group Pod creation request is received, the scheduler selects a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster based on the Pod creation request. The existing container sandbox environment of each resource node is pre-established based on the sandbox environment creation request sent by the scheduler to the resource node.

[0030] In the target sandbox container environment, create the target Pod corresponding to the Pod creation request.

[0031] The above-mentioned container group creation method, device, computer equipment and readable storage medium, in this application, pre-creates an existing sandbox container environment in each resource node, and completes the time-consuming preparation work of creating a sandbox container environment before starting the Pod in advance, thereby simplifying the Pod creation process and reducing the cold start time of the Pod. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0033] Figure 1 A diagram illustrating an application environment of a container group creation method according to an embodiment;

[0034] Figure 2 A schematic diagram of a process for creating a container group in one embodiment;

[0035] Figure 3 A schematic diagram of a process for selecting a target container sandbox environment in one embodiment;

[0036] Figure 4 A schematic diagram of a process for generating a sandbox environment creation request for each resource node in one embodiment;

[0037] Figure 5 A structural block diagram of a container group creation apparatus in one embodiment;

[0038] Figure 6 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0040] Kubernetes (K8s), as a core component of the current cloud-native technology stack, provides developers with a powerful containerized application management solution. The following is an explanation of the concepts in Kubernetes:

[0041] Kubernetes (K8s): K8s is not just a container orchestration tool, but a complete container ecosystem. It defines application state through declarative configuration (such as YAML files) and uses controllers to ensure that the actual state in the cluster matches the desired state. This control-loop-based design enables K8s to automatically handle complex tasks such as container creation, scheduling, upgrades, and fault recovery.

[0042] Pod: A pod is the fundamental unit of work in Kubernetes, encapsulating one or more closely related containers. These containers share the same network namespace, storage volumes, and lifecycle, enabling them to work together as a single application. The pod design allows developers to flexibly combine and manage containers while also providing the necessary isolation and security.

[0043] Sandbox: In Kubernetes, a sandbox typically refers to the isolated execution environment provided for a pod. This environment includes the resources and isolation mechanisms allocated to the pod by the container runtime (such as Docker or containerd). The sandbox ensures that containers within the pod can run securely and independently while still being able to communicate and collaborate with other pods.

[0044] PodSandbox-Controller: The PodSandbox-Controller is an extended Kubernetes controller that monitors the status and resource usage of cluster nodes and uses this information to make resource balancing and scheduling decisions. Unlike traditional Kubernetes controllers, the PodSandbox-Controller focuses more on resource management and optimization at the pod sandbox level. It may dynamically adjust the pod sandbox configuration based on factors such as node load, available resources, and network latency to improve the overall performance and stability of the cluster.

[0045] PodSandbox-Agent: The PodSandbox-Agent is an agent service that runs on every resource node in the cluster. It collects real-time status information about the resource nodes (such as CPU usage, memory usage, and network traffic) and reports this information to the PodSandbox-Controller. The PodSandbox-Agent also executes commands issued by the Controller, such as creating, deleting, or adjusting the Pod's sandbox configuration. This distributed design enables the PodSandbox-Agent to quickly respond to changes in the cluster and ensure that the Pod's sandbox environment aligns with the overall cluster policy.

[0046] In an exemplary embodiment, Figure 1As shown, a schematic diagram of the application environment of a container group creation method is provided, including a scheduler and resource nodes in a cluster; wherein the scheduler includes a PodSandbox-Controller, and each resource node includes a local PodSandbox-Agent.

[0047] In an exemplary embodiment, Figure 2 As shown, a container group creation method is provided, which is applied to Figure 1 The following example illustrates the PodSandbox-Controller of the scheduler in

[15] :

[0048] S201: When a container group Pod creation request is obtained, a target sandbox container environment is selected from the existing container sandbox environments of each resource node in the cluster according to the Pod creation request.

[0049] It is understandable that when a Kubernetes cluster receives a new container group Pod creation request, the Pod creation request is first processed by the cluster's scheduler, and the scheduler decides to schedule the Pod to a resource node in the cluster.

[0050] Among them, a certain number of container sandbox environments are pre-established on each resource node of the cluster, that is, the existing container sandbox environment of each resource node in the cluster.

[0051] Among them, the existing container sandbox environment of each resource node is pre-established based on the sandbox environment creation request sent by the scheduler to the resource node. The specific construction method is: the existing sandbox environment on each resource node is created through the collaborative work of the PodSandbox-Controller component and the PodSandbox-Agent component.

[0052] Among them, the PodSandbox-Agent component is responsible for collecting and reporting the available resources of the resource node where it is located, and creating an existing container sandbox environment according to the sandbox environment creation request initiated by the PodSandbox-Controllerf, so that the existing container sandbox environment is cached on each resource node Node, waiting for the Pod startup request.

[0053] Specifically, when a Pod creation request arrives at the scheduled resource node, the Node's kubelet initiates a RunPodSandbox call, requesting a sandbox cache from the local PodSandbox-Agent that matches the Pod's resource requirements. Based on the kubelet's request, the PodSandbox-Agent allocates a suitable existing container sandbox environment from the cache to the Pod. This selected sandbox is the target sandbox container environment, which already includes the basic network, storage, and other resources required for the Pod to run.

[0054] S202: Create a target Pod corresponding to the Pod creation request in the target sandbox container environment.

[0055] Optionally, after selecting the target sandbox container environment, the kubelet component in the resource node where the target sandbox container environment is located will create each container defined in the Pod in this sandbox, and use the container runtime (such as Docker, containerd, etc.) to create and manage the containers according to the provided configuration.

[0056] After the container is successfully created, the Pod starts running. The kubelet component monitors the status of the Pod and performs health checks and automatic recovery according to predefined policies.

[0057] In the above container group creation method, this application pre-creates an existing sandbox container environment in each resource node, and completes the time-consuming preparation work of creating a sandbox container environment before starting the Pod in advance, thereby simplifying the Pod creation process and reducing the Pod cold start time.

[0058] In an exemplary embodiment, Figure 3 As shown, based on the Pod creation request, the target sandbox container environment is selected from the existing container sandbox environments of each resource node in the cluster, including:

[0059] S301 , matching the resource configuration requirements carried in the Pod creation request with the resource amounts of the existing container sandbox environments of each resource node in the cluster to obtain at least one candidate container sandbox environment that meets the resource configuration requirements.

[0060] It is understandable that when a Pod creation request arrives at the Kubernetes cluster, the request will include the resource configuration requirements required by the Pod, such as the amount of CPU, memory, storage and other resources.

[0061] Accordingly, a certain number of pre-existing container sandbox environments are pre-established on each resource node in the cluster. These pre-existing container sandbox environments have their corresponding resources allocated upon creation. The PodSandbox-Agent component regularly collects and reports the available resources of the node, including remaining CPU, remaining memory, and remaining storage space, and updates this information to the node's node.annotations annotation.

[0062] When a Pod creation request arrives, the PodSandbox-Controller or each kubelet component searches for existing container sandbox environments on each resource node in the cluster based on the Pod's resource configuration requirements. By comparing the Pod's required resources with the resources allocated to each sandbox, it can select sandboxes that meet the Pod's resource configuration requirements, namely candidate container sandbox environments.

[0063] S302 : Select a target sandbox container environment from each candidate container sandbox environment according to the environment attribute information of each candidate container sandbox environment.

[0064] The environmental attribute information includes at least health status, creation time and resource utilization.

[0065] It is understandable that in addition to the amount of resources, each candidate container sandbox environment also has a series of environmental attribute information, such as health status, creation time, and resource utilization. The environmental attribute information reflects the stability and performance of the Sandbox.

[0066] Specifically, after selecting candidate sandboxes that meet resource allocation requirements, the next step is to select the optimal sandbox as the target sandbox container environment based on environmental attribute information. Prioritize sandboxes with good health to ensure stable pod operation. Secondly, consider sandboxes that were created recently to reduce potential issues caused by long periods of inactivity. Finally, selecting sandboxes with moderate resource utilization ensures efficient resource utilization and avoids excessive or idle resources. Taking all these factors into consideration, the optimal sandbox is selected from the candidate sandboxes as the target sandbox container environment.

[0067] In this embodiment, resource matching and environment attribute information selection ensure that the Pod can quickly start and run in the optimal target sandbox container environment, which not only improves the startup speed of the Pod, but also optimizes the resource utilization of the cluster and the overall performance of the system.

[0068] In an exemplary embodiment, the existing container sandbox environment of any resource node is created in the resource node according to the sandbox environment creation request sent by the scheduler.

[0069] The sandbox environment creation request includes at least one sandbox environment type and the number of sandbox environments corresponding to each sandbox environment type; the sandbox environments corresponding to each sandbox environment type occupy different storage resources and computing resources.

[0070] As you can understand, the scheduler generates a sandbox environment creation request based on the cluster's resource availability and the pod's resource requirements. This sandbox environment creation request includes at least one sandbox environment type and the number of sandbox environments corresponding to each sandbox environment type. These sandbox environment types utilize different storage and computing resources to meet the resource allocation requirements of different pods.

[0071] For example, a sandbox environment creation request may carry CRDs, which are used to define sandboxes of different specifications, including required core system resources such as memory and CPU resources.

[0072] Furthermore, after generating the sandbox environment creation request for each resource node Node, the scheduler sends the sandbox environment creation request for the resource node to the proxy component in the resource node through the control component.

[0073] The control component is the PodSandbox-Controller mentioned above. The PodSandbox-Controller is responsible for receiving sandbox environment creation requests generated by the scheduler. The PodSandbox-Controller determines which resource node to create the sandbox environment on based on the current state of the cluster and the available resources of the resource nodes.

[0074] The agent component in the resource node is the PodSandbox-Agent in the resource node. After receiving the sandbox environment creation request sent by the PodSandbox-Controller, the PodSandbox-Agent will parse the sandbox environment type and quantity information in the request.

[0075] Specifically, based on the requested sandbox environment type and quantity, the PodSandbox-Agent calls the Container Runtime Interface (CRI) to interact with the underlying container runtime and begin creating the sandbox environments. During this process, the PodSandbox-Agent ensures that sufficient storage and compute resources are allocated to each sandbox environment to meet the Pod's operational requirements. Successfully created sandbox environments are cached on the resource node, awaiting Pod start requests.

[0076] In addition, after the sandbox environment is created, PodSandbox-Agent will update the status of these sandbox environments (for example, the ready state) to the node.annotations annotation of the node so that components such as PodSandbox-Controller and kubelet components can obtain the latest status of the sandbox environment in real time.

[0077] In this embodiment, the control component (PodSandbox-Controller) and the agent component (PodSandbox-Agent) work together to create a sandbox environment for resource nodes and quickly start Pods in the Kubernetes cluster.

[0078] In an exemplary embodiment, Figure 4 As shown, the sandbox environment creation request for each resource node is generated in the following way:

[0079] S401: Obtain the node resource upper limit and node load status of each resource node.

[0080] In a Kubernetes cluster, the PodSandbox-Agent in each resource node is responsible for regularly collecting resource usage information on that node, including core system resources such as remaining CPU, remaining memory, and remaining storage space, as well as current load indicators (such as CPU utilization and memory utilization). The PodSandbox-Agent then reports the collected node resource limit (i.e., the node's total resources) and current load to the PodSandbox-Controller component via an API or other communication methods.

[0081] The PodSandbox-Controller aggregates this information to form a cluster-level resource view. The PodSandbox-Controller stores the received node resource information in an appropriate storage system (such as an in-memory database or a persistent database) for subsequent calculations and decision-making. Furthermore, this information is continuously updated over time to reflect dynamic changes in cluster resources.

[0082] S402 : According to the node resource upper limit and node load of each resource node and with the set planning conditions as constraints, determine the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type.

[0083] The planning conditions include at least load balancing conditions between resource nodes and security isolation conditions between different container sandbox environments in the same resource node.

[0084] Specifically, in the PodSandbox-Controller, a series of planning conditions are preset as constraints for creating the sandbox environment. For example, these planning conditions include at least load balancing conditions between resource nodes and security isolation conditions between different container sandbox environments on the same resource node.

[0085] As you can understand, the load balancing requirement is designed to ensure that resources in the cluster are evenly distributed, preventing some nodes from being overloaded while others are idle. The security isolation requirement requires that different sandbox environments on the same node be isolated from each other to prevent resource leaks and security issues.

[0086] Specifically, the PodSandbox-Controller executes a linear programming algorithm based on collected node resource information and pre-set planning conditions. The goal of the linear programming algorithm is to determine the type and number of sandbox environments that should be created on each resource node to maximize resource utilization and ensure system stability while meeting application requirements.

[0087] S403 : Generate a sandbox environment establishment request for each resource node according to the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type.

[0088] Based on the results of the linear programming algorithm, the PodSandbox-Controller generates sandbox environment creation requests for each resource node. These requests include the type of sandbox environment to be created on each node (such as sandboxes of different specifications) and the corresponding quantity.

[0089] For example, the execution process of the linear programming algorithm is as follows

[0090] Set up a Kubernetes cluster with three resource nodes (Node1, Node2, and Node3). Each node has a certain amount of CPU and memory resources available. Two types of pods need to be deployed, each requiring a different sandbox environment: (Type 1) Type A Pod: Requires a medium-sized sandbox, each occupying 10 CPU cores and 50 GB of memory. (Type 2) Type B Pod: Requires a high-sized sandbox, each occupying 20 CPU cores and 100 GB of memory.

[0091] The preset planning conditions are: (1) maximizing resource utilization, that is, filling the available CPU and memory resources on each node as much as possible; (2) ensuring system stability, that is, avoiding excessive resource utilization of any node leading to performance degradation or node downtime.

[0092] x1A: Number of sandboxes for TypeA Pods created on Node1.

[0093] x1B: Number of Type B Pod sandboxes created on Node 1.

[0094] x2A: Specifies the number of TypeA Pod sandboxes created on Node2.

[0095] x2B: Number of Type B Pod sandboxes created on Node2.

[0096] x3A: Specifies the number of TypeA Pod sandboxes created on Node 3.

[0097] x3B: Number of Type B Pod sandboxes created on Node 3.

[0098] The objective function is to maximize resource utilization, which can be converted into maximizing CPU and memory usage.

[0099] The constraint is that the CPU resource usage of each node does not exceed its total amount:

[0100] 10x1A+20x1B≤CPUNode1

[0101] 10x2A+20x2B≤CPUNode2

[0102] 10x3A+20x3B≤CPUNode3

[0103] Each node's memory resource usage does not exceed its total amount:

[0104] 50x1A+100x1B≤MemoryNode1

[0105] 50x2A+100x2B≤MemoryNode2

[0106] 50x3A+100x3B≤MemoryNode3

[0107] The decision variables are non-negative integers: x1A, x1B, x2A, x2B, x3A, x3B ≥ 0 and are integers.

[0108] In actual applications, the PodSandbox-Controller collects resource information (CPU_{NodeX} and Memory_{NodeX}) of each node and uses a linear programming solver (such as the Simplex algorithm or interior point method) to solve the linear programming problem based on preset planning conditions (such as the aforementioned CPU and memory usage constraints) and pod requirements (such as the sandbox specifications of TypeA and TypeB pods).

[0109] The solution process finds a set of decision variable values ​​(i.e., the number of sandboxes of each type on each node) that satisfies all constraints and optimizes the objective function (in this case, resource utilization). For example, the solution might indicate that three TypeA Pod sandboxes and one TypeB Pod sandbox need to be created on Node1, two TypeA Pod sandboxes need to be created on Node2, and no sandboxes need to be created on Node3. The PodSandbox-Agent receives these requests and executes the corresponding sandbox creation operations.

[0110] In summary, by setting planning conditions and executing the linear programming algorithm, we have implemented a sandbox environment creation and caching mechanism based on resource balancing and planning conditions in the Kubernetes cluster.

[0111] Furthermore, the above S301 to S303 describe how to determine the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type based on the real-time status of the cluster, and generate a sandbox environment establishment request for each resource node. In another possible implementation, after determining the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type, when a resource node is newly added, crashes, or exits the cluster, the following situations are also included:

[0112] (Case 1) A new resource node joins the cluster:

[0113] The PodSandbox-Controller continuously monitors the status of the Kubernetes cluster, including the addition and removal of nodes. When a new node is detected joining the cluster, the Controller immediately starts the process of creating a Sandbox cache for the new node.

[0114] The PodSandbox-Controller proactively sends a request to the PodSandbox-Agent of the newly added node to obtain information such as available resources. Upon receiving the request, the PodSandbox-Agent of the new node collects core system resource and load metrics, such as remaining CPU, remaining memory, and remaining storage space, based on mechanisms such as Linux system calls. The Agent compiles this resource information and returns it to the PodSandbox-Controller via a response message.

[0115] After receiving the resource information for a new node, the PodSandbox-Controller independently executes a linear programming algorithm for the new node, based on constraints such as the desired ratio of the previously created sandbox caches and the new node's resource information. The goal of the linear programming algorithm is to calculate the optimal number of various sandbox caches to create for the new node, based on the new node's resource capacity and constraints such as the pre-set sandbox specifications and desired ratio. This optimal number should ensure that the proportion of each sandbox in the cluster remains as constant as possible after the node joins, thereby maintaining system stability and resource utilization. The algorithm takes into account various factors, such as the new node's resource capacity, the sandbox specifications, and the number and ratio of existing sandboxes in the cluster, to arrive at the optimal solution through iterative calculation.

[0116] The PodSandbox-Controller determines the type and number of sandbox caches to create for the new node based on the results of the linear programming algorithm. The Controller sends these creation instructions to the PodSandbox-Agent of the new node via a message.

[0117] After receiving the creation instruction, the PodSandbox-Agent of the new node will actually execute the Sandbox creation operation according to the Sandbox specifications and quantity specified in the instruction. The Agent will call mechanisms such as the Container Runtime Interface (CRI) to interact with the underlying specific container runtime to complete the Sandbox creation process. The successfully created Sandbox will be cached locally on the new node, awaiting the Pod start request. These Sandboxes are marked as ready and can be quickly assigned to the newly started Pod by the kubelet. When the Sandbox cache of the new node is created, the PodSandbox-Agent will send a message to the PodSandbox-Controller to notify it of the creation result. After receiving the notification, the PodSandbox-Controller will update the cluster status information and include the Sandbox cache status of the new node in unified management.

[0118] (Case 2) A resource node goes down or exits the cluster:

[0119] The PodSandbox-Controller monitors the status of each node in the cluster in real time through methods such as HTTP Watch. When a node is detected to be down or has exited the cluster, the Controller immediately triggers an emergency response mechanism. The Controller first records the downed node's information and marks all sandbox caches on that node as unavailable.

[0120] The Controller traverses the remaining nodes and counts the number of sandboxes of various specifications currently available by reading the available resources and sandbox cache information reported by the PodSandbox-Agent on each node. Based on the system's expected sandbox ratio, the Controller calculates the gap between the current ratio and the expected ratio, and identifies which sandbox caches exceed the demand and which are insufficient. For sandbox caches that exceed the demand, the Controller marks them as "cache unavailable" and removes them from the scheduling list to ensure that these sandboxes are no longer allocated to new Pod instances. The Controller sends instructions to the PodSandbox-Agents of the relevant nodes, requiring them to release these specified sandbox caches. After receiving the instructions, the Agent performs asynchronous deletion operations, gradually removing these redundant sandbox caches and releasing the corresponding resources. During the deletion process, the Agent continuously monitors resource usage and feeds back the updated resource availability to the Controller in real time.

[0121] Based on the available resources of the remaining nodes and the previously calculated insufficient Sandbox cache, the Controller calls a linear programming algorithm to recalculate the number of various Sandbox caches that need to be replenished. The algorithm comprehensively considers the resource conditions of the remaining nodes, the expected proportion of the system, and possible future Pod requirements to generate a new Sandbox cache planning result. Based on the planning results, the Controller sends a creation request to the PodSandbox-Agent of each node, requesting them to create a new Sandbox cache according to the planning results. After receiving the request, the Agent actually executes the Sandbox creation operation according to the specified specifications and quantity, and adds the newly created Sandbox to the local cache pool.

[0122] Throughout the entire process, the Controller continuously monitors the cluster status and resource usage of the remaining nodes. If a new node joins or an existing node leaves, the Controller will re-execute the above process to ensure that the overall sandbox cache ratio of the system remains at the expected level.

[0123] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0124] Based on the same inventive concept, embodiments of the present application also provide a container group creation device for implementing the aforementioned container group creation method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of one or more container group creation device embodiments provided below can be found in the above-described limitations of the container group creation method and are not further elaborated here.

[0125] In an exemplary embodiment, Figure 5 As shown, a container group creation device is provided, including: a request acquisition module 11 and a container group creation module 12, wherein:

[0126] The request acquisition module 11 is used to select a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster according to the Pod creation request when a container group Pod creation request is obtained; the existing container sandbox environment of each resource node is pre-established according to the sandbox environment creation request sent by the scheduler to the resource node;

[0127] The container group creation module 12 is used to create a target Pod corresponding to the Pod creation request in the target sandbox container environment.

[0128] In one embodiment, the request acquisition module 11 is further configured to: match the resource configuration requirements carried in the Pod creation request with the resource amounts of the existing container sandbox environments of each resource node in the cluster to obtain at least one candidate container sandbox environment that meets the resource configuration requirements;

[0129] A target sandbox container environment is selected from the candidate container sandbox environments according to the environment attribute information of each candidate container sandbox environment.

[0130] In one embodiment, the environment attribute information includes at least health status, creation time, and resource utilization.

[0131] In one embodiment, an existing container sandbox environment of any resource node is created in the resource node according to a sandbox environment creation request sent by a scheduler; wherein the sandbox environment creation request includes at least one sandbox environment type and the number of sandbox environments corresponding to each sandbox environment type; the storage resources and computing resources occupied by the sandbox environments corresponding to each sandbox environment type are different.

[0132] In one embodiment, the apparatus further includes a request generating module for: obtaining a node resource upper limit and a node load condition of each resource node;

[0133] Based on the node resource limit and node load of each resource node, and subject to the set planning conditions as constraints, determine the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type; the planning conditions at least include the load balancing conditions between each resource node and the security isolation conditions between different container sandbox environments in the same resource node;

[0134] A sandbox environment creation request for each resource node is generated according to the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type.

[0135] In one embodiment, the device further includes a request sending module, which is used to send a sandbox environment creation request of the resource node to the proxy component in the resource node through the control component.

[0136] Each module in the container group creation device described above can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a computer device memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0137] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 6 As shown. The computer device includes a processor, a memory, an input / output interface (I / O) and a communication interface. The processor, memory and input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data of a container group creation method. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a container group creation method is implemented.

[0138] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0139] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0140] When a container group Pod creation request is received, the scheduler selects a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster based on the Pod creation request. The existing container sandbox environment of each resource node is pre-established based on the sandbox environment creation request sent by the scheduler to the resource node.

[0141] In the target sandbox container environment, create the target Pod corresponding to the Pod creation request.

[0142] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0143] When a container group Pod creation request is received, the scheduler selects a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster based on the Pod creation request. The existing container sandbox environment of each resource node is pre-established based on the sandbox environment creation request sent by the scheduler to the resource node.

[0144] In the target sandbox container environment, create the target Pod corresponding to the Pod creation request.

[0145] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0146] When a container group Pod creation request is received, the scheduler selects a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster based on the Pod creation request. The existing container sandbox environment of each resource node is pre-established based on the sandbox environment creation request sent by the scheduler to the resource node.

[0147] In the target sandbox container environment, create the target Pod corresponding to the Pod creation request.

[0148] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), quantum computing-based data processing logic devices, artificial intelligence (AI) processors, and the like.

[0149] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, 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 application.

[0150] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A method for creating a container group, characterized in that: Applied to a scheduler in a cluster, the method comprises: When a container group Pod creation request is obtained, a target sandbox container environment is selected from the existing container sandbox environments of each resource node in the cluster according to the Pod creation request; the existing container sandbox environment of each resource node is pre-established according to the sandbox environment creation request sent by the scheduler to the resource node; In the target sandbox container environment, create a target Pod corresponding to the Pod creation request.

2. The method according to claim 1, characterized in that: The step of selecting a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster according to the Pod creation request includes: Matching the resource configuration requirements carried in the Pod creation request with the resource amounts of the existing container sandbox environments of each resource node in the cluster to obtain at least one candidate container sandbox environment that meets the resource configuration requirements; According to the environment attribute information of each candidate container sandbox environment, a target sandbox container environment is selected from each candidate container sandbox environment.

3. The method according to claim 2, characterized in that The environmental attribute information includes at least health status, creation time and resource utilization.

4. The method according to claim 1, characterized in that The existing container sandbox environment of any resource node is created in the resource node according to the sandbox environment creation request sent by the scheduler; wherein the sandbox environment creation request includes at least one sandbox environment type and the number of sandbox environments corresponding to each sandbox environment type; the storage resources and computing resources occupied by the sandbox environments corresponding to each sandbox environment type are different.

5. The method according to claim 4, characterized in that The sandbox environment creation request for each resource node is generated in the following way: Obtain the node resource upper limit and node load status of each resource node; According to the node resource upper limit and node load of each resource node, the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type are determined with the set planning conditions as constraints; the planning conditions at least include the load balancing conditions between the resource nodes and the security isolation conditions between different container sandbox environments in the same resource node; A sandbox environment creation request for each resource node is generated according to the sandbox environment type corresponding to each resource node and the number of sandbox environments corresponding to each sandbox environment type.

6. The method according to claim 4, characterized in that The method further comprises: A request for creating a sandbox environment of the resource node is sent to the proxy component in the resource node through the control component.

7. A container group creation device, characterized in that: A scheduler configured in a cluster, the device comprising: A request acquisition module, configured to select a target sandbox container environment from the existing container sandbox environments of each resource node in the cluster according to the Pod creation request when a container group Pod creation request is obtained; the existing container sandbox environment of each resource node is pre-established according to the sandbox environment creation request sent by the scheduler to the resource node; The container group creation module is used to create a target Pod corresponding to the Pod creation request in the target sandbox container environment.

8. A computer 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 6 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 6 are implemented.

10. A computer program product, comprising a computer program, 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 6 are implemented.

Images