Method, apparatus, and storage medium for loading a container

Abstract

The application provides a container loading method, device, equipment and storage medium. The method can be applied to a virtual guest. A host corresponding to the guest stores container image data and corresponding metadata required for loading the container in a mirror format. The metadata is stored in a first file in the host. The method can include: in response to a loading requirement for the container, sending a first access request for directly accessing the first file to a para-virtualization unit, so that the para-virtualization unit maps the first file to the guest in response to the first access request; querying the mapped first file to obtain the metadata to determine a storage location of the container image data; and accessing the container image data based on the storage location to improve container loading efficiency.

Description

Technical Field

[0001] This application relates to computer technology, specifically to a method, apparatus, device, and storage medium for loading a container. Background Technology

[0002] In secure container scenarios, image loading speed is a crucial performance metric for business applications. Improved container loading speed can significantly accelerate deployment time, shorten end-to-end (E2E) time, and reduce costs. In secure container scenarios, container images are stored on the host machine. The guest machine needs to retrieve the container image data from the host machine through a VirtioS device (a semi-virtualized device) managed by the VMM (Virtual Machine Manager) to complete the image loading.

[0003] In related technologies, when loading a container, the Guest generates a read data request based on the FUSE protocol (the file access protocol used by Virtiofs) and sends it to the Host, which is then executed by Virtiofs. Virtiofs responds to the read data request, completes the read operation, and returns the container image data to the Guest through data copying.

[0004] This container loading method requires a large number of read data requests because the container image data includes a large number of files. Therefore, it requires a lot of read operations and trap-out operations, which consumes a lot of CPU and results in low container loading efficiency. Summary of the Invention

[0005] In view of this, this application discloses at least one method for loading a container. This method can be applied to a virtual client (Guest), which corresponds to a host (Host). The host and the guest communicate via a semi-virtualization unit. The host stores container image data required for loading the container and metadata corresponding to the container image data in image format. The metadata is stored in a first file in the host. The method includes: in response to a loading requirement for the container, sending a first access request for direct access to the first file to the semi-virtualization unit, causing the semi-virtualization unit to map the first file to the guest in response to the first access request; querying the mapped first file to obtain the metadata to determine the storage location of the container image data; and accessing the container image data stored in the host based on the storage location indicated by the metadata to complete the loading of the container.

[0006] In some embodiments, the Host stores at least two container image data, and loading a container requires accessing the container image data at least twice; querying the first file to obtain multiple metadata to determine the storage location of the container image data includes: querying the first file to obtain target metadata corresponding to at least one target container image data that needs to be accessed to determine the target storage location of the at least one target container image data; accessing the container image data stored by the Host based on the storage location indicated by the metadata includes: accessing the at least one target container image data stored by the Host based on the target storage location indicated by the target metadata.

[0007] In some embodiments, accessing the at least one target container image data stored in the Host based on the target storage location indicated by the target metadata includes: generating a second access request for direct access to the at least one target container image data based on the target storage location indicated by the target metadata; sending the second access request to the semi-virtualization unit, so that the semi-virtualization unit responds to the second access request by mapping the at least one target container image data stored in the Host to the Guest; and querying the mapped at least one target container image data to complete access to the target container image data.

[0008] In some embodiments, the at least one target container image data is continuously stored in a second file in the Host; mapping the at least one target container image data to the Guest includes: mapping at least one target container image data continuously stored in the second file to the Guest.

[0009] In some embodiments, the data size of the at least one target container image data does not exceed the maximum preset data size for a single direct access.

[0010] In some embodiments, before sending a first access request for direct access to the first file to the Host in response to a loading requirement for the container, the method further includes: receiving an image directory passed through the semi-virtualization unit; the image directory indicating the storage location of the first file in the Host; the step of sending the first access request for direct access to the first file to the semi-virtualization unit in response to a loading requirement for the container, so that the semi-virtualization unit maps the first file to the Guest in response to the first access request, includes: generating a first access request for direct access to the first file based on the obtained image directory in response to a loading requirement for the container; sending the first access request to the semi-virtualization unit, so that the semi-virtualization unit invokes the semi-virtualization unit in response to the first access request, retrieves the first file from the storage location indicated by the image directory, and maps the first file to the Guest.

[0011] In some embodiments, the first access request and the second access request are DAX requests generated based on the FUSE protocol, and the semi-virtualization unit is a virtiofs unit or a blobfs unit.

[0012] In some embodiments, the image format includes the Nydus image format; the first file is a bootstrap type file, and the second file is a blob type file.

[0013] This application also proposes a container loading method applied to a semi-virtualization unit mounted on a host, wherein the host corresponds to a virtual client (Guest); the host and the guest communicate through the semi-virtualization unit; the host stores container image data required for loading the container and metadata corresponding to the container image data in image format; wherein the metadata is stored in a first file in the host; the method includes: receiving a first access request sent by the guest in response to the loading requirement of the container; the first access request is used to directly access the first file; in response to the first access request, mapping the first file to the guest, so that the guest queries the mapped first file to obtain the metadata to determine the storage location of the container image data, and accesses the container image data stored in the host based on the storage location indicated by the metadata, so as to complete the loading of the container.

