An elastic container instance creation method, device, equipment and storage medium

Abstract

The present disclosure provides an elastic container instance creation method, device and equipment and storage medium, relates to the technical field of computers, in particular to the technical field of cloud computing, big data and the like. The specific implementation scheme is: creating a container storage unit; based on a scheduling algorithm, the container storage unit is scheduled to a target node; in the container storage unit of the target node, based on the GPU resources of a GPU cluster, an elastic container instance is created; wherein the GPU cluster includes a plurality of GPU cards, and the GPU card includes a GPU chip. The present disclosure can improve the creation efficiency and security of the elastic container instance.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of cloud computing, big data and other technologies. Background Technology

[0002] Elastic Container Instance (ECI) is a service based on container and serverless technologies, primarily used to run containers in cloud environments. With the rapid development of cloud computing technology and microservice architecture, ECI has become a core infrastructure for building cloud-native applications due to its rapid deployment and dynamic resource scaling capabilities. However, current methods of creating ECI present challenges in terms of performance optimization and security isolation. Therefore, how to create ECI efficiently and securely has become a pressing issue that needs to be addressed. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, and storage medium for creating flexible containers.

[0004] According to one aspect of this disclosure, a method for instantiating a resilient container is provided, comprising:

[0005] Create a container storage unit;

[0006] Based on the scheduling algorithm, the container storage unit is scheduled to the target node;

[0007] Within the container storage unit of the target node, elastic container instances are created based on the GPU resources of the GPU cluster; wherein, the GPU cluster includes multiple GPU cards, and each GPU card includes a GPU chip.

[0008] According to another aspect of this disclosure, an apparatus for creating elastic container instances is provided, comprising:

[0009] The first creation module is used to create container storage units;

[0010] The scheduling module is used to schedule the container storage unit to the target node based on the scheduling algorithm;

[0011] The second creation module is used to create elastic container instances in the container storage unit of the target node based on the GPU resources of the GPU cluster; wherein the GPU cluster includes multiple GPU cards, and each GPU card includes a GPU chip.

[0012] According to another aspect of this disclosure, an electronic device is provided, comprising:

[0013] At least one processor; and

[0014] The memory is communicatively connected to the at least one processor; wherein,

[0015] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0016] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0017] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0018] This disclosure enables the creation of elastic container instances based on GPU resources within container storage units by creating container storage units and scheduling them to target nodes. Due to the hardware-level parallel computing capabilities of GPU chips, computationally intensive tasks during the elastic container instance creation phase can be accelerated, improving creation efficiency. Furthermore, the parallel processing characteristics of GPU chips allow the simultaneous handling of multiple elastic container instance creation needs, reducing resource fragmentation and improving resource utilization.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0020] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0021] Figure 1 This is a flowchart illustrating the implementation of a method for creating a flexible container instance according to an embodiment of the present disclosure.

[0022] Figure 2 This is a schematic diagram illustrating the process of creating and running a flexible container instance according to an embodiment of the present disclosure;

[0023] Figure 3 This is a schematic diagram of a system for creating and running a flexible container instance according to an embodiment of the present disclosure;

[0024] Figure 4 This is a schematic diagram of the structure of a flexible container instance creation apparatus 400 according to an embodiment of the present disclosure;

[0025] Figure 5 This is a schematic diagram of the structure of a flexible container instance creation apparatus 500 according to an embodiment of the present disclosure;

[0026] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

[0027] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0028] The term "and / or" in this disclosure indicates that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The term "at least one" in this document means any combination of at least two of a plurality of options, such as including at least one of A, B, and C, which can mean including any one or more elements selected from the set of A, B, and C. The terms "first" and "second" in this document refer to and distinguish multiple similar technical terms, and do not imply a specific order or a limitation to only two. For example, "first feature" and "second feature" refer to two types / two features; the first feature can be one or more, and the second feature can also be one or more.

[0029] Before introducing the technical solutions of the embodiments of this disclosure, the technical terms that may be used in this disclosure will be further explained:

[0030] Kubernetes (or K8S for short): An open-source platform for automating the deployment, scaling, and management of containerized applications.

[0031] Containers: A lightweight virtualization technology used to encapsulate applications and their dependencies together for portability and operation in different computing environments.

[0032] Quick Emulator (QEMU): An open-source hardware virtualization software that allows one operating system to run within another.

[0033] Open Container Initiative (OCI): A universal standard for container runtimes and image formats that ensures that different container tools (such as Docker, Podman, containerd, etc.) can interoperate.

