Elastic container instance creation method and device, equipment and storage medium

Abstract

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

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to technical fields such as cloud computing and big data. Background Art

[0002] Elastic Container Instances (ECI) are a service based on container and serverless technologies, primarily used to run containers in cloud environments. With the rapid development of cloud computing and microservices architectures, ECIs have become core infrastructure for building cloud-native applications due to their rapid deployment and dynamic resource scaling. However, current methods for creating ECIs present challenges in terms of performance optimization and security isolation. Therefore, efficiently and securely creating ECIs has become a pressing issue. Summary of the Invention

[0003] The present disclosure provides a flexible container instantiation method, apparatus, device, and storage medium.

[0004] According to one aspect of the present disclosure, a method for creating an elastic container instance is provided, including:

[0005] Create container storage units;

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

[0007] In the container storage unit of the target node, an elastic container instance is created based on GPU resources of a GPU cluster; wherein the GPU cluster includes multiple GPU cards, and the GPU cards include GPU chips.

[0008] According to another aspect of the present disclosure, a device for creating an elastic container instance is provided, comprising:

[0009] A first creation module is used to create a container storage unit;

[0010] A scheduling module, configured to schedule the container storage unit to a target node based on a scheduling algorithm;

[0011] The second creation module 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 the GPU card includes a GPU chip.

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

[0013] at least one processor; and

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

[0015] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform any method in the embodiments of the present disclosure.

[0016] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable the computer to execute any method according to the embodiments of the present disclosure.

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

[0018] This disclosure creates a container storage unit and dispatches it to a target node, allowing the creation of elastic container instances within the container storage unit based on GPU resources. 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 creation of multiple elastic container instances to be handled simultaneously, reducing resource fragmentation and improving resource utilization.

[0019] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings are provided to facilitate a better understanding of the present invention and do not constitute a limitation of the present disclosure.

[0021] Figure 1 This is a flowchart of a method for creating an elastic container instance according to an embodiment of the present disclosure;

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

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

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

[0025] Figure 5 is a structural diagram of an elastic container instance creation device 500 according to an embodiment of the present disclosure;

[0026] Figure 6 A schematic block diagram of an example electronic device 600 is shown, which may be used to implement embodiments of the present disclosure. DETAILED DESCRIPTION

[0027] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be appreciated by those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0028] The “and / or” in the embodiments of the present disclosure indicates that there may be three relationships. For example, A and / or B may indicate three situations: A exists alone, A and B exist at the same time, and B exists alone. The term “at least one” herein indicates any combination of at least two of any one or more of a plurality of. For example, at least one of A, B, and C may indicate any one or more elements selected from the set consisting of A, B, and C. The terms “first” and “second” herein refer to and distinguish between multiple similar technical terms, and do not mean to limit the order or to limit the meaning to only two. For example, the first feature and the second feature refer to two categories / two features. The first feature may be one or more, and the second feature may also be one or more.

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

[0030] Kubernetes (abbreviated as K8S): an open source platform for automating the deployment, scaling, and management of containerized applications.

[0031] Container: A lightweight virtualization technology used to package applications and their dependencies so that they can be ported and run 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 interoperability between different container tools (such as Docker, Podman, and containerd).

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

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

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

[0037] In recent years, cloud computing and microservices architectures have rapidly developed, embracing elastic container instance solutions based on standard container runtimes (such as runc). These solutions leverage the Linux kernel's namespace and control group technologies to achieve lightweight isolation. They can encapsulate applications and their dependencies at the process level on a single host, enabling rapid deployment, dynamic scaling, and multi-tenant resource management.

[0038] However, as enterprises increasingly demand more security from elastic container instances, traditional container isolation mechanisms are gradually exposing security shortcomings. First, the shared kernel between containers and the host makes them vulnerable to kernel vulnerabilities, allowing attackers to penetrate the host or other tenant containers through the container. Second, namespaces provide only logical isolation and cannot protect against data leakage risks caused by privilege escalation or malicious configuration. Furthermore, in multi-tenant co-location scenarios, containers lacking hardware-level isolation can lead to performance degradation and privacy risks due to resource contention.