[0014] In some embodiments, the Host stores at least two container image data, and loading a container requires at least two accesses to the container image data; the Guest queries the first file to obtain target metadata corresponding to at least one target container image data required for the current access to determine the target storage location of the at least one target container image data; the method further includes: receiving a second access request initiated by the Guest; the second access request is generated based on the target storage location indicated by the target metadata; in response to the second access request, the at least one target container image data stored in the Host is mapped to the Guest, so that the Guest queries the mapped at least one target container image data to complete the access to the target container image data.

[0015] In some embodiments, the device is applied to a virtual client (Guest), which corresponds to a host (Host), and the host communicates with the guest through a semi-virtualization unit. The host stores container image data required for loading the container and metadata corresponding to the container image data in an image format. The metadata is stored in a first file in the host. The device includes: a sending module, which, in response to a loading requirement for the container, sends a first access request for direct access to the first file to the semi-virtualization unit, so that the semi-virtualization unit maps the first file to the guest in response to the first access request; a querying module, which queries the mapped first file to obtain the metadata to determine the storage location of the container image data; and a loading module, which, based on the storage location indicated by the metadata, accesses the container image data stored in the host to complete the loading of the container.

[0016] In some embodiments, the device is applied to a virtual client (Guest), which corresponds to a host (Host), and the host communicates with the guest through a semi-virtualization unit. The host stores container image data required for loading the container and metadata corresponding to the container image data in an image format. The metadata is stored in a first file in the host. The device includes: a first receiving module, which receives a first access request sent by the guest in response to the loading requirement of the container; the first access request is used to directly access the first file; and a first mapping module, which, in response to the first access request, maps the first file to the guest, so that the guest queries the mapped first file to obtain the metadata to determine the storage location of the container image data, and accesses the container image data stored in the host based on the storage location indicated by the metadata, so as to complete the loading of the container.

[0017] This application also proposes an electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements a container loading method as shown in any of the foregoing embodiments by executing the executable instructions.

[0018] This application also proposes a computer-readable storage medium storing a computer program for causing a processor to execute a container loading method as shown in any of the foregoing embodiments.

[0019] In the aforementioned solution, by using direct access technology of semi-virtualized devices, the first file containing the metadata of the image data is mapped to the Guest. This allows the Guest to traverse the metadata directly within the Guest during the file lookup process without having to trap out of the Host. Then, file access and container loading are completed through the metadata. Compared with related technologies, this reduces the number of times the Host is accessed, the number of traps and reads, and the CPU consumption is reduced, thus improving container loading efficiency.

[0020] It should be understood that the general description above and the detailed description below are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in one or more embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in one or more embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic flowchart illustrating a method for loading a container according to an embodiment of this application;

[0023] Figure 2 This is a comparative diagram of DAX and Read shown in an embodiment of this application;

[0024] Figure 3 This is a schematic flowchart illustrating a method for accessing target container image data according to an embodiment of this application;

[0025] Figure 4 This is a schematic diagram illustrating a scenario of loading a Kata container, as shown in an embodiment of this application.

[0026] Figure 5 This is a flowchart illustrating a method for loading a container, as shown in an embodiment of this application.

[0027] Figure 6 This is a schematic diagram of the structure of a container loading device shown in an embodiment of this application;

[0028] Figure 7 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of devices and methods consistent with some aspects of this application as detailed in the appended claims.

[0030] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items. It should also be understood that the word “if” as used herein, depending on the context, can be interpreted as “when,” “in response to a determination,” or “when…”.

[0031] Based on this, this application proposes a container loading method. This method can be applied to a virtual client (Guest), which corresponds to a host (Host), and the host communicates with the guest through a semi-virtualization unit. The host stores container image data required for loading the container and metadata corresponding to the container image data in image format. The metadata is stored in a first file in the host. The method may include: in response to a loading requirement for the container, sending a first access request for direct access to the first file to the semi-virtualization unit, causing the semi-virtualization unit to map the first file to the guest in response to the first access request; querying the mapped first file to obtain the metadata to determine the storage location of the container image data; and accessing the container image data stored in the host based on the storage location indicated by the metadata to complete the container loading.

[0032] In the aforementioned solution, by using direct access technology of semi-virtualized devices, the first file containing the metadata of the image data is mapped to the Guest. This allows the Guest to traverse the metadata directly within the Guest during the file lookup process without having to trap out of the Host. Then, file access and container loading are completed through the metadata. Compared with related technologies, this reduces the number of times the Host is accessed, the number of traps and reads, and the CPU consumption is reduced, thus improving container loading efficiency.

[0033] The following description, in conjunction with the accompanying drawings, illustrates the embodiments. Please refer to the attached figures. Figure 1 , Figure 1 This is a schematic flowchart illustrating a container loading method according to an embodiment of this application.

