Resource mounting method and device of container, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides a resource mounting method and device of a container, electronic equipment and a readable storage medium. The method comprises the steps that when a virtual machine initialization process of a security container is operated, a resource management plug-in extracts mounting indication information from an environment variable of the security container; the resource management plug-in generates a resource mounting request according to the mounting indication information; and the resource management plug-in calls a resource management service to process the resource mounting request. As the resource management plug-in is arranged in the virtual machine initialization process of the security container, the resource management plug-in not only can access the path in the security container, but also can access the host machine and the path of the virtual machine, the resource on the host machine, the resource on the virtual machine and the resource of the external storage object can be mounted to the security container. In addition, the mounting indication information can be dynamically adjusted to mount different resources, and a dynamic resource mounting mode is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of virtualization, and in particular to a resource mounting method and device for a container, an electronic device, and a readable storage medium. BACKGROUND

[0002] In a multi-tenant cloud service scenario, computing power is provided by a cluster composed of multiple host machines, and one or more lightweight virtual machines run on each host machine. Each business container is run in an independent lightweight virtual machine to form a secure container running environment. The computing power cluster can access the VPC (Virtual Personal Cloud) resources of each tenant to form cross-multi-tenant network communication.

[0003] In the prior art, a secure container has a need to mount storage resources to access the mounted storage resources. Specifically, the storage resources can be mounted through the CSI (Container Storage Interface) or VI (Volume Inline) of the cluster.

[0004] However, in a multi-tenant cloud service scenario, the above mounting method cannot mount resources to the secure container. SUMMARY

[0005] The purpose of the embodiments of the present application is to provide a resource mounting method and device for a container, an electronic device, and a readable storage medium to mount storage resources to a secure container in a multi-tenant cloud service scenario. The specific technical solutions are as follows: In the first aspect of the present application, a resource mounting method for a container is provided, which comprises: When a virtual machine initialization process of a secure container is running, a resource management plug-in extracts mounting indication information from an environment variable of the secure container; the resource management plug-in generates a resource mounting request according to the mounting indication information; and the resource management plug-in calls a resource management service to process the resource mounting request.

[0006] Optionally, the resource management plug-in extracts the mounting indication information from the environment variable of the secure container, which comprises: The resource management plug-in extracts a resource mounting type from a first environment variable of the secure container; the resource management plug-in extracts a resource mounting parameter from a second environment variable corresponding to the resource mounting type, different resource mounting types corresponding to different second environment variables; and the resource management plug-in extracts a target mounting path from a third environment variable of the secure container.

[0007] Optionally, the resource management plug-in generates a resource mounting request according to the mounting indication information, and the resource mounting request comprises: The resource management plug-in encapsulates the resource mounting type into the header information of the resource mounting request, and encapsulates the resource mounting parameter and the target mounting path into the message body of the resource mounting request.

[0008] Optionally, the resource management plug-in calls a resource management service to process the resource mounting request, and the processing comprises: The resource management service extracts the resource mounting type from the header information of the resource mounting request, and calls a resource mounting interface corresponding to the resource mounting type to mount the resource corresponding to the resource mounting parameter to the target mounting path.

[0009] Optionally, the resource management service calls the resource mounting interface corresponding to the resource mounting type to mount the resource corresponding to the resource mounting parameter to the target mounting path, and the mounting comprises: The resource management service obtains a resource type set according to the container identifier of the secure container, and when the resource mounting type is in the resource type set, the resource management service calls the resource mounting interface corresponding to the resource mounting type to mount the resource corresponding to the resource mounting parameter to the target mounting path.

[0010] Optionally, the resource mounting type comprises at least one of the following: an object storage service, a file storage system, a block storage device, a virtual machine resource or a host resource; the resource mounting parameter corresponding to the object storage service comprises a path of the object storage service and bucket information; the resource mounting parameter corresponding to the file storage system comprises a server address, a file path and a file protocol version of the file storage system; the resource mounting parameter corresponding to the block storage device comprises a block identifier, a block size and a block type; the resource mounting parameter corresponding to the virtual machine resource comprises a path in a virtual machine where the secure container is located; and the resource mounting parameter corresponding to the host resource comprises a path in a host where the secure container is located.

[0011] Optionally, when the resource mounting type is the block storage device, the mounting of the resource corresponding to the resource mounting parameter to the target mounting path comprises: determining whether a block corresponding to the block identifier exists in the resource mounting parameter; when the block corresponding to the block identifier does not exist, creating a block storage device according to the block identifier, the block size and the block type, and formatting the block storage device into a file system to mount the block storage device to the target mounting path; when the block corresponding to the block identifier exists, binding the block storage device to the virtual machine and mounting the block storage device to the target mounting path.

[0012] Optionally, the path in the virtual machine where the security container is located comprises a path for storing running indexes of a business container, and the target mounting path comprises a path in a system container of the security container.

[0013] Optionally, when the resource mounting type is a host resource, mounting the resource corresponding to the resource mounting parameter to the target mounting path comprises: splitting the path in the host into a top path of the host and a business sub-path; mounting the top path to a first path in a system container; and mounting a path composed of the first path in the system container and the business sub-path to the target mounting path.