[0039] Related technologies attempt to reduce the attack surface by introducing a sandbox as an additional isolation layer, creating a security barrier between container applications and the host kernel. However, because its operational 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 relies on the robustness of the host kernel and cannot completely eliminate the risk of kernel-level attacks.

[0040] To address the above issues, the present disclosure proposes a method for creating elastic container instances. This method can create elastic container instances based on virtualized containers by invoking GPU resources in a graphics processing unit (GPU) cluster, thereby improving creation efficiency and security.

[0041] Figure 1 The following is a flowchart of a method for creating an elastic container instance according to an embodiment of the present disclosure, including:

[0042] S110, creating a container storage unit;

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

[0044] S130: 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 the GPU cards include GPU chips.

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

[0046] In another example, a user can use a K8S command line tool (such as kubectl) to run a container storage unit creation instruction (such as kubectl apply-f pod-definition.yaml) to create a container storage unit.

[0047] In the disclosed embodiment, after a container storage unit is created, the K8S API Server may 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. Furthermore, after the container storage unit is scheduled, the container storage unit may be marked as running.

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

[0049] (1) Filtering stage: Based on the preset conditions, at least one candidate node that meets the requirements is selected.

[0050] In this stage, in one example, nodes that meet the requirements can be screened by checking whether the memory, storage, and GPU resources of each node meet the requirements (requests) and limits (limits) of the container storage unit. For example, if the container storage unit requires 2GB of video memory and 3GB of storage, if the remaining resources of the node do not meet the requirements of the container storage unit, the node will be filtered out.

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

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

[0053] Specifically, the scheduler can be used to score various types of resources in candidate nodes based on scoring rules. Here, the scoring rules can be related to the utilization rate of each type of resource in the candidate node, and the score for each type of resource is determined based on the utilization rate of each type of resource. For example, if the candidate node's memory utilization rate is 30% and the remaining rate is 70%, the score for the memory resource can be 70. For another example, if the candidate node's network bandwidth utilization rate is 60%, the score for the candidate node's network bandwidth resource can be 60.

[0054] In this example, you can preset the weights of various types of resources. Generally speaking, you can set higher weights for compute-intensive resources (such as memory, video memory, etc.), and set smaller weights for non-critical or general resources (such as disk I / O, network bandwidth, etc.).

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

[0056] In an embodiment of the present disclosure, after the container storage unit is dispatched 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, where the GPU cluster may include multiple GPU cards.

[0057] Here, the GPU card is a hardware device obtained by integrating multiple core components, among which the core components include GPU chips, audio processing units, heat dissipation modules, etc. The components work together to achieve efficient parallel processing capabilities.

[0058] In the disclosed embodiments, a GPU chip is designed specifically for parallel computing and integrates a large number of programmable computing component modules (such as computing units, CUDA Cores, Tensor Cores, etc.). These cores work together to achieve high-throughput numerical calculations and data processing. GPU resources can include the computing power and video memory of the GPU chip in the GPU card, which can be used to create elastic container instances.

[0059] Using the above method, by creating a container storage unit and dispatching it to the target node, elastic container instances can be created within the container storage unit 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 computationally intensive tasks of elastic container instance creation, improving creation efficiency. Furthermore, the parallel processing characteristics of GPU chips allow the creation of multiple elastic container instances to be handled simultaneously, reducing resource fragmentation and improving resource utilization.

[0060] Figure 2 The figure is a flowchart of creating and running an elastic container instance according to an embodiment of the present disclosure.

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

[0062] S201: Create a container storage unit and dispatch it to a target node.

[0063] It should be noted that, in the embodiment of the present disclosure, the creation and scheduling method of the container storage unit and related examples can be found in the above S110 and S120 related descriptions, which will not be repeated here.

[0064] S202: Activate a first virtualized container.