[0034] Figure 1 The container loading method shown (hereinafter referred to as the container loading method) can be applied to a virtual client Guest, which corresponds to a host host, and the host communicates with the guest through a semi-virtualized unit.

[0035] The Host and the Guest constitute a virtualization system. The virtualization system refers to a physical computer and one or more virtual computers virtualized on that physical computer. The physical computer can act as the Host, and the virtualized computers can act as the Guests. In some methods, these Guests can be managed by installing a VMM (Virtual Machine Manager) on the Host. This application does not limit the specific types of Host, Guest, or VMM.

[0036] The Host and the Guest can communicate through a semi-virtualized unit.

[0037] The semi-virtualized unit can be a Virtiofs unit or a blobfs. The blobfs can be understood as a Virtiofs compatible with Nydus images.

[0038] Taking Virtiofs as an example of a semi-virtualization unit, Virtiofs interfaces can be installed on both the Guest and Host sides, enabling data communication between the Host and Guest. In some embodiments, other methods can be used to manage the data communication instead of the semi-virtualization unit, such as using PMEM shared memory.

[0039] The semi-virtualized unit supports Direct Access eXciting (DAX) technology. This DAX technology allows for read and write operations via file mapping, reducing the need for additional copying.

[0040] The Host stores the container image data required to load the container and the corresponding metadata in an image format. The metadata is stored in a first file within the Host. In some implementations, the image format is the Nydus image format.

[0041] The term "container" refers to a technology that packages an application and its dependencies together. This technology can package the complete runtime environment, the application, and all its required dependencies, libraries, other binaries, configuration files, etc., into container image data. This container image data is typically stored on the host machine. For example, the host machine can obtain the container image archive from the cloud or other storage media, then decompress it into container image data and store it in memory or external storage (e.g., hard drive).

[0042] It should be noted that this application relates to a secure container scenario. The secure container refers to a technology that runs containers within a virtual machine (Guest), which increases the isolation between the host and the container, ensuring that the host is not affected by malicious containers and guaranteeing the host's security.

[0043] Container loading refers to the preparation process before running a container in the Guest. Container loading requires establishing a channel between the Guest and the Host to access the container image data. In other words, the Guest must be able to access the container image data. This allows the container to be run based on the container image data.

[0044] Container image data can include various formats. The difference between this application and related technologies lies in the fact that the image format used in this application allows the metadata of the image data to be centrally stored in the first file. In some embodiments, this application uses the Nydus image format.

[0045] The Nydus image format is an optimized container image format. Specifically, the Nydus image format optimizes the existing OCI image standard format and uses it to design a file system stored on the host. This file system may include a first file and a second file. The first file stores metadata corresponding to multiple container image data required to load the container, and the second file stores multiple container image data required to load the container. In some embodiments, the first file is a bootstrap type file, and the second file is a blob type file. This allows the guest to directly parse the container image content using the bootstrap type file and the blob type file.

[0046] This allows for the aggregation and organization of metadata from multiple container image data sets, making it easy to determine the file directory structure and storage location of multiple container image data sets by querying and parsing the first file.

[0047] like Figure 1 As shown, the method may include steps S102-S106. Unless otherwise specified, this application does not specifically limit the order in which these steps are performed.

[0048] In step S102, in response to the loading requirement for the container, a first access request for direct access to the first file is sent to the semi-virtualization unit, so that the semi-virtualization unit maps the first file to the Guest in response to the first access request.

[0049] The loading requirement can be triggered periodically, either after certain conditions are met or by the user.

[0050] The first access request may follow a communication protocol agreed upon between the Host and the Guest. In some embodiments, the protocol is the FUSE protocol. In this step, a DAX request (first access request) may be generated based on the FUSE protocol.

[0051] The FUSE protocol is a file system protocol supported by the semi-virtualization unit. The guest can generate a first access request based on the FUSE protocol and send it to the host through the semi-virtualization unit.

[0052] The semi-virtualization unit can be a Virtiofs unit or a blobfs unit. The Guest can send the first access request through the interface exposed by the semi-virtualization unit.

[0053] The semi-virtualization unit supports DAX, meaning that the unit can obtain the first file and complete the mapping.

[0054] The mapping (mmap) refers to the mapping of file addresses. In some methods, the first address where the first file is stored in the Host can be transformed to obtain a second address, which is an address that the Guest can directly access, thus completing the file mapping. For example, the second address may be the virtual memory address corresponding to the Guest. The Guest can then directly access the first file in virtual memory through the second address.

[0055] Please see Figure 2 , Figure 2 This is a comparative diagram of DAX and Read shown in an embodiment of this application. Figure 2 The left side shows the data access process for Read. Figure 2 The right side shows the DAX data access process.

[0056] In the Read data access process, the Guest can initiate a Read request for the data to be accessed (such as any container image data) based on the FUSE protocol, and then send the Read request to Virtiofs. Virtiofs can respond to the Read request, find the data to be accessed in the Host's kernel Page Cache, and copy the data to the Guest's kernel Page Cache using memcpy. This means that the data to be accessed is transferred during the Read access process, resulting in relatively low access efficiency.