[0014] Optionally, before the resource management plug-in in the virtual machine initialization process of the security container intercepts a security container creation request, the method further comprises: when the virtual machine initialization process of the security container receives a container creation request, extracting a resource management mode from an annotation of the security container; and when the resource management mode indicates dynamic resource management, running the resource management plug-in.

[0015] Optionally, the method further comprises: when the resource management mode indicates static resource management, mounting a default source path to a default target path.

[0016] In a second aspect of the embodiments of the present application, a container resource mounting device is further provided, comprising: an information extraction module configured to extract mounting indication information from an environment variable of a security container through a resource management plug-in when a virtual machine initialization process of the security container is running.

[0017] a request generation module configured to generate a resource mounting request according to the mounting indication information through the resource management plug-in.

[0018] a mounting processing module configured to process the resource mounting request by calling a resource management service through the resource management plug-in.

[0019] Optionally, the information extraction module is further configured to: extracting, by the resource management plug-in, a resource mounting type from a first environment variable of the secure container; extracting, by the resource management plug-in, a resource mounting parameter from a second environment variable corresponding to the resource mounting type, different resource mounting types corresponding to different second environment variables; extracting, by the resource management plug-in, a target mounting path from a third environment variable of the secure container.

[0020] Optionally, the request generation module is further configured to: encapsulating, by the resource management plug-in, the resource mounting type into header information of the resource mounting request; and encapsulating, by the resource management plug-in, the resource mounting parameter and the target mounting path into a message body of the resource mounting request.

[0021] Optionally, the mounting processing module is further configured to: extracting, by the resource management service, the resource mounting type from the header information of the resource mounting request; and calling, by the resource management service, a resource mounting interface corresponding to the resource mounting type to mount a resource corresponding to the resource mounting parameter into the target mounting path.

[0022] Optionally, the mounting processing module is further configured to: obtaining, by the resource management service, a resource type set according to a container identifier of the secure container; and when the resource mounting type is in the resource type set, calling, by the resource management service, a resource mounting interface corresponding to the resource mounting type to mount a resource corresponding to the resource mounting parameter into the target mounting path.

[0023] Optionally, the resource mounting type comprises at least one of the following: an object storage service, a file storage system, a block storage device, a virtual machine resource, or a host resource; the resource mounting parameter corresponding to the object storage service comprises a path of the object storage service and bucket information; the resource mounting parameter corresponding to the file storage system comprises a server address of the file storage system, a file path, and a file protocol version; the resource mounting parameter corresponding to the block storage device comprises a block identifier, a block size, and a block model number; the resource mounting parameter corresponding to the virtual machine resource comprises a path in a virtual machine where the secure container is located; and the resource mounting parameter corresponding to the host resource comprises a path in a host where the secure container is located.

[0024] Optionally, when the resource mounting type is the block storage device, the mounting processing module is further configured to: determining whether a block corresponding to the block identifier exists in the resource mounting parameter; when the block corresponding to the block identifier does not exist, creating a block storage device according to the block identifier, the block size and the block type, and formatting the block storage device into a file system to mount the block storage device into the target mounting path; when the block corresponding to the block identifier exists, binding the block storage device to the virtual machine and mounting the block storage device into the target mounting path.

[0025] Optionally, the path in the virtual machine where the security container is located comprises a path for storing running indexes of a business container, and the target mounting path comprises a path in a system container of the security container.

[0026] Optionally, when the resource mounting type is a host resource, the mounting processing module is further configured to: split the path in the host into a top path of the host and a business sub-path, mount the top path into a first path in the system container, and mount the path composed of the first path in the system container and the business sub-path into the target mounting path.

[0027] Optionally, the method further comprises: a plug-in running module configured to extract a resource management mode from an annotation of the security container through a virtual machine initialization process of the security container when receiving a container creation request, and run the resource management plug-in when the resource management mode indicates dynamic resource management.

[0028] Optionally, the mounting processing module is further configured to: mount a default source path into a default target path when the resource management mode indicates static resource management.

[0029] In a third aspect of the embodiments of the present application, an electronic device is further provided, which comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; the memory is used for storing a computer program; and the processor is used for executing the program stored in the memory to implement the method in the first aspect.

[0030] In a fourth aspect of the embodiments of the present application, a computer readable storage medium is further provided, which stores instructions, and when the instructions are run on a computer, the computer executes the method in the first aspect.

[0031] In a fifth aspect of the embodiments of the present application, a computer program product containing instructions is further provided, and when the instructions are run on a computer, the computer executes the method in the first aspect.