[0065] S203: Create an elastic container instance using the first virtualized container.

[0066] In some embodiments, creating an elastic container instance in a container storage unit of a target node based on GPU resources of a GPU cluster includes:

[0067] Based on the container management engine, enable the first virtualized container;

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

[0069] In an embodiment of the present 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 Kata runtime). Here, the container management engine can be Containerd.

[0070] Furthermore, the container management engine calls the virtualization runtime and sends a request to create the first virtualization container to the virtualization runtime. Then, the virtualization runtime uses QEMU to enable the first virtualization container.

[0071] In one example, a GPU resource scheduler (e.g., a device plugin) in the first virtualized container can request GPU resources from the GPU cluster. The GPU resource scheduler dynamically allocates GPU resources to the first virtualized container based on GPU resource availability (e.g., computing power usage or video memory usage). Ultimately, 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.

[0072] Using this approach, the container management engine enables the first virtualized container to access GPU resources to create elastic container instances. Because the first virtualized container uses hardware virtualization technology to provide an independent kernel-level isolation environment for each elastic container instance, container escapes and resource contention are reduced. Furthermore, the lightweight design of the first virtualized container reduces elastic container instance initialization time and improves creation efficiency.

[0073] In addition, the key point of this step also includes adapting the first virtualized container to the GPU cluster to enable interaction between the first virtualized container and the GPU cluster. The specific implementation method will be described in detail later.

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

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

[0076] In the disclosed embodiments, after an elastic container is created, the container management engine can invoke the relevant service components to initiate a query request to the image management system. The query request can include the unique identifier of the elastic container instance, and the image management system can include the image file and corresponding image configuration data.

[0077] After receiving the query request, the image management system can, based on the unique identifier of the elastic container instance, traverse the records of each image configuration data in the image management system that is related to the elastic container instance, and filter out the corresponding image configuration data from the multiple image configuration data. Here, the 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 according to the storage location information in the image configuration data. In one example, the operation of the elastic container instance can be achieved through the overlay mount technology. Specifically, an Overlay file system can be created in the host's file system. The Overlay file system includes a lower directory (lowerdir), an upper directory (upperdir) and a merged directory (mergedir). Here, lowerdir points to the directory where the image file is located, which contains all the files and directory structures in the image; upperdir is the writable layer created by the elastic container instance. Any modification of 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, which integrates the contents of lowerdir and upperdir, so that the program in the elastic container instance can directly obtain the required files and directories by accessing mergedir.

[0079] Furthermore, image files can be mounted into the lowerdir. This way, all files and directories in the image file become the base layer of the overlay file system. Then, using overlay mount technology, the upperdir of the elastic container instance and the lowerdir where the image file resides are merged. After this merger, the elastic container instance has a complete, read-write file system environment, allowing it to run.

[0080] By using the above approach to obtain the corresponding image configuration data through the elastic container instance, the obtained image configuration data can be closely associated with the elastic container instance, thereby improving the accuracy of the image file determination. Furthermore, with the image file more closely associated with the elastic container instance, the operating efficiency of the elastic container instance can be improved.

[0081] In some embodiments, the first virtualized container includes a modified Kata container.

[0082] As mentioned above, a key point of step S203 is to enable the interaction between the first virtualized container and the CPU cluster. Since Kata containers are mainly suitable for interacting with the Central Processing Unit (CPU) and calling CPU resources to create elastic container instances, this reduces the efficiency of elastic container instances. Therefore, to implement the above step S203, it is necessary to enable the improved Kata container (i.e., the first virtualized container) to interact with the GPU cluster, so as to use the improved Kata container to call GPU resources to create elastic container instances, thereby improving creation efficiency.

[0083] Since the currently commonly used Kata containers are mainly suitable for interacting with the CPU, such Kata containers may have compatibility or functional defects when interacting directly with the GPU cluster, which hinders the Kata containers from obtaining GPU resources. To solve such problems, the embodiments of the present disclosure make targeted improvements to the source code of the currently commonly used Kata containers to obtain a first virtualized container, so that the improved Kata container (i.e., the first virtualized container) can correctly interact with the GPU cluster and call GPU resources, meeting the requirements for creating elastic container instances.