[0057] In the DAX data access process, the Guest can initiate a DAX request for the data to be accessed (such as any container image data) based on the FUSE protocol, and then send the DAX request to Virtiofs. Virtiofs can respond to the DAX request, find the data to be accessed in the Host's kernel Page Cache, and mmap (map) the data to be accessed into the Guest's kernel Page Cache. That is, the data to be accessed is not transferred during the DAX access process; only mapping is completed, which can improve access efficiency and avoid wasting CPU.

[0058] In some embodiments, before executing S102, the Host can pass the image directory of the first file to the Guest through the semi-virtualization unit. On the Guest side, the method further includes receiving the image directory passed through the semi-virtualization unit.

[0059] The mirror directory can indicate the storage location of the first file in the host.

[0060] In S102, the Guest can respond to the loading requirements of the container by generating a first access request for direct access to the first file based on the obtained image directory; then the first access request can be sent to the semi-virtualization unit, so that the semi-virtualization unit responds to the first access request by obtaining the first file from the storage location indicated by the image directory and mapping the first file to the Guest.

[0061] S104, query the first file that is mapped, obtain the metadata corresponding to the container image data to determine the storage location of the container image data.

[0062] In step S102, the first file is mapped to the Guest. This means the Guest can directly access the first file locally.

[0063] The first file contains metadata for multiple container image data required to load the container.

[0064] The metadata, also known as intermediary data or relay data, is data about data. It mainly describes the properties of the data and is used to support functions such as indicating storage location, historical data, resource lookup, and file records.

[0065] By parsing the metadata, the Guest can obtain the directory structure of the file system corresponding to multiple container image data, and determine the storage location of each container image data.

[0066] S106, based on the storage location indicated by the metadata, access the container image data stored in the Host to complete the loading of the container.

[0067] After determining the storage location of each container image data in S106, an access request can be constructed to access the container image data stored in the Host, thereby completing the loading of the container. In some methods, file access can also be completed through a DAX access request, thus utilizing DAX's file mapping technology to improve file access efficiency without copying file content, thereby improving file loading efficiency.

[0068] In the aforementioned scheme described in S102-S106, the first file containing the metadata of the image data is mapped to the Guest through the direct access technology of the semi-virtualized device. This allows the Guest to traverse the metadata directly in the Guest without trapping out of the Host during the file lookup process, and then complete file access and container loading through the metadata. Compared with related technologies, this reduces the number of times the Host is accessed, reduces the number of trapping and reading operations, reduces CPU consumption, and improves container loading efficiency.

[0069] In some embodiments, the Host stores at least two container image data. In order to further improve the container loading efficiency, loading a container requires accessing the container image data at least twice, and each time only the container image data that needs to be accessed is accessed.

[0070] Specifically, in S104, the first file can be queried to obtain the target metadata corresponding to at least one target container image data that needs to be accessed to determine the target storage location of the at least one target container image data.

[0071] The logic code for loading the container pre-defined at least one target container image data that needs to be accessed each time. The Guest can determine the target storage location of the at least one target container image data based on the first file using a lookup operation.

[0072] Then in S106, the at least one target container image data stored in the Host can be accessed based on the target storage location indicated by the target metadata.

[0073] In some embodiments, the target container image data can be accessed via DAX. See also... Figure 3 , Figure 3 This is a schematic flowchart illustrating a method for accessing target container image data, as shown in an embodiment of this application. Figure 3 The method described may include steps S302-S306. Unless otherwise specified, this application does not specifically limit the order in which these steps are performed.

[0074] S302, based on the target storage location indicated by the target metadata, generate a second access request for direct access to the at least one target container image data.

[0075] In some methods, the target storage location can be obtained by analyzing the metadata, and then the target storage location can be packaged into the second access request.

[0076] The second access request may follow the communication protocol agreed upon between the Host and the Guest. In some embodiments, the protocol is the FUSE protocol. In this step, the second access request (DAX request) may be generated based on the FUSE protocol.

[0077] S304, the second access request is sent to the semi-virtualization unit so that the semi-virtualization unit responds to the second access request by mapping the at least one target container image data stored in the Host to the Guest.

[0078] For an explanation of S304, please refer to the explanation of S102. Further details will not be provided here.

[0079] S306, query the mapped at least one target container image data to complete access to the target container image data.

[0080] In this step, the Guest can directly query the at least one target container image data locally to complete access to the target container image data.

[0081] Through S302-S306, target container image data can be accessed via DAX, thereby utilizing DAX's file mapping technology to improve file access efficiency without copying file content, and thus improve file loading efficiency.

[0082] In some embodiments, the container image data is stored in a second file in the Host. The at least one target container image data described in the preceding embodiments is continuously stored in the second file in the Host. In S304, the at least one target container image data continuously stored in the second file can be mapped to the Guest step. This allows direct access to multiple target container image data sets at once.