[0032] The container resource mounting method, device, electronic device and readable storage medium provided by the embodiments of the present application can extract mounting indication information from the environment variable of the secure container by the resource management plug-in when the virtual machine initialization process of the secure container is running; the resource management plug-in generates a resource mounting request according to the mounting indication information; and the resource management plug-in calls the resource management service to process the resource mounting request. Since the resource management plug-in is laid in the virtual machine initialization process of the secure container, it can not only access the path in the secure container, but also access the path of the host and the virtual machine, so it can mount the resources on the host, the resources on the virtual machine and the resources of the external storage object to the secure container. In addition, the mounting indication information can be dynamically adjusted for different resource mounting, and a dynamic resource mounting mode is realized. BRIEF DESCRIPTION OF DRAWINGS

[0033] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows.

[0034] Figure 1 An application scenario of the embodiments of the present application; Figure 2 An internal schematic diagram of a secure container in the embodiments of the present application; Figure 3 A step flowchart of a container resource mounting method in the embodiments of the present application; Figure 4 A flowchart of another container resource mounting method in the embodiments of the present application; Figure 5 A structural schematic diagram of a container resource mounting device in the embodiments of the present application; Figure 6 A schematic diagram of an electronic device in the embodiments of the present application. DETAILED DESCRIPTION

[0035] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0036] The embodiment of the present application is applied to a multi-tenant cloud service scenario. In the multi-tenant cloud service scenario, a cloud service platform provides a cluster to support computing power sharing of multiple tenants. The cluster can be a Kubernetes cluster, which includes one or more host computers, one or more virtual machines running on each host computer, one or more secure containers running on each virtual machine, and each secure container including a system container and one or more business containers sharing resources. One or more business containers correspond to one tenant. The system container is used to run an operating system.

[0037] Figure 1 is a schematic diagram of a multi-tenant cloud service scenario of the embodiment of the present application. Referring to Figure 1 , the cluster includes host computers H1 and H2, three virtual machines VM1, VM2 and VM3 running on the host computer H1, two secure containers SC1 and SC2 running on the virtual machine VM1, the secure container SC1 including a system container and three business containers UC1, UC2 and UC3, and the three business containers corresponding to three tenants respectively.

[0038] It can be seen that isolation is achieved between different virtual machines and between different secure containers, and resource sharing is achieved within the same secure container.

[0039] When mounting a storage resource through CSI or VI, a component depends on a host computer. However, in the multi-tenant cloud service scenario, the network of the host computer is different from the network of the secure container, and the component on the host computer cannot access the path in the secure container. Therefore, the storage resource cannot be mounted into the secure container through CSI or VI.

[0040] In order to mount a storage resource to a secure container in the multi-tenant cloud service scenario, the embodiment of the present application considers that a resource management plug-in (which can be referred to as resource-hook-plugin) is arranged in the virtual machine initialization process in the secure container, so as to call a resource management service (which can be referred to as resource-hook-server) to mount a storage resource according to mounting instruction information in an environment variable in the process of creating the secure container. Since the resource management plug-in is arranged in the virtual machine initialization process in the secure container, it can not only access the path in the secure container, but also access the paths of the host computer and the virtual machine where it is located. Therefore, the host computer resource, the virtual machine resource and the resource of an external storage object can be mounted to the secure container. In addition, the mounting instruction information can be dynamically adjusted to mount different resources, so as to realize a dynamic resource mounting mode.

[0041] The resource mounting method of the container of the present application will be described in detail through specific embodiments.

[0042] Nomenclature: Virtual machine initialization process: a process of a secure container runtime, used to initialize a virtual machine environment, the virtual machine initialization process includes a life cycle management phase of the secure container, for example, creating a secure container, deleting a secure container, etc.

[0043] Resource management plug-in: a plug-in for managing storage resources, integrated in an extensible manner in the virtual machine initialization process, the resource management plug-in is a plug-in tool.

[0044] Resource management service: used for resource mounting processing according to the resource mounting request of the resource management plug-in, the resource management service can provide multiple resource management interfaces, and different resource management interfaces perform mounting processing on different resource mounting types.

[0045] Container creation request: used to request to create a secure container, which can include related parameters of the secure container.

[0046] Resource management mode: used to indicate a mounting mode of a storage resource, including: dynamic resource management and static resource management.

[0047] Dynamic resource management: used to indicate mounting a storage resource according to mounting indication information.

[0048] Static resource management: used to mount a default source path to a default target path.

[0049] Mounting indication information: information required for storage resource mounting, including but not limited to: resource mounting type, resource mounting parameter, and target mounting path.

[0050] Resource mounting type: used to indicate the type of mounted storage resource, the resource mounting type includes at least one of the following: object storage service, file storage system, block storage device, virtual machine resource, or host machine resource. Object storage service: stores data through objects; file storage system: stores data through files; block storage device: stores data through data blocks; virtual machine resource: a path on a virtual machine; host machine resource: a path on a host machine.

[0051] Resource mounting parameter: related parameters of the mounted storage resource, different resource mounting types correspond to different resource mounting parameters. The resource mounting parameters corresponding to the object storage service include: the path of the object storage service, bucket information; the resource mounting parameters corresponding to the file storage system include: the server address of the file storage system, the file path, the file protocol version; the resource mounting parameters corresponding to the block storage device include: the block identifier, the block size, the block type; the resource mounting parameters corresponding to the virtual machine resource include: a path in a virtual machine where the secure container is located; the resource mounting parameters corresponding to the host machine resource include: a path in a host machine where the secure container is located.