[0084] Using the above method, the improved Kata container (i.e., the first virtualized container) can be used for the subsequent elastic container creation process. Since Kata containers have advantages such as strong isolation and low-latency startup, the first virtualized 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 virtualized container to the GPU cluster, the following targeted improvements can be made based on the source code of the Kata container. Here, the source code of the improved Kata container can be considered as the source code of the first virtualized container. In other words, the improved Kata container can be considered as the first virtualized container.

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

[0087] The allocation logic is used to allocate data buses to GPU chips in the GPU card.

[0088] In the disclosed embodiments, a 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, data transmission between different components is achieved using a common communication protocol and data encoding specifications. Generally speaking, 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 memory mapping and access permissions for input and output devices.

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

[0091] In one example, to implement the method disclosed herein, multiple GPU cards, such as 8 GPU cards, can generally be used simultaneously. The IOMMU Group corresponding to each GPU card has two devices, which requires two PCI buses. In the embodiment of the present disclosure, since the audio processing unit is not used in the process of creating an 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 the data bus (or PCI bus) is not allocated.

[0092] It should be noted that the detection method of the GPU chip and the audio processing unit in the embodiment of the present disclosure may include but is not limited to a detection method based on hardware identification, a detection method based on runtime status, etc., and the method disclosed in the present disclosure does not impose specific restrictions on this.

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

[0094] In some embodiments, the source code of the first virtualization container includes an initialization timeout threshold of a GPU card, and the initialization timeout threshold of the GPU card meets the loading requirements of multiple GPU cards.

[0095] In the disclosed embodiments, the Kata container source code sets a default initialization timeout threshold for each GPU card. However, in multi-GPU application scenarios (e.g., eight GPU cards), hardware initialization, driver loading, or resource scheduling processes can take a long time, often exceeding the default initialization timeout threshold, causing GPU loading to time out and fail.

[0096] The disclosed method can confirm through log analysis and performance monitoring that the cause of this problem is that the initialization timeout threshold is not adapted to the high-density multi-GPU card application scenario. Therefore, based on the source code of the Kata container, the initialization timeout threshold can be extended so that the initialization timeout threshold in the source code of the first virtualized container can meet the initialization, driver loading and other loading requirements of multiple GPU cards. At the same time, for GPU clusters with different numbers of GPU cards, a multi-level timeout strategy can be set to reduce resource waste and reduce response delay.

[0097] The above approach, based on the initialization timeout threshold in the source code of the first virtualized container, can meet the complex requirements of multi-GPU card loading scenarios, reduce the problem of loading failure caused by GPU card initialization delay, and thus improve the success rate of loading or mapping the GPU cluster to the first virtualized container.

[0098] In some embodiments, there is a corresponding relationship between the non-uniform memory access architecture of the host machine and each GPU card in the GPU cluster; wherein,

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

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

[0101] In the disclosed embodiments, when the first virtualized container interacts with the GPU cluster, there are issues with inter-GPU communication performance. Inter-GPU communication performance refers to the data transmission efficiency and latency between different GPUs in a multi-GPU cluster. Generally speaking, inter-GPU communication transmission speeds are slow, typically only 2 GB / s.

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

[0103] Based on this approach, the correspondence can be configured in the container management engine, so that after the first virtualized container is enabled, it can determine multiple GPU cards corresponding to the first virtualized container based on the correspondence, thereby improving the GPU resource calling process.

[0104] In this way, after the first virtualized container is enabled based on the container management engine, the GPU resource request task in the first virtualized container can directly access the NUMA of the host machine, and based on the optimal topological relationship between the GPU card and NUMA, determine the multiple GPU cards that provide GPU resources, thereby improving the efficiency of GPU resource calling and data transmission between multiple GPU cards.