[0034] Runtime: A type of software component that manages containers, providing an environment for isolating and managing applications, allowing applications to run in an independent environment.

[0035] Kata Container: A container solution (or virtualized container) based on virtualization technology. It provides enhanced security isolation through a lightweight virtualization mechanism, while also taking into account the fast startup speed and low resource consumption of containers.

[0036] Container storage unit (or simply Pod): The smallest deployable unit in Kubernetes, which can be used to store one or more closely related containers.

[0037] In recent years, cloud computing technology and microservice architecture have developed rapidly, and elastic container instance solutions based on standard container runtimes (such as runc) have been widely adopted. This type of solution achieves lightweight isolation through Linux kernel namespaces and control group technology, and can encapsulate applications and their dependent environments at the process level on a single host machine, thereby supporting rapid deployment, dynamic scaling, and multi-tenant resource management.

[0038] However, as enterprises increasingly demand higher security from elastic container instances, traditional container isolation mechanisms are gradually revealing their security shortcomings: On the one hand, the fact that containers share the kernel with the host makes them vulnerable to kernel vulnerabilities, allowing attackers to penetrate the host or other tenant containers through the container; on the other hand, namespaces only provide logical isolation and cannot protect against data leakage risks caused by privilege escalation or malicious configuration. Furthermore, in multi-tenant deployment scenarios, containers lacking hardware-level isolation may experience performance interference and privacy risks due to resource contention.

[0039] In related technologies, sandboxes are introduced as an additional isolation layer to attempt to build a security barrier between container applications and the host kernel, thereby reducing the attack surface. However, because its operating mechanism still relies on interaction with the host operating system, this architecture has limitations in protecting against certain types of attacks. Therefore, while this technology improves security, it still depends on the robustness of the host kernel and cannot completely eliminate the risk of kernel-level attacks.

[0040] To address the aforementioned issues, this disclosure proposes a method for creating elastic container instances. This method leverages virtualized containers and utilizes GPU resources within a Graphics Processing Unit (GPU) cluster to create elastic container instances, thereby improving creation efficiency and security.

[0041] Figure 1 This is a flowchart illustrating the implementation of a method for creating a flexible container instance according to an embodiment of the present disclosure, including:

[0042] S110, Create a container storage unit;

[0043] S120. Based on the scheduling algorithm, schedule the container storage unit to the target node;

[0044] S130. In the container storage unit of the target node, an elastic container instance is created based on the GPU resources of the GPU cluster; wherein, the GPU cluster includes multiple GPU cards, and each GPU card includes a GPU chip.

[0045] In one example, a user can create a request based on a container storage unit (or Pod), writing a definition file (typically in JavaScript Object Notation (JSON) format) for that container storage unit. This definition file is then sent to the Kubernetes Application Programming Interface Server (API Server) via Hypertext Transfer Protocol (HTTP). The Kubernetes API Server receives and verifies the container storage unit creation request, and then creates the container storage unit. Here, the Kubernetes API Server is one of the core components of the Kubernetes architecture, providing a unified API interface for all components in the Kubernetes architecture, as well as an interface for interaction with external users.

[0046] In another example, users can create container storage units by running container storage unit creation commands (such as `kubectl apply -f pod-definition.yaml`) using Kubernetes command-line tools (such as `kubectl`).

[0047] In this embodiment of the disclosure, after a container storage unit is created, the K8S API Server can mark the container storage unit as Pending and notify the scheduler so that the scheduler can schedule the container storage unit to the target node based on the scheduling algorithm. Further, after scheduling the container storage unit is completed, it can be marked as Running.

[0048] In one example, the scheduling algorithm may include two phases:

[0049] (1) Filtering stage: Select at least one candidate node that meets the requirements by using preset conditions.

[0050] In this phase, in one example, nodes can be filtered to meet the requirements by checking whether the resources such as memory, storage space, and GPU in each node meet the requirements and limits of the container storage unit. For example, if the container storage unit requires 2GB of video memory and 3GB of storage space, then the node is filtered out if the remaining resources in the node do not meet the requirements of the container storage unit.

[0051] (2) Determination stage: Scoring each candidate node to determine the target node.

[0052] In this stage, in one example, the score of a candidate node is determined by analyzing the scores of various resources in the candidate node and combining the weights corresponding to each resource.

[0053] Specifically, a scheduler can be used to score various resources in candidate nodes based on scoring rules. These scoring rules can be related to the utilization rate of each resource within the candidate nodes, determining the score for that resource based on its utilization rate. For example, if a candidate node's memory utilization rate is 30% and its remaining utilization rate is 70%, then the score for its memory resource could be 70. Similarly, if a candidate node's network bandwidth utilization rate is 60%, then the score for its network bandwidth resource could be 60.