[0052] Target mounting path: the target path where the storage resource is mounted, for example, it can be a path in the business container or a path in the system container.

[0053] Referring to Figure 2 As shown in FIG. 1, a structure schematic diagram of a secure container provided by an embodiment of the present application is shown, the secure container includes an intermediate component and a virtual machine kernel, a business container, a system container, a virtual machine initialization process and a resource mounting service are located in the virtual machine kernel, and a resource management plug-in is set in the virtual machine initialization process. The intermediate component contained-shim is used to isolate and manage container processes.

[0054] Figure 3 As shown in FIG. 2, a step flowchart of a resource mounting method of a container provided by an embodiment of the present application is shown, the method can include: Figure 3 S101, when running a virtual machine initialization process of a secure container, a resource management plug-in extracts mounting instruction information from environment variables of the secure container.

[0055] S102, the resource management plug-in generates a resource mounting request according to the mounting instruction information.

[0056] S103, the resource management plug-in calls a resource management service to process the resource mounting request.

[0057] In the process of running the virtual machine initialization process, the resource management plug-in can be called to perform dynamic mounting of storage resources, and there can be two implementation manners.

[0058] In the first implementation manner, for all secure containers, the resource management plug-in is called to perform dynamic mounting of storage resources when running the virtual machine initialization process thereof.

[0059] In the second implementation manner, the resource management plug-in is called to perform dynamic mounting of storage resources for part of the secure containers. Specifically, the resource management plug-in in the virtual machine initialization process of the secure container intercepts a secure container creation request, and further includes: When the virtual machine initialization process of the secure container receives a container creation request, the resource management mode of the secure container is extracted from an annotation of the secure container; when the resource management mode indicates dynamic resource management, the resource management plug-in is run; and when the resource management mode indicates static resource management, a default source path is mounted into a default target path.

[0060] The above resource management mode can have two values true and false, true indicates dynamic resource management, and false indicates static resource management. The embodiment of the present application can flexibly control the resource management mode according to the annotation, and the flexibility is improved.

[0061] ​The above annotations can also be dynamically configured. For example, they can differentiate between time periods, virtual machine performance parameters, and container parameters to intelligently set different resource management modes for different time periods, different virtual machines, and different security containers.

[0062] When the resource management mode is dynamic resource management, the virtual machine initialization process calls the resource management plugin to implement dynamic resource management. Specifically, the resource management plugin needs to extract mount instruction information from the environment variables of the secure container. The mount instruction information includes one or more sub-information, which can be located in the same or different environment variables.

[0063] In one implementation, the environment variable containing the resource mount type is called the first environment variable, the environment variable containing the resource mount parameters is called the second environment variable, and the environment variable containing the target mount path is called the third environment variable. Thus, the resource management plugin extracts mount instruction information from the environment variables of the secure container, including: The resource management plugin extracts the resource mount type from the first environment variable of the secure container; the resource management plugin extracts the resource mount parameters from the second environment variable corresponding to the resource mount type, with different second environment variables corresponding to different resource mount types; the resource management plugin extracts the target mount path from the third environment variable of the secure container.

[0064] As can be seen, the second environment variable differs for different resource mount types. For example, when the resource mount type RESOURCE_TYPE is OSS (Object Storage Service), the second environment variable is OSS; when the resource mount type RESOURCE_TYPE is NFS (Network File System), the second environment variable is NFS; when the resource mount type RESOURCE_TYPE is Block, the second environment variable is BLOCK; when the resource mount type RESOURCE_TYPE is GUEST, the second environment variable is GUEST; and when the resource mount type RESOURCE_TYPE is HOST, the second environment variable is HOST.

[0065] Understandably, traditional solutions store all resource mount parameters in the same storage address. However, this application stores resource mount parameters for different resource mount types in different second environment variables. This allows access to only the corresponding second environment variable based on the first environment variable, reducing the number of addresses traversed and improving the efficiency of obtaining resource mount parameters, thereby increasing mount efficiency.

[0066] Upon obtaining the resource mount type, resource mount parameters, and target mount path, a resource mount request can be generated based on these three factors. Specifically, the resource management plugin generates a resource mount request based on the mount instruction information, including: The resource management plugin encapsulates the resource mount type into the header information of the resource mount request; the resource management plugin also encapsulates the resource mount parameters and the target mount path into the message body of the resource mount request.

[0067] The resource mounting request here can be an HTTP (Hypertext Transfer Protocol) request, used for communication between the resource management plugin and the resource management service. The resource mounting type is located in its header, allowing the resource management service to parse the resource mounting type upon receiving the request and invoke the corresponding resource mounting interface. Specifically, the resource management plugin calls the resource management service to process the resource mounting request, including: The resource management service extracts the resource mount type from the header information of the resource mount request; the resource management service calls the resource mount interface corresponding to the resource mount type to mount the resource corresponding to the resource mount parameters to the target mount path.