[0083] Since the container image data is continuously stored in the second file included in the Host, more than one target container image data can be accessed in a single DAX direct access. Compared with ordinary container image data that does not use the image format (which can only access one target container image data at a time), this improves mapping efficiency and thus improves image loading efficiency.

[0084] In some embodiments, the data size of at least one target container image data described in the preceding embodiments does not exceed the maximum preset data size for a single direct access.

[0085] The maximum preset data size refers to the maximum amount of data allowed in a single direct access. In some embodiments, the amount of data allowed in a single direct access is 2MB, meaning that the size of the data of the at least one target container image should not exceed 2MB. This ensures that multiple target container image data can be accessed at once, while also preventing files from becoming inaccessible due to exceeding the access limit, thus avoiding abnormal container loading.

[0086] The following examples illustrate the implementation of Kata's secure container scenario.

[0087] Kata is a secure container technology based on Qemu. Qemu is a hypervisor.

[0088] Please see Figure 4 , Figure 4 This is a schematic diagram illustrating a scenario of loading a Kata container, as shown in an embodiment of this application.

[0089] Figure 4 In the host user space, the Qemu program is installed for managing virtual machines. Qemu includes bolbfs, which supports Nydus images.

[0090] Qemu manages Figure 4 The Guest instance is a ROM-based container. Its kernel also runs bolbfs, which enables data transfer between the Host and Guest. The Guest instance uses EROFS (Extendable Read-Only File System), which parses blob and bootstrap files to obtain image data. The Guest instance then loads the Kata container based on the obtained image data.

[0091] When there is a need for secure container operation, Qemu can obtain the Nydus image corresponding to the Kata container from remote storage (such as the cloud) in a peer-to-peer manner, and store the Nydus image in the kernel (such as the hard drive) of the host.

[0092] The Nydus image corresponds to a blob type file and a bootstrap type file. The blob type file stores multiple image data required to load the Kata container, and the bootstrap type file stores the metadata corresponding to each of the multiple image data.

[0093] Please see Figure 5 , Figure 5 This is a flowchart illustrating a method for loading a container, as shown in an embodiment of this application. Figure 5 In response to Figure 4 Description of the loading container method flow for the scenario.

[0094] S501, the Host downloads the Nydus image corresponding to the Kata container from remote storage via Qemu and stores the Nydus image on the hard disk.

[0095] In this step, the host can download the Nydus image from a remote location using peer-to-peer transmission technology. The Nydus image contains both blob and bootstrap type files.

[0096] S502, send the image directory corresponding to the Nydus image to bolbfs.

[0097] In this step, the image directory can be generated based on the storage address of the Nydus image, and the image directory can be sent to bolbfs.

[0098] S503, bolbfs passes the mirror directory to the Guest.

[0099] This application does not limit the technical means used for passthrough.

[0100] S504, the Guest initiates a first DAX request for a bootstrap type file based on the mirror directory, and sends the first DAX request to the Host for use by bolbfs.

[0101] The Guest mentioned in this step can generate a first DAX request based on the mirror directory via the FUSE protocol, and send the first DAX request to bolbfs through the interface exposed by bolbfs in Qemu.

[0102] S505, in response to the first DAX request, the bolbfs finds the bootstrap type file from the Host based on the image directory, maps the bootstrap type file to the memory space corresponding to Qemu, and then maps the bootstrap type file in the memory space to the Guest.

[0103] The mapping can be completed using mmap in this step.

[0104] In this example, loading the Kata container requires multiple accesses to the image data. The following explanation uses a single access as an example.

[0105] S506, Guest queries the mapped bootstrap type file to determine the file system directory structure corresponding to the Nydus image, and determines the storage address of the multiple target image data that need to be accessed based on the directory structure.

[0106] The multiple target image data are stored contiguously in blob type files, and the file size does not exceed the maximum amount of data allowed in a single DAX access (e.g., 2MB).

[0107] In this step, the Guest can query the bootstrap type file to obtain the metadata of multiple target image data, and then obtain the storage address of multiple target image data by analyzing the metadata.

[0108] S507, Guest generates a second DAX access request based on the storage addresses of multiple target image data and the FUSE protocol, and sends the second DAX access request to the bolbfs.

[0109] S508, in response to the second DAX access request, the bolbfs finds the target blob type file of the target image data from the Host based on the storage address of the target image data, and finds the target image data in the target blob type file, and then can map the target image data to the Guest.

[0110] In this step, the mapping can be performed using mmap. It's important to note that the mapped target image data is still saved as blob files.

[0111] S509, Guest can directly query the image data of multiple mapped targets.

[0112] In this step, the Guest can directly query the target blob type file that is being mapped, and use the built-in EROFS to parse the target blob type file to obtain multiple target image data.

[0113] The Kata container can be loaded successfully by executing steps S506-S509 multiple times.

[0114] In the aforementioned solution, by storing the container image in Nydus image format and then using bolbfs direct access technology, a bootstrap type file containing the metadata of the image data is mapped to the Guest. This allows the Guest to directly traverse the metadata within the Guest during the file lookup process without trapping out of the Host, and then complete file access and container loading through the metadata. Compared with related technologies, this reduces the number of times the Host is accessed, the number of traps and reads, and the CPU consumption, thereby improving container loading efficiency.