[0054] In this example, the weights of various resources can be predefined. Generally, computationally intensive resources (such as memory and video memory) can be set to higher weights, while non-critical or general-purpose resources (such as disk I / O and network bandwidth) can be set to lower weights.

[0055] Furthermore, based on the scores of various resources in the candidate nodes and the corresponding weights of each resource, a score can be obtained for each candidate node. Based on the scores of each candidate node, the target node can be determined; in one example, the candidate node with the highest score can be identified as the target node.

[0056] In this embodiment of the disclosure, after the container storage unit is scheduled to the target node, an elastic container instance can be created in the container storage unit of the target node based on the GPU resources of the GPU cluster. The GPU cluster may include multiple GPU cards.

[0057] Here, a GPU card is a hardware device obtained by integrating multiple core components, including a GPU chip, an audio processing unit, a heat dissipation module, etc. The components work together to achieve efficient parallel processing capabilities.

[0058] In this embodiment, the GPU chip is a chip specifically designed for parallel computing, which integrates a large number of programmable computing component modules (such as computing units, CUDA Cores, Tensor Cores, etc.). Through the collaborative work of these cores, high-throughput numerical computation and data processing are achieved. GPU resources may include the computing power, video memory, and other resources of the GPU chip in the GPU card that can be used to create elastic container instances.

[0059] Using the above method, by creating container storage units and scheduling them to target nodes, elastic container instances can be created within container storage units based on GPU resources. Compared to elastic container instance methods based on CPU resources, the hardware-level parallel computing capabilities of GPU chips can accelerate the processing of computationally intensive tasks during the elastic container instance creation phase, improving creation efficiency. Furthermore, the parallel processing characteristics of GPU chips allow the simultaneous handling of the creation needs of multiple elastic container instances, reducing resource fragmentation and improving resource utilization.

[0060] Figure 2 This is a schematic diagram illustrating the process of creating and running a flexible container instance according to an embodiment of the present disclosure.

[0061] like Figure 2 As shown, the process of creating and running an elastic container instance may include:

[0062] S201. Create a container storage unit and schedule it to the target node.

[0063] It should be noted that, in the embodiments of this disclosure, the methods and examples for creating and scheduling container storage units can be found in the descriptions of S110 and S120 above, and will not be repeated here.

[0064] S202, Enable the first virtualization container.

[0065] S203. Create an elastic container instance through the first virtualization container.

[0066] In some implementations, elastic container instances are created in the container storage unit of the target node based on the GPU resources of the GPU cluster, including:

[0067] Enable the first virtualized container based on the container management engine;

[0068] The first virtualized container invokes the GPU resources of the GPU cluster to create an elastic container instance in the container storage unit of the target node.

[0069] In this embodiment of the disclosure, the container management engine in the target node can be used to parse the configuration information of the container storage unit to determine the virtualization runtime (such as the Kata runtime). Here, the container management engine can be Containerd.

[0070] Furthermore, the container management engine invokes the virtualization runtime, sending the creation request for the first virtualized container to the virtualization runtime. The virtualization runtime then uses QEMU to enable the first virtualized container.

[0071] In one example, GPU resources can be requested from the GPU cluster through a GPU resource scheduler (such as a DevicePlugin) within the first virtualization container. The GPU resource scheduler dynamically allocates GPU resources to the first virtualization container based on GPU resource availability (such as compute power usage or video memory usage). Ultimately, the first virtualization container can use the allocated GPU resources to create an elastic container instance in the container storage unit of the target node.

[0072] Using the above method, the first virtualization container, based on the container management engine, utilizes GPU resources to create elastic container instances. Because the first virtualization container provides each elastic container instance with an independent kernel-level isolation environment through hardware virtualization technology, container escape and resource contention are reduced. Furthermore, the lightweight design of the first virtualization container reduces the initialization time of elastic container instances, improving creation efficiency.

[0073] In addition, a key point in this step is to adapt the first virtualization container to the GPU cluster so that the first virtualization container can interact with the GPU cluster. The specific implementation method will be introduced in detail later.

[0074] S204. Based on the elastic container instance, obtain the corresponding image configuration data.

[0075] S205. Run an elastic container instance based on image configuration data.

[0076] In this embodiment of the disclosure, after the elastic container is created, the container management engine can invoke relevant service components to initiate a query request to the image management system. Here, the query request may include the unique identifier information of the elastic container instance, and the image management system may include image files and corresponding image configuration data.