[0068] After obtaining the resource mount type, the resource management service can determine the corresponding resource mount interface based on the mount type. Different resource mount types correspond to different resource mount interfaces. The mapping relationship between the two can be represented by an identifier or a mapping table. Representation by an identifier means that the resource mount interface and the resource mount type contain the same string; representation by a mapping table means a list of resource mount types and resource mount interfaces that correspond one-to-one.

[0069] There are two approaches to calling the resource mounting interface. In the first approach, the resource management service can extract the resource mounting parameters from the body of the resource mounting request and pass them to the resource mounting interface for resource mounting. In the second approach, the resource management service can also pass the entire resource mounting request to the resource mounting interface, so that the resource mounting interface can extract the resource mounting parameters from the body of the resource mounting request and perform resource mounting.

[0070] It's understandable that different resource mounting interfaces have different mounting logic. Setting up different resource mounting interfaces for different resource mounting types facilitates modular code management and reduces code maintenance complexity.

[0071] In some possible implementations, a resource type set can be set for a secure container to restrict the types of resource mounts that the secure container can use. The resource type set of a secure container includes one or more usable resource types, which are the resource mount types that the secure container can use. A secure container can only use the usable resource types in its corresponding resource type set and cannot use resource mount types outside of its corresponding resource type set. Different secure containers can correspond to the same or different resource type sets. For example, such as... Figure 1 The security containers SC1 and SC2 are shown. SC1 corresponds to resource type sets that can include object storage services, file storage systems, and block storage devices, while SC2 corresponds to resource type sets that can include virtual machine resources and host machine resources. Different security containers may include one or more of the same usable resource types, or they may be completely different. Based on these resource type sets, the resource management service calls the resource mount interface corresponding to the resource mount type to mount the resource corresponding to the resource mount parameters to the target mount path, including: The resource management service obtains the resource type set based on the container identifier of the secure container; when the resource mount type is in the resource type set, the resource management service calls the resource mount interface corresponding to the resource mount type to mount the resource corresponding to the resource mount parameters to the target mount path.

[0072] Thus, each container identifier corresponds to a set of resource types. When the virtual machine initialization process of running secure container SC1 is in progress, the resource management service corresponding to secure container SC1 obtains the resource type set of secure container SC1 based on the container identifier of secure container SC1; when the virtual machine initialization process of running secure container SC2 is in progress, the resource management service corresponding to secure container SC2 obtains the resource type set of secure container SC2 based on the container identifier of secure container SC2.

[0073] The resource management service of a secure container can perform resource mounting when the resource mount type is in the resource type set, but cannot perform resource mounting when the resource mount type is not in the resource type set.

[0074] Of course, when a resource management service fails to mount a resource, it can generate failure indication information, including but not limited to: a first message indicating that the resource mounting interface corresponding to the resource mounting type does not exist; a second message indicating that the resource is abnormal; and a third message indicating that the resource mounting type is not supported. This allows for analysis of the reasons for mounting failure based on the failure indication information, thereby improving the success rate of subsequent mountings. For example, upon receiving the first message, the resource mounting interface corresponding to the resource mounting type can be added; upon receiving the second message, the resource can be restarted or repaired to try and mount it successfully again; upon receiving the third message, the resource type set of the secure container can be analyzed to determine whether a resource mounting type needs to be added to it.

[0075] It is understandable that the mounting process differs depending on the resource mounting type. The following details the specific mounting process of the resource mounting interface when the resource mounting types are object storage services, file storage systems, block storage devices, host resources, and virtual machine resources.

[0076] When the resource mount type is object storage service, the resource mount interface mounts the object storage service indicated by the URL (Uniform Resource Locator) path and bucket information carried in the body message of the resource mount request to the target mount path. The target mount path can be the root path (rootfs path) of the business container plus a sub-path within the business container. This achieves the mounting of the object storage service to a sub-path within the business container within the security container.

[0077] When the resource mount type is a file storage system, the resource mount interface mounts the file storage system indicated by the server address, file path, and file protocol version carried in the body of the resource mount request to the target mount path. Specifically, the file storage system can be mounted using the `mount -tnfs` command. The target mount path here can be similar to the object storage service mentioned above.

[0078] When the resource mount type is block storage device, the resource corresponding to the resource mount parameters is mounted to the target mount path, including: Determine if a corresponding block exists in the block identifier in the resource mount parameters; if no corresponding block storage device exists for the block identifier, create a block storage device based on the block identifier, block size, and block model, and format the block storage device as a file system to mount the block storage device to the target mount path; if a corresponding block storage device exists for the block identifier, bind the block storage device to the virtual machine and mount the block storage device to the target mount path.

[0079] Understandably, when a block identifier already exists with a corresponding block storage device, it means the block storage device to be mounted has been created and can be mounted directly. When a block identifier does not exist with a corresponding block storage device, it means the block storage device to be mounted has not been created and needs to be created first based on the block identifier, block size, and block type. The file system here can be an extended file system, such as ext2, ext3, or ext4.