[0115] Corresponding to the foregoing embodiments, this application also proposes a container loading method, applied to a semi-virtualization unit mounted on a host, wherein the host corresponds to a virtual client (Guest); the host and the guest communicate through the semi-virtualization unit; the host stores container image data required for loading the container and metadata corresponding to the container image data in image format; wherein the metadata is stored in a first file in the host;

[0116] The method may include:

[0117] Receive the first access request sent by the Guest in response to the loading requirement of the container; the first access request is for direct access to the first file;

[0118] In response to the first access request, the first file is mapped to the Guest, so that the Guest queries the mapped first file to obtain the metadata to determine the storage location of the container image data, and accesses the container image data stored in the Host based on the storage location indicated by the metadata, so as to complete the loading of the container.

[0119] In some embodiments, the Host stores at least two container image data, and loading a container requires at least two accesses to the container image data; the Guest queries the first file to obtain target metadata corresponding to at least one target container image data required for the current access to determine the target storage location of the at least one target container image data; the method further includes: receiving a second access request initiated by the Guest; the second access request is generated based on the target storage location indicated by the target metadata; in response to the second access request, the at least one target container image data stored in the Host is mapped to the Guest, so that the Guest queries the mapped at least one target container image data to complete the access to the target container image data.

[0120] The description of the aforementioned method can be found in the preceding embodiments, and will not be detailed here.

[0121] In this method, the first file containing the metadata of the image data is mapped to the Guest through the direct access technology of the semi-virtualized device. This allows the Guest to traverse the metadata directly in the Guest without trapping out of the Host during the file lookup process. Then, the file access and container loading are completed through the metadata. Compared with related technologies, this method reduces the number of times the Host is accessed, the number of trapping and reading operations, and the CPU consumption, thereby improving the container loading efficiency.

[0122] Corresponding to any of the embodiments described above, this application also proposes a container loading device. The device can be applied to a virtual client (Guest), which corresponds to a host (Host). The host communicates with the guest via a semi-virtualized unit. The host stores container image data required for loading the container and metadata corresponding to the container image data in image format. The metadata is stored in a first file within the host.

[0123] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating the structure of a container loading device according to an embodiment of this application. Figure 6 As shown, the loading device 600 of the container may include:

[0124] The sending module 610, in response to the loading requirement for the container, sends a first access request for direct access to the first file to the semi-virtualization unit, so that the semi-virtualization unit, in response to the first access request, maps the first file to the Guest;

[0125] The query module 620 queries the mapped first file and obtains the metadata corresponding to the container image data to determine the storage location of the container image data;

[0126] The loading module 630 accesses the container image data stored in the Host based on the storage location indicated by the metadata, in order to complete the loading of the container.

[0127] In some embodiments, the Host stores at least two container image data, and loading a container requires accessing the container image data at least twice;

[0128] The query module 620 further includes:

[0129] Query the first file to obtain the target metadata corresponding to at least one target container image data that needs to be accessed to determine the target storage location of the at least one target container image data;

[0130] The loading module 630 further includes:

[0131] Based on the target storage location indicated by the target metadata, access the at least one target container image data stored in the Host.

[0132] In some embodiments, the loading module 630 further includes:

[0133] Based on the target storage location indicated by the target metadata, a second access request is generated to directly access the at least one target container image data;

[0134] The second access request is sent to the semi-virtualization unit, so that the semi-virtualization unit responds to the second access request by mapping the at least one target container image data stored in the Host to the Guest;

[0135] Query the mapped target container image data to complete access to the target container image data.

[0136] In some embodiments, the at least one target container image data is continuously stored in a second file in the Host;

[0137] The loading module 630 further includes:

[0138] Map at least one of the target container image data stored consecutively in the second file to the Guest.

[0139] In some embodiments, the data size of the at least one target container image data does not exceed the maximum preset data size for a single direct access.

[0140] In some embodiments, the device 600 further includes:

[0141] Before sending a first access request for direct access to the first file to the Host in response to the loading requirements of the container, the directory receiving module receives an image directory passed through the semi-virtualization unit; the image directory indicates the storage location of the first file in the Host.

[0142] The sending module 610 further includes:

[0143] In response to the loading requirement for the container, a first access request for direct access to the first file is generated based on the obtained image directory;

[0144] The first access request is sent to the semi-virtualization unit, so that the semi-virtualization unit responds to the first access request by calling the semi-virtualization unit to retrieve the first file from the storage location indicated by the image directory and map the first file to the Guest.

[0145] In some embodiments, the first access request and the second access request are DAX requests generated based on the FUSE protocol, and the semi-virtualization unit is a virtiofs unit or a blobfs unit.

[0146] In some embodiments, the image format includes the Nydus image format; the first file is a bootstrap type file, and the second file is a blob type file.