[0077] After receiving a query request, the image management system can use the unique identifier of the elastic container instance to traverse the records related to each image configuration data in the image management system and filter out the corresponding image configuration data from multiple image configuration data. Here, image configuration data may include the image name, version number, storage location (such as the specific address and path in the image management system), startup parameters (such as environment variables, resource limits, etc.), etc.

[0078] Furthermore, after determining the image configuration data, the corresponding image file can be pulled from the image management system based on the storage location information in the image configuration data. In one example, an elastic container instance can be run using overlay mount technology. Specifically, an overlay file system can be created in the host machine's file system. This overlay file system includes a lower directory, an upper directory, and a merged directory. Here, lowerdir points to the directory where the image file is located and contains all the files and directory structures in the image; upperdir is a writable layer created by the elastic container instance, and any modifications made to the file system by the elastic container instance during operation will be recorded in this directory; mergedir is a merged view of lowerdir and upperdir, integrating the contents of lowerdir and upperdir, allowing programs in the elastic container instance to directly access the required files and directories by accessing mergedir.

[0079] Furthermore, the image file can be mounted into the lowerdir, making all files and directories within the image file the base layer of the overlay file system. Then, using overlay mount technology, the upperdir of the elastic container instance and the lowerdir containing the image file are merged. After the merge, the elastic container instance has a complete, readable and writable file system environment, enabling it to run.

[0080] By using the above method to obtain the corresponding image configuration data through the elastic container instance, the obtained image configuration data can be closely related to that elastic container instance, thereby improving the accuracy of determining the image file. Furthermore, with an image file that is more closely related to the elastic container instance, the operating efficiency of the elastic container instance can be improved.

[0081] In some implementations, the first virtualization container includes a modified Kata container.

[0082] As mentioned earlier, a key aspect of step S203 is enabling the interaction between the first virtualized container and the CPU cluster. Since Kata containers are primarily designed to interact with the Central Processing Unit (CPU) and utilize CPU resources to create elastic container instances, this reduces the efficiency of elastic container instances. Therefore, to achieve step S203, the improved Kata container (i.e., the first virtualized container) needs to interact with the GPU cluster to leverage GPU resources and create elastic container instances, thereby improving creation efficiency.

[0083] Since the commonly used Kata containers are primarily designed for interaction with the CPU, direct interaction with GPU clusters can lead to compatibility or functional defects, hindering their access to GPU resources. To address this issue, this disclosure provides targeted improvements to the source code of commonly used Kata containers, resulting in a first virtualized container. This improved Kata container (the first virtualized container) can then correctly interact with the GPU cluster and access GPU resources, fulfilling the requirements for creating elastic container instances.

[0084] Using the above method, the improved Kata container (i.e., the first virtualization container) can be used for the subsequent elastic container creation process. Since the Kata container has advantages such as strong isolation and low-latency startup, the first virtualization container also has these advantages, which can improve the security of elastic container instance creation, reduce the probability of container escape attacks, and reduce security risks.

[0085] Regarding S203 above, in order to adapt the first virtualization container to the GPU cluster, the following targeted improvements can be made based on the Kata container's source code. Here, the improved Kata container's source code can be considered the source code of the first virtualization container; in other words, the improved Kata container can be considered the first virtualization container.

[0086] In some implementations, the source code of the first virtualization container includes logic for allocating the data bus; wherein,

[0087] This allocation logic is used to allocate a data bus to the GPU chip in the GPU card.

[0088] In this embodiment of the disclosure, the data bus can be a channel for data transmission between various components (such as GPU cards, memory, etc.) in a cloud computing system, that is, to realize data transmission between different components using a common communication protocol and data encoding standard. Generally, the data bus can be a Peripheral Component Interconnect (PCI) bus.

[0089] Currently in the cloud computing field, each GPU card belongs to an Input-Output Memory Management Unit Group (IOMMU Group). Here, the IOMMU Group is a mechanism for managing the memory mapping and access permissions of input / output devices.

[0090] The IOMMU Group includes two devices: the GPU chip of the GPU card and the audio processing unit. During virtualization, all devices in the IOMMU Group can be added to the first virtualization container by dynamically inserting or removing hardware (such as hot-plugging). However, the number of PCI buses within the first virtualization container is limited, typically only eight.