[0080] The determination of the above block identifier can be implemented by the cloud API (Application Program Interface).

[0081] The embodiments of this application can mount the block storage device in both cases where the block storage device is present or absent, which helps to improve the mounting success rate.

[0082] When the resource mount type is a virtual machine resource, the resource mount interface mounts the path within the virtual machine where the security container resides, carried in the main body of the resource mount request, to the target mount path. In one scenario, the path within the virtual machine where the security container resides includes: a path used to store the runtime metrics of the business container, and the target mount path includes a path within the system container of the security container.

[0083] The path to the runtime metrics of the business containers is related to the specific application scenario. They are usually located in virtual machines. For example, the / sys / fs / cgroup path in a virtual machine is used to store the runtime metrics of the business containers in the virtual machine.

[0084] In conventional technologies, monitoring components on the host machine can monitor the operational metrics of a Pod (container group), but cannot obtain the operational metrics of each individual application container within the container group, including but not limited to: the CPU (Central Processing Unit) usage and memory usage of virtual machines. It can be seen that conventional technologies can achieve overall operational metrics for multiple application containers, not just the metrics of a single application container. To collect the operational metrics of each application container, a dedicated collection container can be deployed within each Pod, which incurs additional overhead in CPU, memory, and other resources. As the number of containers in the cluster increases, this overhead leads to higher operational costs.

[0085] This application implements the mounting of the runtime metrics of the business container to the system container, enabling the business container to access its runtime metrics. This allows the operating system within the system container to monitor the business container's metrics for performance management. This embodiment of the application achieves the aforementioned monitoring of business container runtime metrics simply through resource mounting, effectively reducing costs.

[0086] When the resource mount type is a virtual machine resource, the resource mount interface mounts the path on the host machine where the secure container, carried in the main body of the resource mount request, to the target mount path. Specifically, when the resource mount type is a host machine resource, the resource corresponding to the resource mount parameters is mounted to the target mount path, including: The path in the host machine is split into the top-level path of the host machine and the business sub-path; the top-level path is mounted to the first path in the system container; the path composed of the first path and the business sub-path in the system container is mounted to the target mounting path.

[0087] In practical applications, for security reasons, the top-level path of the host machine is not directly mounted to the application container; only the subdirectories corresponding to the application container are mounted. However, when creating a Pod cache pool, the application corresponding to the Pod cannot be determined, and therefore the application subpath cannot be determined in advance. Therefore, by first binding and mounting the top-level path of the host machine to the first path in the system container, and then mounting the first path in the system container plus the application subpath to the application container, the security of the top-level path of the host machine can be guaranteed.

[0088] In conventional solutions, paths on the host machine can be mounted to the application container via hostpath mounting. However, this approach requires setting the mounted host path in the Pod configuration before starting the secure container. For existing Pod instances, when updating the application container, the mount point in the hostpath mounting method (i.e., the path on the host machine to be mounted) cannot be directly modified. This embodiment of the application, however, can implement mounting during the virtual machine initialization process. Therefore, after modifying the path on the host machine, simply running the virtual machine initialization process will remount the Pod.

[0089] In summary, the embodiments of this application can dynamically mount storage resources through the resource mounting plugin in the virtual machine initialization process.

[0090] Figure 4 This is a flowchart illustrating the steps of another container resource mounting method in this application embodiment, referencing... Figure 4 As shown, the resource mounting method for the above container includes the following steps: S201. When the virtual machine initialization process of a secure container receives a container creation request, it extracts the resource management pattern from the annotations of the secure container.

[0091] S202. When the resource management mode indicates dynamic resource management, run the resource management plugin.

[0092] Execute S203 or S211 after executing S202.

[0093] S203. The resource management plugin extracts the resource mount type from the first environment variable of the secure container, extracts the resource mount parameters from the second environment variable corresponding to the resource mount type, and extracts the target mount path from the third environment variable of the secure container.

[0094] S204. The resource management plugin encapsulates the resource mount type into the header information of the resource mount request, and encapsulates the resource mount parameters and the target mount path together into the message body of the resource mount request, and sends the resource mount request to the resource management service.

[0095] S205. The resource management service extracts the resource mount type from the header information of the resource mount request, obtains the resource type set according to the container identifier of the security container, and when the resource mount type is in the resource type set, it proceeds to one of S206 to S210 according to the resource mount type.

[0096] S206. When the resource mount type is object storage service, mount the object storage service path and the object storage service indicated by the bucket information to the target mount path.

[0097] S207. When the resource mount type is a file storage system, mount the file storage system indicated by the server address, file path, and file protocol version to the target mount path.

[0098] S208. When the resource mount type is a block storage device, determine whether the block identifier in the resource mount parameters has a corresponding block. If the block identifier does not have a corresponding block storage device, create a block storage device based on the block identifier, block size, and block model, and format the block storage device as a file system to mount the block storage device to the target mount path. Alternatively, if the block identifier has a corresponding block storage device, bind the block storage device to the virtual machine and mount the block storage device to the target mount path.