[0147] In the aforementioned solution, by using direct access technology of semi-virtualized devices, the first file containing the metadata of the image data is mapped to the Guest. This allows the Guest to traverse the metadata directly within the Guest during the file lookup process without having to trap out of the Host. Then, file access and container loading are completed through the metadata. Compared with related technologies, this reduces the number of times the Host is accessed, the number of traps and reads, and the CPU consumption is reduced, thus improving container loading efficiency.

[0148] This application also proposes a container loading apparatus. This apparatus is applied to a virtual client (Guest), which corresponds to a host (Host), and the host communicates with the guest via a semi-virtualization unit. The host stores container image data required for loading the container and metadata corresponding to the container image data in image format; wherein the metadata is stored in a first file within the host. The apparatus may include:

[0149] The first receiving module receives a first access request sent by the Guest in response to the loading requirement of the container; the first access request is used to directly access the first file.

[0150] The first mapping module, in response to the first access request, maps the first file to the Guest, so that the Guest queries the mapped first type to obtain the metadata to determine the storage location of the container image data, and accesses the container image data stored in the Host based on the storage location indicated by the metadata, so as to complete the loading of the container.

[0151] In some embodiments, the Host stores at least two container image data, and loading a container requires at least two accesses to the container image data; the Guest queries the first file to obtain the target metadata corresponding to at least one target container image data required for the current access to determine the target storage location of the at least one target container image data;

[0152] The device further includes:

[0153] The second receiving module receives the second access request initiated by the Guest; the second access request is generated based on the target storage location indicated by the target metadata;

[0154] The second mapping module, in response to the second access request, maps the at least one target container image data stored in the Host to the Guest, so that the Guest can query the mapped at least one target container image data to complete access to the target container image data.

[0155] The embodiments of the container loading device shown in this application can be applied to electronic devices. Accordingly, this application discloses an electronic device that may include a processor.

[0156] Memory used to store processor-executable instructions.

[0157] The processor is configured to invoke executable instructions stored in the memory to implement the container loading method shown in any of the foregoing embodiments.

[0158] Please see Figure 7 , Figure 7 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application.

[0159] like Figure 7 As shown, the electronic device may include a processor for executing instructions, a network interface for network connectivity, memory for storing operational data for the processor, and non-volatile memory for storing instructions corresponding to a loading device for a container.

[0160] The embodiments of the device can be implemented through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of its host electronic device reading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, besides... Figure 7In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device is located in the embodiment may also include other hardware depending on the actual function of the electronic device, which will not be described in detail here.

[0161] It is understandable that, in order to improve processing speed, the instructions for the container loading device can also be directly stored in memory, and this is not limited here.

[0162] This application proposes a computer-readable storage medium storing a computer program that can be used to cause a processor to execute the container loading method shown in any of the foregoing embodiments.

[0163] Those skilled in the art will understand that one or more embodiments of this application can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0164] In this application, “and / or” means having at least one of two options. For example, “A and / or B” can include three options: A, B, and “A and B”.

[0165] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the data processing device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0166] The specific embodiments of this application have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0167] The subject matter and functional implementations described in this application can be implemented as digital electronic circuits, tangibly embodied computer software or firmware, computer hardware that may include the structures disclosed in this application and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this application can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions loaded onto a tangible, non-transitory program carrier for execution by a data processing apparatus or to control the data processing apparatus. Alternatively or additionally, the program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0168] The processing and logic flow described in this application can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by loading input data and generating output. The processing and logic flow can also be executed by dedicated logic circuitry—such as FPGA (Field-Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit)—and the device can also be implemented as dedicated logic circuitry.

[0169] A computer suitable for executing computer programs may include, for example, a general-purpose and / or special-purpose microprocessor, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer may include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer may also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer may be loadably coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0170] Computer-readable media suitable for storing computer program instructions and data can include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROMs and DVD-ROMs. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0171] While this application contains numerous specific implementation details, these should not be construed as limiting the scope of any disclosure or the scope of the claims, but rather are primarily used to describe the features of specific embodiments of a particular disclosure. Certain features described in the multiple embodiments of this application may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation of a sub-combination.

[0172] Similarly, although loads are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these loads to be executed in the specific order shown or sequentially, or requiring all illustrated loads to be executed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the described embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0173] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0174] The above are merely preferred embodiments of one or more embodiments of this application and are not intended to limit the scope of one or more embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this application should be included within the scope of protection of one or more embodiments of this application.

Claims

1. A method for loading a container, applied to a virtual client (Guest), wherein the Guest corresponds to a host (Host), and the Host communicates with the Guest via a semi-virtualized unit; the Host stores container image data required for loading the container and metadata corresponding to the container image data in an image format; wherein, The container is a secure container that runs within the Guest and is isolated from the Host; The metadata is stored in the first file in the Host; The method includes: In response to the loading requirement for the container, a first access request for direct access to the first file is sent to the semi-virtualization unit, so that the semi-virtualization unit maps the first file to the Guest in response to the first access request; The first file that is mapped is queried to obtain the target metadata corresponding to at least one target container image data that needs to be accessed to determine the target storage location of the at least one target container image data; wherein, the at least one target container image data is continuously stored in the second file in the Host; Based on the target storage location indicated by the target metadata, a second access request is generated to directly access the at least one target container image data. The second access request is sent to the semi-virtualization unit so that the semi-virtualization unit responds to the second access request by mapping the at least one target container image data stored consecutively in the second file to the Guest. Query the mapped target container image data to complete the loading of the container.