[0091] In one example, to implement the method disclosed herein, multiple GPU cards, such as eight GPU cards, can typically be used simultaneously. Each GPU card corresponds to an IOMMU Group with two devices, requiring two PCI buses. In this embodiment of the disclosure, since the audio processing unit is not used during the creation of the elastic container instance based on the first virtualization container, the data bus allocation logic can be determined in the source code of the first virtualization container according to the resource requirement characteristics of the elastic container instance. That is, if a GPU chip is detected, a data bus (or PCI bus) is allocated to the GPU chip; if an audio processing unit is detected, the device is skipped, and no data bus (or PCI bus) is allocated.

[0092] It should be noted that the detection methods for the GPU chip and audio processing unit in the embodiments of this disclosure may include, but are not limited to, detection methods based on hardware identifiers, detection methods based on runtime states, etc., and the method disclosed herein does not impose specific limitations on these methods.

[0093] In this way, the data bus allocation logic is pre-configured in the source code of the first virtualization container. This allocation logic allocates the data bus to the GPU chip according to the creation requirements of the elastic container instance. This avoids allocating the bus to devices that do not participate in the creation of elastic container instances, thereby improving the utilization of GPU resources and the creation efficiency of elastic containers.

[0094] In some implementations, the source code of the first virtualization container includes an initialization timeout threshold for the GPU cards, which satisfies the loading requirements of multiple GPU cards.

[0095] In this embodiment of the disclosure, the source code of the Kata container sets a default initialization timeout threshold for each GPU card. However, in application scenarios involving multiple GPU cards (e.g., 8 GPU cards), the time required for hardware initialization, driver loading, or resource scheduling processes is generally longer than the default initialization timeout threshold, causing GPU card loading to fail due to timeout.

[0096] This disclosed method, through log analysis and performance monitoring, confirms that the cause of the problem is that the initialization timeout threshold is not adapted to high-density multi-GPU application scenarios. Therefore, based on the Kata container source code, the initialization timeout threshold can be extended so that the initialization timeout threshold in the first virtualization container's source code can meet the initialization, driver loading, and other loading requirements of multiple GPU cards. Furthermore, for GPU clusters with different numbers of GPU cards, multi-level timeout policies can be set to reduce resource waste and lower response latency.

[0097] By adopting the above method, based on the initialization timeout threshold in the source code of the first virtualization container, the complex requirements of multi-GPU card loading scenarios can be met, reducing the problem of loading failure caused by GPU card initialization delay, thereby improving the success rate of loading or mapping the GPU cluster to the first virtualization container.

[0098] In some implementations, a correspondence exists between the host machine's non-consistent memory access architecture and the individual GPU cards in the GPU cluster; wherein,

[0099] The host machine includes the physical computer running the first virtualization container;

[0100] This mapping is used to configure the container management engine.

[0101] In this embodiment of the disclosure, there is a communication performance issue between GPU cards when the first virtualization container interacts with the GPU cluster. Here, the communication performance between GPU cards refers to the data transfer efficiency and communication latency between different GPU cards in a multi-GPU cluster. Generally, the communication transmission speed between GPU cards is slow, typically only 2GB / s.

[0102] To address this issue, the method disclosed herein utilizes a virtualization runtime (such as the Kata runtime) to collect the mapping relationship (e.g., memory bandwidth affinity) between the host machine's Non-Uniform Memory Access (NUMA) architecture and each GPU card. Furthermore, based on this mapping relationship and the resource requests of the first virtualization container, multiple GPU cards with optimal performance (e.g., lowest communication latency, optimal bandwidth) can be preferentially selected for the first virtualization container to execute the GPU resource requests.

[0103] Based on this approach, the mapping relationship can be configured in the container management engine, enabling the first virtualized container to determine the multiple GPU cards corresponding to it after it is enabled, thereby improving the GPU resource allocation process.

[0104] In this way, after the first virtualization container is enabled based on the container management engine, the GPU resource request task in the first virtualization container can directly access the host machine's NUMA. Based on the optimal topology between the GPU card and NUMA, multiple GPU cards that provide GPU resources are determined, thereby improving the efficiency of GPU resource access and data transfer efficiency between multiple GPU cards.

[0105] In some implementations, the source code of the first virtualization container includes a disk space allocation tool for allocating storage space to elastic container instances.

[0106] In this embodiment, a disk space allocation tool (such as xfs_quota) can be pre-configured in the source code of the first virtualization container to limit the storage space of the elastic container instance. Specifically, the disk space allocation tool has the capability to set storage space quotas, and can allocate specific storage space limits for individual users, groups, or projects. Furthermore, the disk space allocation tool can monitor the storage space usage in the elastic container instance in real time and promptly detect abnormal usage. In addition, the disk space allocation tool supports flexible storage space quota adjustments, and can respond to changes in the storage space requirements of the elastic container instance by adjusting the storage space quota accordingly.