[0099] S209. When the resource mount type is virtual machine resource, mount the path in the virtual machine to the target mount path.

[0100] S210. When the resource mount type is host resource, the path in the host is split into the top-level path of the host and the business sub-path. The top-level path is mounted to the first path in the system container, and the path composed of the first path in the system container and the business sub-path is mounted to the target mount path.

[0101] S211. When the virtual machine initialization process of a secure container indicates static resource management in resource management mode, it mounts the default source path to the default target path.

[0102] The default source path and default target path can be the default settings or the paths from the last mount.

[0103] It should be noted that S201 to S211 described above can be referred to the foregoing embodiments, and will not be repeated here. In addition, the order of S201 to S211 can be flexibly adjusted on the basis of mutual independence, and the embodiments of this application do not limit the order of them.

[0104] Figure 5 This is a schematic diagram of the structure of a container resource mounting device according to an embodiment of this application, applied to electronic devices, such as... Figure 5 As shown, the resource mounting device 400 of the container may include: The information extraction module 401 is used to extract mount instruction information from the environment variables of the secure container through the resource management plugin during the virtual machine initialization process of the running secure container.

[0105] The request generation module 402 is used to generate resource mount requests based on mount instruction information through the resource management plugin.

[0106] The mount processing module 403 is used to process resource mount requests by calling the resource management service through the resource management plugin.

[0107] Optionally, the information extraction module 401 is also used for: The resource management plugin extracts the resource mount type from the first environment variable of the secure container; the resource mount parameters are extracted from the second environment variable corresponding to the resource mount type, with different second environment variables for different resource mount types; and the target mount path is extracted from the third environment variable of the secure container.

[0108] Optionally, the request generation module 402 is also used for: The resource management plugin encapsulates the resource mount type into the header information of the resource mount request; the resource mount parameters and the target mount path are also encapsulated into the message body of the resource mount request.

[0109] Optionally, the mounting processing module 403 is also used for: The resource management service extracts the resource mount type from the header information of the resource mount request; the resource management service then calls the resource mount interface corresponding to the resource mount type to mount the resource corresponding to the resource mount parameters to the target mount path.

[0110] Optionally, the mounting processing module 403 is also used for: The resource management service obtains the resource type set based on the container identifier of the secure container; when the resource mount type is in the resource type set, the resource management service calls the resource mount interface corresponding to the resource mount type to mount the resource corresponding to the resource mount parameters to the target mount path.

[0111] Optionally, the resource mount type includes at least one of the following: object storage service, file storage system, block storage device, virtual machine resource, or host machine resource; the resource mount parameters corresponding to the object storage service include: the path of the object storage service and bucket information; the resource mount parameters corresponding to the file storage system include: the server address of the file storage system, file path, and file protocol version; the resource mount parameters corresponding to the block storage device include: block identifier, block size, and block model; the resource mount parameters corresponding to the virtual machine resource include: the path in the virtual machine where the secure container is located; the resource mount parameters corresponding to the host machine resource include: the path in the host machine where the secure container is located.

[0112] Optionally, when the resource mount type is a block storage device, the mount processing module 403 is further used for: Determine if a corresponding block exists in the block identifier in the resource mount parameters; if no corresponding block storage device exists for the block identifier, create a block storage device based on the block identifier, block size, and block model, and format the block storage device as a file system to mount the block storage device to the target mount path; if a corresponding block storage device exists for the block identifier, bind the block storage device to the virtual machine and mount the block storage device to the target mount path.

[0113] Optionally, the path within the virtual machine where the security container resides includes: a path used to store the runtime metrics of the business container, and a target mount path including a path within the system container of the security container.

[0114] Optionally, when the resource mount type is a host resource, the mount processing module 403 is also used for: The path in the host machine is split into the top-level path of the host machine and the business sub-path; the top-level path is mounted to the first path in the system container; the path composed of the first path and the business sub-path in the system container is mounted to the target mounting path.

[0115] Optionally, it also includes: The plugin runtime module is used to extract the resource management pattern from the annotations of the secure container when the virtual machine initialization process of the secure container receives a container creation request; when the resource management pattern indicates dynamic resource management, the resource management plugin is run.

[0116] Optionally, the mounting processing module 403 is also used for: When the resource management mode indicates static resource management, the default source path will be mounted to the default target path.

[0117] This application also provides an electronic device 900, such as... Figure 6 As shown, it includes a processor 9001, a communication interface 9002, a memory 9003, and a communication bus 9004. The processor 9001, communication interface 9002, and memory 9003 communicate with each other via the communication bus 9004. The memory 9003 is used to store computer programs; the processor 9001 is used to implement the resource mounting method of the container provided in the above embodiment when executing the program stored in the memory 9003.

[0118] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0119] The communication interface is used for communication between the aforementioned terminal and other devices.

[0120] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0121] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0122] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform the resource mounting method of any of the containers described in the above embodiments.

[0123] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the resource mounting method of any of the containers described in the above embodiments.