[0105] In some embodiments, the source code of the first virtualized container includes a disk space allocation tool, which is used to allocate storage space for the elastic container instance.

[0106] In an embodiment of the present disclosure, a disk space allocation tool (such as xfs_quota) can be pre-set in the source code of the first virtualization container to impose quota restrictions on the storage space of the elastic container instance. Specifically, the disk space allocation tool has the ability to set storage space quotas, and can allocate specific storage space limits for individual users, groups, or projects. In addition, the disk space allocation tool can also monitor the usage of storage space in the elastic container instance in real time and detect abnormal occupation in a timely manner. In addition, the disk space allocation tool also supports flexible storage space quota adjustments, and can make storage space quota adjustment responses according to changes in the storage space requirements of the elastic container instance.

[0107] This approach allocates storage space to each elastic container instance based on the amount of data it holds. This reduces the risk of insufficient storage space in the current elastic container instance due to excessive data in other elastic containers. Furthermore, since each elastic container instance has independent storage space, the security of the elastic container instance during subsequent operations is enhanced.

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

[0109] For GPU resources based on a GPU cluster, you must load multiple GPU cards before creating an elastic container instance.

[0110] When a GPU card is loaded, a first bus address is allocated to the GPU card, and a target bus address of the GPU card is determined according to 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.

[0111] In the disclosed embodiments, before creating an elastic container instance based on the GPU resources of a GPU cluster, a GPU cluster can be established. This process can be understood as loading multiple GPU cards. Furthermore, during the loading process of a GPU card, the target bus address of the GPU card must be determined to ensure normal communication and collaboration between the subsequent GPU cards in the GPU cluster.

[0112] In an embodiment of the present disclosure, bus address allocation logic is pre-configured in the source code of the first virtualization container. The bus address of the GPU card is determined based on the bus address allocation logic. Specifically, when a GPU card is loaded, an initial, temporary first bus address is assigned to the GPU card. This first bus address allocation process 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 to determine a range of free, available bus addresses. Then, according to the initial allocation rules, the GPU card is assigned a first bus address within this range. The initial allocation rules can include bus address allocation rules based on a bus starting address and an incrementing rule. For example, if the bus starting address is 0x1000 and the incrementing step is 0x100, when the first GPU card is loaded, the first bus address of the first GPU card may be assigned 0x1000; when the second GPU card is loaded, the second GPU card's first bus address may be assigned 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 it is found during the comparison process that the first bus address of the GPU card being loaded is the same as the bus address of a GPU card in the GPU cluster, that is, there is a bus address conflict, then the first bus address is skipped (or ignored) and is no longer used 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 all existing bus addresses in the GPU cluster is found, and the bus address is determined as the target bus address of the GPU card being loaded.

[0114] By using the above method, the first bus address of the newly loaded GPU card is compared with the bus addresses already existing in the GPU cluster to determine the target bus address of the GPU card, 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 method disclosed herein, it is necessary to complete the installation and configuration of components such as the container management engine, container runtime, and QEMU on each node in advance to support the subsequent creation of elastic container instances.

[0116] In the embodiment of the present 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 K8S horizontal Pod Autoscaler (HPA) to support the creation of the elastic container instance.

[0117] Figure 3 FIG. 1 is a system diagram for creating and running an elastic 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 (Virtual-Node, VNode) 311 may be included. Here, the VNode 311 may include a virtual entity (such as a virtual machine) running on a physical node, and the VNode 311 may serve as a target node of a container storage unit.

[0120] The K8S API Server 310 may also include multiple node agents 312 (such as Virtual-Kubelet). In the disclosed embodiment, the node agents 312 may be used to manage container storage units on the VNode 311 and implement tasks on the VNode 311. Each node agent 312 may correspond to one VNode 311, or each node agent 312 may correspond to multiple VNodes 311. This disclosed embodiment is merely illustrative and is not intended to be limiting.

[0121] The K8S API Server 310 may also include a central scheduling module 313 (such as the Elastic Container Instance Service (eci-service)). The 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 creation, state change, billing, and deletion of container storage units).