[0107] By employing the above method, storage space can be allocated according to the data volume of each elastic container instance. This reduces the likelihood of insufficient available storage space for the current elastic container instance due to excessive data volume in other elastic containers. Furthermore, since each elastic container instance has independent storage space, the security of the elastic container instance during subsequent operation is improved.

[0108] In some implementations, the source code of the first virtualization container includes bus address allocation logic;

[0109] Before creating an elastic container instance, GPU resources based on a GPU cluster also include loading multiple GPU cards;

[0110] When loading a GPU card, a first bus address is assigned to the GPU card. Based on the first bus address, the bus addresses of at least one GPU card already loaded in the GPU cluster, and the bus address allocation logic, the target bus address of the GPU card is determined.

[0111] In this embodiment of the disclosure, before creating an elastic container instance based on the GPU resources of the GPU cluster, a GPU cluster can be established. This process of establishing a GPU cluster can be understood as loading multiple GPU cards. Furthermore, during the loading of a GPU card, the target bus address of that GPU card needs to be determined to enable normal communication and collaborative work between the GPU cards within the GPU cluster.

[0112] In this embodiment of the disclosure, bus address allocation logic is pre-configured in the source code of the first virtualization container to determine the bus address of the GPU card. Specifically, when a GPU card is being loaded, an initial, temporary first bus address is allocated to the GPU card. The allocation process of the first bus address can be implemented based on a hardware detection module and initial allocation rules. In one example, the hardware detection module scans the PCI bus of the GPU card, determines the range of free and available bus addresses, and then allocates a first bus address within that range to the GPU card according to the initial allocation rules. Here, the initial allocation rules can include bus address allocation rules based on the bus start address and an incrementing rule. For example, if the bus start address is 0x1000 and the increment step is 0x100, when the first GPU card is loaded, the first bus address of the first GPU card can be allocated as 0x1000; when the second GPU card is loaded, the first bus address of the second GPU card can be allocated as 0x1100.

[0113] Furthermore, based on the bus address allocation logic, the first bus address is compared one by one with at least one bus address already loaded in the GPU cluster to determine the target bus address. Specifically, if the comparison process finds that the first bus address of the GPU card being loaded is the same as the bus address of another GPU card in the GPU cluster, i.e., there is a bus address conflict, then the first bus address is skipped (or ignored) and no longer considered as a candidate for the target bus address, and the first bus address of the GPU card being loaded is re-determined. Then, the above comparison operation is performed again until a bus address that does not conflict with any existing bus addresses in the GPU cluster is found, and this bus address is determined as the target bus address of the GPU card being loaded.

[0114] By comparing the first bus address of the newly loaded GPU card with the existing bus addresses in the GPU cluster, the target bus address of the GPU card can be determined, which can reduce the occurrence of address conflicts and thus improve the stability of the GPU cluster operation.

[0115] It is understandable that before applying the methods disclosed herein, it is necessary to install and configure components such as the container management engine, container runtime, and QEMU on each node in advance to support the creation of subsequent elastic container instances.

[0116] In this embodiment of the disclosure, if the remaining space of the container storage unit is insufficient to create a new elastic container instance, the container storage unit can be increased by triggering the Kubernetes HorizontalPod Autoscaler (HPA) to support the creation of elastic container instances.

[0117] Figure 3 This is a schematic diagram of a system for creating and running a flexible container instance according to an embodiment of the present disclosure.

[0118] like Figure 3 As shown, the system may include a K8S API Server 310, a container management engine 320, and an image management system 330.

[0119] In the K8S API Server 310, multiple virtual nodes (VNodes) 311 can be included. Here, VNode 311 can include virtual entities (such as virtual machines) running on physical nodes, and the VNode 311 can serve as the target node of a container storage unit.

[0120] The K8S API Server 310 may also include multiple node agents 312 (such as Virtual-Kubelets). In this embodiment, the node agents 312 can be used to manage container storage units on VNode 311 and implement tasks on VNode 311. Here, each node agent 312 may correspond to one VNode 311, or each node agent 312 may correspond to multiple VNodes 311. This embodiment is only an example and does not impose specific limitations.

[0121] The Kubernetes API Server 310 may also include a central scheduling module 313 (such as an Elastic Container Instance Service (eci-service)). This central scheduling module 313 interacts with multiple node agents 312 via the Google Remote Procedure Call (GRPC) protocol to handle lifecycle events of container storage units (such as container storage unit creation, status changes, billing, deletion, etc.).