[0124] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0125] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0126] It should be noted that the various data-related processes in the embodiments of this application are carried out in compliance with the relevant data protection laws and policies of the country where the location is located, and with the authorization granted by the owner of the corresponding device.

[0127] The various embodiments in this specification are described in a related 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 system 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.

[0128] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A resource mounting method of a container, characterized by, The method comprises: When a virtual machine initialization process of a secure container is running, a resource management plug-in extracts mounting indication information from environment variables of the secure container; The resource management plug-in generates a resource mounting request according to the mounting indication information; The resource management plug-in calls a resource management service to process the resource mounting request.

2. The method of claim 1, wherein, The resource management plug-in extracts mounting indication information from environment variables of the secure container, comprising: The resource management plug-in extracts a resource mounting type from a first environment variable of the secure container; The resource management plug-in extracts resource mounting parameters from a second environment variable corresponding to the resource mounting type, different resource mounting types corresponding to different second environment variables; The resource management plug-in extracts a target mounting path from a third environment variable of the secure container.

3. The method of claim 2, wherein, The resource management plug-in generates a resource mounting request according to the mounting indication information, comprising: The resource management plug-in encapsulates the resource mounting type into header information of the resource mounting request; The resource management plug-in encapsulates the resource mounting parameters and the target mounting path into a message body of the resource mounting request.

4. The method according to any one of claims 1 to 3, characterized in that, The resource management plug-in calls a resource management service to process the resource mounting request, comprising: The resource management service extracts the resource mounting type from the header information of the resource mounting request; The resource management service calls a resource mounting interface corresponding to the resource mounting type to mount a resource corresponding to the resource mounting parameters to the target mounting path.

5. The method of claim 4, wherein, The resource management service calls a resource mounting interface corresponding to the resource mounting type to mount a resource corresponding to the resource mounting parameters to the target mounting path, comprising: The resource management service acquires a resource type set according to a container identifier of the secure container; When the resource mounting type is in the resource type set, the resource management service calls a resource mounting interface corresponding to the resource mounting type to mount a resource corresponding to the resource mounting parameters to the target mounting path.

6. The method according to any one of claims 1 to 3, characterized in that, The resource mounting type comprises at least one of the following: an object storage service, a file storage system, a block storage device, a virtual machine resource, or a host machine resource; The resource mounting parameters corresponding to the object storage service comprise a path of the object storage service and bucket information; The resource mounting parameters corresponding to the file storage system comprise a server address, a file path, and a file protocol version of the file storage system; The resource mounting parameters corresponding to the block storage device comprise a block identifier, a block size, and a block model number; The resource mounting parameters corresponding to the virtual machine resource comprise a path in a virtual machine where the secure container is located; The resource mounting parameters corresponding to the host machine resource comprise a path in a host machine where the secure container is located.

7. The method of claim 6, wherein, When the resource mounting type is a block storage device, mounting a resource corresponding to the resource mounting parameters to the target mounting path comprises: Determining whether a corresponding block exists in the block identifier in the resource mounting parameters; When the block identifier does not exist corresponding block storage device, creating block storage device according to the block identifier, the block size and the block model number, and formatting the block storage device as a file system to mount the block storage device into the target mounting path; When the block identifier exists corresponding block storage device, binding the block storage device to the virtual machine, and mounting the block storage device into the target mounting path.

8. The method of claim 6, wherein, The path in the virtual machine where the security container is located comprises a path for storing operation indexes of a business container, and the target mounting path comprises a path in a system container of the security container.

9. The method of claim 6, wherein, When the resource mounting type is a host resource, mounting the resource corresponding to the resource mounting parameter into the target mounting path comprises: Splitting the path in the host into a top path of the host and a business sub-path; Mounting the top path to a first path in the system container; Mounting the path composed of the first path in the system container and the business sub-path to the target mounting path.

10. The method according to any one of claims 1 to 3, characterized in that, The resource management plug-in in the virtual machine initialization process of the security container further intercepts a security container creation request before the security container is created. The virtual machine initialization process of the security container extracts a resource management mode from an annotation of the security container when receiving a container creation request. When the resource management mode indicates dynamic resource management, the resource management plug-in is run.

11. The method of claim 10, wherein, The method further comprises: When the resource management mode indicates static resource management, mounting a default source path into a default target path.

12. A resource mounting apparatus of a container, characterized by comprising: The apparatus comprises: An information extraction module configured to extract mounting indication information from environment variables of the security container through a resource management plug-in when a virtual machine initialization process of the security container is run; A request generation module configured to generate a resource mounting request according to the mounting indication information through the resource management plug-in; A mounting processing module configured to process the resource mounting request through a resource management service called by the resource management plug-in.

13. An electronic device, comprising: The apparatus comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; The memory is configured to store a computer program; The processor is configured to execute the program stored in the memory to implement the method of any one of claims 1 to 11.

14. A computer readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1 to 11.

15. A computer program, characterized in that, The computer program is run by the computer to implement the method of any one of claims 1 to 11. The computer program is run by the computer to implement the method of any one of claims 1 to 11.

Images