2. The method according to claim 1, The step of mapping the at least one target container image data to the Guest includes: Map at least one of the target container image data stored consecutively in the second file to the Guest.

3. The method according to claim 2, wherein the data size of the at least one target container image data does not exceed the maximum preset data size for a single direct access.

4. The method of claim 1, further comprising, before sending a first access request for direct access to the first file to the Host in response to a loading requirement for the container: Receive the image directory passed through the semi-virtualization unit; The mirror directory indicates the storage location of the first file in the Host; In response to a loading request for the container, a first access request for direct access to the first file is sent to the semi-virtualization unit, so that the semi-virtualization unit, in response to the first access request, maps the first file to the Guest, including: In response to the loading requirement for the container, a first access request for direct access to the first file is generated based on the obtained image directory; The first access request is sent to the semi-virtualization unit, so that the semi-virtualization unit responds to the first access request by calling the semi-virtualization unit to retrieve the first file from the storage location indicated by the image directory and map the first file to the Guest.

5. The method according to claim 1, wherein the first access request and the second access request are DAX requests generated based on the FUSE protocol, and the semi-virtualization unit is a virtiofs unit or a blobfs unit.

6. The method according to claim 4, wherein the image format includes the Nydus image format; the first file is a bootstrap type file, and the second file is a blob type file.

7. A container loading method, applied to a semi-virtualization unit mounted on a host, wherein the host corresponds to a virtual client (Guest); the host and the guest communicate through the semi-virtualization unit; the host stores container image data required for loading the container and metadata corresponding to the container image data in image format; wherein, The metadata is stored in the first file in the Host; The method includes: Receive the first access request sent by the Guest in response to the loading requirement of the container; the first access request is for direct access to the first file; In response to the first access request, the first file is mapped to the Guest, so that the Guest queries the mapped first file to obtain the target metadata corresponding to at least one target container image data that needs to be accessed to determine the target storage location of the at least one target container image data, and generates a second access request for direct access to the at least one target container image data based on the target storage location indicated by the target metadata; wherein, the at least one target container image data is continuously stored in a second file in the Host; In response to the second access request sent by the Guest, the at least one target container image data stored consecutively in the second file is mapped to the Guest, so that the Guest can query the mapped at least one target container image data to complete the loading of the container.

8. A container loading device, applied to a virtual client (Guest), wherein the Guest corresponds to a host (Host), and the Host communicates with the Guest via a semi-virtualization unit; the Host stores container image data required for loading the container and metadata corresponding to the container image data in an image format; wherein, The container is a secure container that runs within the Guest and is isolated from the host; The metadata is stored in the first file in the Host; The device includes: The sending module, in response to the loading requirement for the container, sends a first access request for direct access to the first file to the semi-virtualization unit, so that the semi-virtualization unit, in response to the first access request, maps the first file to the Guest; The query module retrieves the target metadata corresponding to at least one target container image data that needs to be accessed to determine the target storage location of the at least one target container image data; wherein, the at least one target container image data is continuously stored in a second file in the Host; The loading module generates a second access request for direct access to the at least one target container image data based on the target storage location indicated by the target metadata, and sends the second access request to the semi-virtualization unit so that the semi-virtualization unit responds to the second access request by mapping the at least one target container image data stored consecutively in the second file to the Guest; and queries the mapped at least one target container image data to complete the loading of the container.

9. A container loading device, applied to a semi-virtualization unit mounted on a host, wherein the host corresponds to a virtual client (Guest); the host and the guest communicate through the semi-virtualization unit; the host stores container image data required for loading the container and metadata corresponding to the container image data in image format; wherein, The container is a secure container that runs within the Guest and is isolated from the host; The metadata is stored in the first file in the Host; The device includes: The first receiving module receives a first access request sent by the Guest in response to the loading requirement of the container; the first access request is used to directly access the first file. The first mapping module, in response to the first access request, maps the first file to the Guest, so that the Guest queries the mapped first file to obtain target metadata corresponding to at least one target container image data that needs to be accessed to determine the target storage location of the at least one target container image data, and generates a second access request for direct access to the at least one target container image data based on the target storage location indicated by the target metadata; wherein, the at least one target container image data is continuously stored in a second file in the Host; in response to the second access request sent by the Guest, the at least one target container image data continuously stored in the second file is mapped to the Guest, so that the Guest queries the mapped at least one target container image data to complete the loading of the container.

10. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the container loading method as described in any one of claims 1-7 by running the executable instructions.

11. A computer-readable storage medium storing a computer program for causing a processor to perform a loading method of a container as described in any one of claims 1-7.

Images