[0122] The system further includes a container management engine 320 for managing a first virtualized container 321, including operations such as creation, activation, update, and deletion. The first virtualized container 321 is used to call GPU resources in a GPU cluster to create an elastic container instance.

[0123] The system also includes an image management system 330, which is integrated with the container management engine 320 and is used 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 implement the creation and operation process of elastic container instances.

[0125] The disclosed solution uses a container management engine and QEMU to enable a first virtualized container, and then uses the first virtualized container to create an elastic container instance, achieving stronger isolation than 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, GPU chips, with their hardware-level parallel computing capabilities, can accelerate the processing of compute-intensive tasks during the creation phase of elastic container instances, thereby improving creation efficiency. Furthermore, the parallel processing characteristics of GPU chips enable them to handle the creation of multiple elastic container instances simultaneously, further improving resource utilization.

[0127] The present disclosure also provides a device for creating an elastic container instance. Figure 4 FIG. 4 is a schematic diagram of a structure of an elastic container instance creation apparatus 400 according to an embodiment of the present disclosure, including:

[0128] A first creation module 410 is used to create a container storage unit;

[0129] A scheduling module 420 is configured to schedule the container storage unit to a target node based on a scheduling algorithm;

[0130] The second creation module 430 is configured 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 the GPU cards include GPU chips.

[0131] In some implementations, the second creation module 430 is configured to:

[0132] Based on the container management engine, enable the first virtualized container;

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

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

[0135] The allocation logic is used to allocate data buses to GPU chips in the GPU card.

[0136] In some embodiments, the source code of the first virtualized container includes a disk space allocation tool, which is used to allocate storage space for the elastic container instance.

[0137] In some implementations, the source code of the first virtualization container includes an initialization timeout threshold of a GPU card, and the initialization timeout threshold of the GPU card meets the loading requirements of multiple GPU cards.

[0138] In some embodiments, there is a corresponding relationship between the non-uniform memory access architecture of the host machine and each GPU card in the GPU cluster; wherein,

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

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

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

[0142] The present disclosure also provides a device for creating an elastic container instance. Figure 5 is a structural diagram of an elastic container instance creation device 500 according to an embodiment of the present disclosure, further comprising a cluster establishment module 540 for loading multiple GPU cards;

[0143] When a GPU card is loaded, a first bus address is allocated to the GPU card, and a target bus address of the GPU card is determined according to 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.

[0144] In some embodiments, the elastic container instance creation apparatus 500 further includes an execution module 550 configured to:

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

[0146] Run elastic container instances based on image configuration data.

[0147] For the description of specific functions and examples of each module and submodule of the device in the embodiment of the present disclosure, please refer to the relevant description of the corresponding steps in the above method embodiment, which will not be repeated here.

[0148] In the technical solution disclosed herein, the acquisition, storage and application of personal information of users involved are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0149] According to an embodiment of the present disclosure, the present 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 can 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 provided as examples only and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

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

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

[0153] Computing unit 601 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized 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. Computing unit 601 performs the various methods and processes described above, such as the elastic container instance creation method. For example, in some embodiments, the elastic container instance creation method can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed onto device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by computing unit 601, one or more steps of the elastic container instance creation method described above can be performed. Alternatively, in other embodiments, computing unit 601 can be configured to perform the elastic container instance creation method in any other suitable manner (e.g., via firmware).

[0154] Various embodiments of the systems and techniques described 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), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system comprising at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0155] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0156] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, 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 (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the 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 acoustic input, voice input, or tactile input).

[0158] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0159] A computer system may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship arises through computer programs running on the respective computers and having a client-server relationship with each other. The server may be a cloud server, a server in a distributed system, or a server integrated with a blockchain.

[0160] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved. This is not limited herein.

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

Claims