[0122] The system also includes a container management engine 320 for managing the first virtualized container 321, including operations such as creation, activation, updating, and deletion. The first virtualized container 321 is used to access GPU resources in the GPU cluster to create elastic container instances.

[0123] The system also includes an image management system 330, which is integrated with the container management engine 320 to store image configuration data and corresponding image files for running elastic container instances. Here, the container management engine 320 can pull image files from the image management system 330 to run elastic container instances.

[0124] Furthermore, the K8S API Server 310 can communicate with the Container Management Engine 320 and the Image Management System 330 to enable the creation and operation of Elastic Container Instances.

[0125] This disclosed solution enables the first virtualized container through a container management engine and QEMU, and then uses the first virtualized container to create elastic container instances, achieving stronger isolation compared to traditional container runtimes. On this basis, each elastic container instance can be created by an independent first virtualized container, thereby reducing potential security risks.

[0126] Furthermore, leveraging the resource advantages of GPU chips, such as their hardware-level parallel computing capabilities, it can accelerate the processing of computationally intensive tasks during the creation phase of elastic container instances, thereby improving creation efficiency. Simultaneously, the parallel processing characteristics of GPU chips enable them to handle the creation needs of multiple elastic container instances concurrently, further enhancing resource utilization.

[0127] This disclosure also proposes a flexible container instance creation apparatus. Figure 4 This is a schematic diagram of the structure of a flexible container instance creation apparatus 400 according to an embodiment of the present disclosure, including:

[0128] The first creation module 410 is used to create container storage units;

[0129] The scheduling module 420 is used to schedule the container storage unit to the target node based on the scheduling algorithm;

[0130] The second creation module 430 is used to create an elastic container instance in the container storage unit of the target node based on the GPU resources of the GPU cluster; wherein the GPU cluster includes multiple GPU cards, and each GPU card includes a GPU chip.

[0131] In some implementations, the second creation module 430 is used for:

[0132] Enable the first virtualized container based on the container management engine;

[0133] The first virtualized container invokes the GPU resources of the GPU cluster to create an elastic container instance in the container storage unit of the target node.

[0134] In some implementations, the source code of the first virtualization container includes logic for allocating the data bus; wherein,

[0135] This allocation logic is used to allocate a data bus to the GPU chip in the GPU card.

[0136] In some implementations, the source code of the first virtualization container includes a disk space allocation tool for allocating storage space to elastic container instances.

[0137] In some implementations, the source code of the first virtualization container includes an initialization timeout threshold for the GPU cards, which satisfies the loading requirements of multiple GPU cards.

[0138] In some implementations, a correspondence exists between the host machine's non-consistent memory access architecture and the individual GPU cards in the GPU cluster; wherein,

[0139] The host machine includes the physical computer running the first virtualization container;

[0140] The mapping is used to configure the container management engine.

[0141] In some implementations, the source code of the first virtualization container includes bus address allocation logic;

[0142] This disclosure also proposes a flexible container instance creation apparatus. Figure 5 This is a schematic diagram of the structure of an elastic container instance creation apparatus 500 according to an embodiment of the present disclosure, which also includes a cluster establishment module 540 for loading multiple GPU cards;

[0143] When loading a GPU card, a first bus address is assigned to the GPU card. Based on the first bus address, the bus address of at least one GPU card already loaded in the GPU cluster, and the bus address allocation logic, the target bus address of the GPU card is determined.

[0144] In some implementations, the elastic container instance creation apparatus 500 further includes a runtime module 550 for:

[0145] Based on the elastic container instance, obtain the corresponding image configuration data;

[0146] Run an elastic container instance based on the image configuration data.

[0147] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0148] The acquisition, storage, and application of personal information by users involved in this technical solution comply with relevant laws and regulations and do not violate public order and good morals.

[0149] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0150] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0151] like Figure 6 As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded from storage unit 608 into random access memory (RAM) 603. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0152] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0153] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as the flexible container instance creation method. For example, in some embodiments, the flexible container instance creation method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the flexible container instance creation method described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the flexible container instance creation method by any other suitable means (e.g., by means of firmware).

[0154] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0155] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0156] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0157] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0158] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0159] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0160] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0161] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for creating a resilient container instance, comprising: Create a container storage unit; Based on the scheduling algorithm, the container storage unit is scheduled to the target node; The target node includes a virtual entity running on a physical node; Load multiple GPU cards; Based on the container management engine, the first virtualization container is enabled; GPU resources are requested from the GPU cluster through the GPU resource scheduler in the first virtualization container; according to the availability of the GPU resources, the GPU resources are allocated to the first virtualization container so that the first virtualization container can use the allocated GPU resources to create an elastic container instance in the container storage unit of the target node. The first virtualization container includes an improved Kata container, the improvement including targeted modifications to the source code of the Kata container, the improved Kata container being adapted to the GPU cluster; wherein, the GPU cluster includes multiple GPU cards, the GPU cards including GPU chips; The source code of the first virtualization container includes bus address allocation logic; wherein, when loading a GPU card, a first bus address is allocated to the GPU card; based on the bus address allocation logic, the first bus address is compared one by one with the bus addresses of at least one GPU card already loaded in the GPU cluster. If the first bus address is the same as the bus address of at least one GPU card already loaded in the GPU cluster, a bus address conflict is determined, the first bus address is skipped, and the first bus address of the GPU card is re-determined. The comparison operation is performed again until a bus address that does not conflict with the bus addresses of at least one GPU card already loaded in the GPU cluster is found, and this bus address is determined as the target bus address of the GPU card.

2. The method according to claim 1, wherein, The source code of the first virtualization container also includes logic for allocating the data bus; among which, The allocation logic is used to allocate the data bus to the GPU chip in the GPU card.

3. The method according to claim 1 or 2, wherein, The source code of the first virtualization container also includes an initialization timeout threshold for the GPU card, which satisfies the loading requirements of the multiple GPU cards.

4. The method according to claim 3, wherein, There is a correspondence between the host machine's non-consistent memory access architecture and the individual GPU cards in the GPU cluster; wherein... The host machine includes a physical computer running the first virtualization container; The mapping relationship is used to configure the container management engine.

5. The method according to claim 4, wherein, The source code of the first virtualization container also includes a disk space allocation tool, which is used to allocate storage space for the elastic container instance.

6. The method according to claim 1 or 2, further comprising: Based on the elastic container instance, obtain the corresponding image configuration data; Run the elastic container instance based on the image configuration data.

7. An apparatus for creating a flexible container instance, comprising: The first creation module is used to create container storage units; The cluster creation module is used to load multiple GPU cards; A scheduling module is used to schedule the container storage unit to a target node based on a scheduling algorithm; the target node includes a virtual entity running on a physical node; The second creation module is used to enable the first virtualized container based on the container management engine; request GPU resources from the GPU cluster through the GPU resource scheduler in the first virtualized container; allocate the GPU resources to the first virtualized container according to the availability of the GPU resources; so that the first virtualized container can use the allocated GPU resources to create an elastic container instance in the container storage unit of the target node. The first virtualization container includes an improved Kata container, the improvement including targeted modifications to the source code of the Kata container, the improved Kata container being adapted to the GPU cluster; wherein, the GPU cluster includes multiple GPU cards, the GPU cards including GPU chips; The source code of the first virtualization container includes bus address allocation logic; wherein, when loading a GPU card, a first bus address is allocated to the GPU card; based on the bus address allocation logic, the first bus address is compared one by one with the bus addresses of at least one GPU card already loaded in the GPU cluster. If the first bus address is the same as the bus address of at least one GPU card already loaded in the GPU cluster, a bus address conflict is determined, the first bus address is skipped, and the first bus address of the GPU card is re-determined. The comparison operation is performed again until a bus address that does not conflict with the bus addresses of at least one GPU card already loaded in the GPU cluster is found, and this bus address is determined as the target bus address of the GPU card.

8. The apparatus according to claim 7, wherein, The source code of the first virtualization container also includes logic for allocating the data bus; among which, The allocation logic is used to allocate the data bus to the GPU chip in the GPU card.

9. The apparatus according to claim 7 or 8, wherein, The source code of the first virtualization container also includes an initialization timeout threshold for the GPU card, which satisfies the loading requirements of the multiple GPU cards.

10. The apparatus according to claim 9, wherein, There is a correspondence between the host machine's non-consistent memory access architecture and the individual GPU cards in the GPU cluster; wherein... The host machine includes a physical computer running the first virtualization container; The mapping relationship is used to configure the container management engine.

11. The apparatus according to claim 10, wherein, The source code of the first virtualization container also includes a disk space allocation tool, which is used to allocate storage space for the elastic container instance.

12. The apparatus according to claim 7 or 8, further comprising an operation module for: Based on the elastic container instance, obtain the corresponding image configuration data; Run the elastic container instance based on the image configuration data.

13. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6.

15. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.

Images