1. A method for creating an elastic container instance, comprising: Create container storage units; Based on a scheduling algorithm, scheduling the container storage unit to a target node; In the container storage unit of the target node, an elastic container instance is created based on GPU resources of a graphics processing unit (GPU) cluster; wherein the GPU cluster includes multiple GPU cards, and the GPU cards include GPU chips.

2. The method according to claim 1, wherein The step of creating an elastic container instance in the container storage unit of the target node based on the GPU resources of the GPU cluster includes: Based on the container management engine, enable the first virtualized container; The GPU resources of the GPU cluster are called through the first virtualized container to create the elastic container instance in the container storage unit of the target node.

3. The method according to claim 2, wherein: The source code of the first virtualized container includes the allocation logic for the data bus; wherein, The allocation logic is used to allocate the data bus to the GPU chip in the GPU card.

4. The method according to claim 2 or 3, wherein: The source code of the first virtualization container includes an initialization timeout threshold of a GPU card, and the initialization timeout threshold of the GPU card meets a loading requirement of the multiple GPU cards.

5. The method according to claim 4, wherein There is a corresponding relationship between the non-uniform memory access architecture of the host machine and each of the GPU cards in the GPU cluster; wherein, The host machine includes a physical computer running the first virtualized container; The corresponding relationship is used to configure the container management engine.

6. The method according to claim 5, wherein: The source code of the first virtualized container includes a disk space allocation tool, and the disk space allocation tool is used to allocate storage space for the elastic container instance.

7. The method according to claim 6, wherein: The source code of the first virtualized container includes bus address allocation logic; The GPU resource based on the GPU cluster further includes loading the multiple GPU cards before creating the elastic container instance; When loading one of the GPU cards, a first bus address is assigned to the GPU card, and a target bus address of the GPU card is determined according to the first bus address, the bus address of at least one GPU card already loaded in the GPU cluster, and the bus address assignment logic.

8. The method according to any one of claims 1 to 3, further comprising: Based on the elastic container instance, obtain corresponding image configuration data; Based on the image configuration data, the elastic container instance is run.

9. A device for creating an elastic container instance, comprising: A first creation module is used to create a container storage unit; A scheduling module, configured to schedule the container storage unit to a target node based on a scheduling algorithm; The second creation module 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 the GPU cards include GPU chips.

10. The device according to claim 9, wherein The second creation module is used to: Based on the container management engine, enable the first virtualized container; The GPU resources of the GPU cluster are called through the first virtualized container to create the elastic container instance in the container storage unit of the target node.

11. The device according to claim 10, wherein The source code of the first virtualized container includes the allocation logic for the data bus; wherein, The allocation logic is used to allocate the data bus to the GPU chip in the GPU card.

12. The device according to claim 10 or 11, wherein The source code of the first virtualization container includes an initialization timeout threshold of a GPU card, and the initialization timeout threshold of the GPU card meets a loading requirement of the multiple GPU cards.

13. The device according to claim 12, wherein There is a corresponding relationship between the non-uniform memory access architecture of the host machine and each of the GPU cards in the GPU cluster; wherein, The host machine includes a physical computer running the first virtualized container; The corresponding relationship is used to configure the container management engine.

14. The device according to claim 13, wherein The source code of the first virtualized container includes a disk space allocation tool, and the disk space allocation tool is used to allocate storage space for the elastic container instance.

15. The device according to claim 14, wherein The source code of the first virtualized container includes bus address allocation logic; The device also includes a cluster establishment module for loading the multiple GPU cards; When loading one of the GPU cards, a first bus address is assigned to the GPU card, and a target bus address of the GPU card is determined according to the first bus address, the bus address of at least one GPU card already loaded in the GPU cluster, and the bus address assignment logic.

16. The apparatus according to any one of claims 9 to 11, further comprising an operation module configured to: Based on the elastic container instance, obtain corresponding image configuration data; Based on the image configuration data, the elastic container instance is run.

17. 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, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 8.

18. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions are used to cause the computer to execute the method according to any one of claims 1-8.

19. A computer program product comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 8.

Images