Container storage volume dynamic mounting method and related device

Abstract

The application discloses a container storage volume dynamic mounting method and related equipment, relates to the technical field of container arrangement and storage management, and comprises the following steps: in response to the fact that an event listening module monitors that there is a new mounting demand in a Kubernetes Pod Annotation, obtaining a mounting declaration from the Kubernetes Pod Annotation, mounting based on the mounting declaration, and returning a mounting result; if the mounting result is mounting failure, returning the mounting step until the mounting is successful. The application monitors the mounting declaration change in the Kubernetes Pod Annotation through the event listening module, responds to the change to perform mounting in the container running process, ensures that the mounting is finally successful in combination with a failure retry mechanism, realizes that the storage volume can be dynamically added or deleted without rebuilding a container group during container running, effectively solves the technical problem of dynamic mounting in the container running process, and significantly improves the flexibility and operation and maintenance efficiency of storage management.

Description

Technical Field

[0001] This application relates to the field of container orchestration and storage management technology, and in particular to a method and related equipment for dynamically mounting container storage volumes. Background Technology

[0002] In related technologies, the standard way to mount persistent storage volumes to containers in container orchestration platforms (such as Kubernetes) is based on the Container Storage Interface (CSI). This process relies on the kubelet to synchronously perform node-level mount operations during the Pod creation phase, mounting the storage backend to the node's global directory, and then mapping it to the container's target path via bind-mount. Successful container startup depends on the successful mounting, and the storage volume declaration must be predefined in the Pod specification.

[0003] However, the existing solution has significant drawbacks: First, the mounting is tightly coupled with the container lifecycle. If the storage backend is abnormal or the driver fails, the Pod will be blocked in the ContainerCreating state for a long time and will not be able to enter the Running state, which reduces system availability. Second, the dual bind-mount introduces additional kernel overhead, which affects the performance of large-scale container deployment. Third, the mounting configuration is statically bound to the Pod Spec. Storage volumes cannot be dynamically added or deleted during container operation. Changes require rebuilding the Pod, which is difficult to meet the needs of elastic and agile operation and maintenance. Summary of the Invention

[0004] The main purpose of this application is to provide a method and related equipment for dynamically mounting container storage volumes, aiming to solve the technical problem of how to dynamically mount them during container operation.

[0005] To achieve the above objectives, this application proposes a method for dynamically mounting container storage volumes, the method comprising: In response to the event listening module detecting a new mount requirement in the Kubernetes Pod Annotation, the mount declaration is obtained from the Kubernetes Pod Annotation; Based on the mount declaration, mount the device and return the mount result; If the mounting result is a mounting failure, return to the mounting steps until the mounting is successful.

[0006] In one embodiment, after the step of until successful mounting, the method further includes: If an abnormal restart of a container is detected, during the container startup process, based on the runtime plugin module, the mount operation is executed sequentially on all mount declarations in the Kubernetes Pod Annotation, resulting in multiple mount results; If any of the mounting results fail, the event listening module will re-attack the mounting operation corresponding to the failed mounting during the normal operation of the container until all mounting results are successful.

[0007] In one embodiment, the mount declaration includes a storage volume identifier, a mount target path, a storage type, a subpath, and mount options. The step of mounting based on the mount declaration further includes: Based on the storage type, determine the parsing link; Based on the parsing link, the mount declaration is parsed to assemble mount parameters; Mounting is performed based on the aforementioned mounting parameters.

[0008] In one embodiment, the step of parsing the mount declaration based on the parsing link to assemble mount parameters further includes: When the storage volume identifier is a user-side storage declaration identifier, query the storage volume resource identifier bound to the user-side storage declaration identifier based on the Kubernetes API; Based on the Kubernetes API and the storage volume resource identifier, obtain the storage volume resource object, extract the storage backend path information from the attribute fields of the storage volume resource object, and extract the auxiliary resource references associated with the storage backend path information; Based on the auxiliary resource reference, the auxiliary resource is queried through the Kubernetes API to extract the connection endpoint and authentication information of the storage backend from the auxiliary resource; The connection endpoint, the storage backend path information, the authentication information, and the mount options are assembled into the mount parameters.

[0009] In one embodiment, before the step of mounting based on the mounting parameters, the method further includes: Enter the target container's mount namespace to obtain the current mount status of the target path based on the mount information query tool; If the target path is not a mount point, mount the device. If the target path is already a mount point, the current mount source and current file system type are extracted from the results of the mount information query tool. The current mount source is compared with the expected mount source to obtain a first comparison result, and the current file system type is compared with the expected file system type to obtain a second comparison result. If both the first and second comparison results are successful, the mount operation is skipped, and a mount success is returned. If either the first or second comparison result fails, a mount conflict error is recorded, and a mount failure is returned.

[0010] In one embodiment, the step of mounting based on the mounting parameters further includes: Based on the mount parameters, the target directory is recursively created within the container's mount namespace; Based on the container's mount namespace, PID namespace, and the target directory, standard file system mount operations are performed to mount the storage backend's mount source to the target path.

[0011] In one embodiment, after the step of mounting the storage backend source to the target path, the method further includes: Based on the container's mount namespace, obtain the file system group identifier from the container group's security context; Based on the file system group identifier, recursively modify the file ownership group of the target directory within the container's mount namespace, and grant group access permissions corresponding to the file system group identifier; Based on the container's mount namespace, the security context label of the target directory is recursively set, and the security context label is used to allow the container process to access the target directory.

[0012] Furthermore, to achieve the above objectives, this application also proposes a container storage volume dynamic mounting device, which includes: The acquisition module is used to obtain the mount declaration from the Kubernetes Pod Annotation in response to the event listening module detecting a new mount requirement in the Kubernetes Pod Annotation. A mounting module, which is used to mount the device based on the mounting declaration and return the mounting result; A loop module is used to return to the mounting step if the mounting result is a mounting failure, until the mounting is successful.

[0013] In addition, to achieve the above objectives, this application also proposes a container storage volume dynamic mounting device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the container storage volume dynamic mounting method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the container storage volume dynamic mounting method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the container storage volume dynamic mounting method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application discloses a method and related equipment for dynamically mounting container storage volumes, relating to the fields of container orchestration and storage management technology. Compared with existing solutions, which have significant drawbacks: First, mounting is strongly coupled with the container lifecycle; if the storage backend malfunctions or the driver fails, the Pod will be blocked in the ContainerCreating state for a long time, unable to enter the Running state, reducing system availability. Second, dual bind-mount introduces additional kernel overhead, affecting the performance of large-scale container deployments. Third, the mounting configuration is statically bound to the Pod Spec; storage volumes cannot be dynamically added or deleted during container operation, and changes require rebuilding the Pod, making it difficult to meet the needs of elastic and agile operation and maintenance. In contrast, this application first responds to the event listening module detecting a new mounting requirement in the Kubernetes Pod Annotation, obtains the mounting declaration from the Kubernetes Pod Annotation, then performs the mounting based on the mounting declaration, and returns the mounting result. Finally, if the mounting result is a mounting failure, the mounting process is returned until the mounting is successful.

[0017] Understandably, this application monitors changes to mount declarations in Kubernetes Pod Annotations through an event listening module and executes mounts in response to these changes during container runtime. It also incorporates a failure retry mechanism to ensure successful mounts. This enables dynamic addition and deletion of storage volumes without rebuilding the container group during container runtime, effectively solving the technical problem of dynamic mounting during container runtime and significantly improving the flexibility and operational efficiency of storage management. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0020] Figure 1 This is a flowchart illustrating an embodiment of the container storage volume dynamic mounting method of this application. Figure 2 This is a system architecture diagram provided for Embodiment 1 of the container storage volume dynamic mounting method of this application; Figure 3 This is a flowchart illustrating Embodiment 2 of the container storage volume dynamic mounting method of this application; Figure 4 This is a schematic diagram of the module structure of the container storage volume dynamic mounting device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the container storage volume dynamic mounting method in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution in this application embodiment is: In this embodiment, for ease of description, the following description will focus on the dynamic mounting of container storage volumes to devices.

[0025] Based on this, embodiments of this application provide a method for dynamically mounting container storage volumes, referring to... Figure 1 and Figure 2 , Figure 1 This is a flowchart illustrating the first embodiment of the container storage volume dynamic mounting method of this application. Figure 2 This is a system architecture diagram provided for the first embodiment of the container storage volume dynamic mounting method of this application.

[0026] In this embodiment, the method for dynamically mounting a container storage volume includes steps S10 to S30: Step S10: In response to the event listening module detecting a new mount requirement in the Kubernetes Pod Annotation, the mount declaration is obtained from the Kubernetes Pod Annotation; It should be noted that the event listening module refers to the node-level daemon component deployed on each worker node of the container orchestration platform. It is responsible for listening to the creation and update events of the container group on this node and calling the corresponding processing methods when the event is triggered.

[0027] Kubernetes Pod Annotations are annotation fields in the metadata of Kubernetes container groups. They are a key-value pair metadata storage mechanism that can be dynamically modified during the runtime of the container group, allowing configuration additions, deletions, and modifications without changing the container group specifications.

[0028] A mount declaration is a description of the mount requirement that a user writes in the container group annotation. It must include at least the identification information of the target storage volume and the mount target path within the container.

[0029] In this embodiment, the event listening module continuously monitors the creation and update events of all container groups on this node. When a new mount requirement is detected in the annotation of a container group, the mount processing flow is triggered. The event listening module reads the mount declaration data from the annotation field of that container group.

[0030] Understandably, this step serves as the trigger entry point for the entire mounting process, allowing real-time awareness of changes in the mounting requirements declared by the user in the container group metadata. This enables the mounting operation to respond to new or changed mounting configurations during container runtime without requiring the container group to be rebuilt.

[0031] Step S20: Based on the mount declaration, perform the mount and return the mount result; It should be noted that mounting refers to the operation of mounting the storage volume of the storage backend to a specified path inside the container file system, so that the container process can access the data in the storage volume through that path.

[0032] In this embodiment, based on the parameters (storage volume identifier, mount target path, storage type, subpath, mount options, etc.) in the mount declaration obtained in step S10, parameter parsing, namespace injection, and kernel mount operations are performed sequentially. After the mount operation is completed, the mount result is returned.

[0033] Understandably, this step carries the core mount execution logic, translating user declarations into actual kernel mount operations.

[0034] Step S30: If the mounting result is a mounting failure, return to the mounting step until the mounting is successful.

[0035] It should be noted that the mount result refers to the status information returned after the mount operation is completed, which includes at least an indication of whether the mount was successful or failed.

[0036] In this embodiment, it is determined whether the mounting result returned in step S20 is a mounting failure. If the mounting fails, the process returns to step S20 to re-execute the mounting; if the mounting is successful, the process for the current mounting item ends.

[0037] Understandably, this application introduces an automatic retry mechanism. When the initial mounting fails due to transient failures such as network jitter or temporary unavailability of the storage backend, it ensures that the mounting will eventually succeed through repeated retries, thereby improving the reliability and fault tolerance of the mounting operation.

[0038] Specifically, after the steps leading up to successful mounting, steps S40-S50 are also included: Step S40: If an abnormal restart of the container is detected, during the container startup process, based on the runtime plugin module, the mount operation is executed sequentially on all mount declarations in the Kubernetes Pod Annotation to obtain multiple mount results; It should be noted that abnormal restart refers to an unexpected restart of a container due to reasons such as process crash, node failure recovery, or being evicted by the system.

[0039] Runtime plugin modules refer to node resource interface plugins registered as container runtimes. They communicate with the container runtime via Unix DomainSocket and can receive callback notifications from the container runtime after the container process starts.

[0040] All mount declarations refer to all mount declarations that exist in the current container group annotations.

[0041] Sequential mounting operations refer to the runtime plugin module performing the mounting operation sequentially on all mount declarations in the container group annotations during container startup.

[0042] In this embodiment, when the container restarts due to an abnormal reason, the pre-registered runtime plugin module is called back by the container runtime during the container restart process. The runtime plugin module obtains all mount declarations in the current container group annotations, performs mount operations on each mount declaration in turn, and generates a mount result for each mount operation. Multiple mount results are then obtained by summing them up.

[0043] Understandably, this step covers scenarios where containers restart abnormally, ensuring that the storage volume mounts on the container can be automatically rebuilt after the container resumes operation, eliminating the need for manual intervention.

[0044] Step S50: If there is a mounting failure among the multiple mounting results, then during the normal operation of the container, based on the event listening module, the mounting operation corresponding to the mounting failure will be re-mounted until all mounting results are successful.

[0045] It should be noted that multiple mount results refer to the mount item results returned by the runtime plug-in module after performing the mount operation during container startup in step S40.

[0046] The normal operation process refers to the stage where the container has successfully entered the running state and continues to provide services.

[0047] In this embodiment, it is determined whether any of the multiple mounting results obtained in step S40 have failed. If any mounting failures occur, after the container enters normal operation, the event listening module will specifically target these failed mounting items and use a retry mechanism to re-execute the mounting until all mounting items are successfully mounted.

[0048] Understandably, if the plugin module fails to mount completely at runtime, the event listener module compensates for the failure and retryes during normal container operation, forming a dual guarantee mechanism to ultimately ensure that all mount declarations are successfully effective.

[0049] This application discloses a method and related equipment for dynamically mounting container storage volumes, relating to the fields of container orchestration and storage management technology. Compared with existing solutions, which have significant drawbacks: First, mounting is strongly coupled with the container lifecycle; if the storage backend malfunctions or the driver fails, the Pod will be blocked in the ContainerCreating state for a long time, unable to enter the Running state, reducing system availability. Second, dual bind-mount introduces additional kernel overhead, affecting the performance of large-scale container deployments. Third, the mounting configuration is statically bound to the Pod Spec; storage volumes cannot be dynamically added or deleted during container operation, and changes require rebuilding the Pod, making it difficult to meet the needs of elastic and agile operation and maintenance. In contrast, this application first responds to the event listening module detecting a new mounting requirement in the Kubernetes Pod Annotation, obtains the mounting declaration from the Kubernetes Pod Annotation, then performs the mounting based on the mounting declaration, and returns the mounting result. Finally, if the mounting result is a mounting failure, the mounting process is returned until the mounting is successful.

[0050] Understandably, this application monitors changes to mount declarations in Kubernetes Pod Annotations through an event listening module and executes mounts in response to these changes during container runtime. It also incorporates a failure retry mechanism to ensure successful mounts. This enables dynamic addition and deletion of storage volumes without rebuilding the container group during container runtime, effectively solving the technical problem of dynamic mounting during container runtime and significantly improving the flexibility and operational efficiency of storage management.

[0051] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 The mount declaration includes a storage volume identifier, mount target path, storage type, subpath, and mount options. The step of mounting based on the mount declaration further includes steps A10-A30: Step A10: Determine the resolution link based on the storage type; It should be noted that the parsing link refers to the parameter parsing and processing path designed for different storage types. Different types of storage backends (such as CephFS, NFS, etc.) correspond to different parameter sources and assembly logic.

[0052] For CephFS types: the storage backend path is obtained from the subvolume path attribute of the storage volume, the connection endpoint is parsed from the monitor address list in the cluster configuration object (such as ConfigMap), and the authentication information is obtained from the user identifier and key in the credential object (such as Secret), which are then assembled into a mount source in monitor address list: subvolume path format.

[0053] For NFS type: The storage backend path is obtained from the shared path attribute of the storage volume, and the connection endpoint obtains the ClusterIP of the NFS service through the service discovery mechanism (such as filtering services by tag) and assembles it into a mount source in the ClusterIP: shared path format.

[0054] For other types of storage backends (general extensions): Compared to CephFS and NFS, for other kernel-supported file system types, the system can directly use the storage volume identifier as the mount source and the storage type as the file system type to achieve general mount support. Users can connect to more storage backends by extending the storage type resolution adapter.

[0055] In this embodiment, based on the storage type field in the mounting declaration, the parsing task of the mounting declaration is distributed to the parsing link corresponding to that storage type. Each storage type has its own preset independent parameter acquisition rules and assembly method.

[0056] Understandably, this step enables scalable adaptation to multiple storage types, allowing the system to distinguish different storage backends through the storage type field and call the corresponding parameter parsing logic, laying the foundation for the accurate assembly of subsequent mounting parameters.

[0057] Step A20: Based on the parsing link, parse the mount declaration to assemble mount parameters; It should be noted that mount parameters refer to the complete set of technical parameters required to perform kernel mount operations. They include at least the mount source string, file system type, and mount option list, and serve as a bridge between mount declarations and kernel mount operations.

[0058] In this embodiment, the parameter parsing logic corresponding to the parsing link determined in step A10 is invoked. By querying the application programming interface of the container orchestration platform, storage backend information is extracted level by level from the storage volume resource object and its associated auxiliary resources, and the scattered declaration information and platform metadata are assembled into mount parameters that can be directly used by the kernel mount command.

[0059] Understandably, this step automatically translates the user's abstract declarations (such as storage volume name and mount path) into specific mount parameters (such as storage backend IP address and authentication key), allowing the user to declare only the target storage volume and mount path without having to manually configure complex information such as the storage backend address and credentials.

[0060] Specifically, the step of parsing the mount declaration based on the parsing link to assemble mount parameters further includes steps A21 to A24: Step A21: When the storage volume identifier is a user-side storage declaration identifier, query the storage volume resource identifier bound to the user-side storage declaration identifier based on the Kubernetes API; It should be noted that the user-side storage declaration identifier refers to the name of the storage resource declaration object that the user applies for in the container orchestration platform. It represents the user's application requirements for storage resources and can only be used after being bound to the actual storage volume resources.

[0061] In this embodiment, the content of the storage volume identifier field is parsed. If the storage volume identifier is a user-side storage declaration identifier, the application programming interface of the container orchestration platform is called to query the storage volume resource identifier bound to the user-side storage declaration identifier; if the storage volume identifier is directly a storage volume resource identifier, this step is skipped.

[0062] Understandably, this step completes the mapping from user-side storage declaration to actual storage volume resources, enabling subsequent steps to obtain specific storage backend information based on the storage volume resource object. It is a necessary preprocessing step for achieving automatic parameter assembly.

[0063] Step A22: Based on the Kubernetes API and the storage volume resource identifier, obtain the storage volume resource object, extract the storage backend path information from the attribute fields of the storage volume resource object, and extract the auxiliary resource references associated with the storage backend path information; It should be noted that a storage volume resource object refers to the metadata object in the container orchestration platform that represents the actual storage volume resource, including attribute information such as the storage volume capacity, access mode, and storage backend path.

[0064] Storage backend path information refers to the specific path identifier of a storage volume in the storage backend system, such as a subvolume path in CephFS or a shared export path in NFS.

[0065] Secondary resource references are reference fields in storage volume resource objects that point to other related resources. They are used to obtain information such as the connection endpoints and authentication credentials of the storage backend.

[0066] In this embodiment, based on the storage volume resource identifier obtained in step A21, the application programming interface of the container orchestration platform is called to obtain the complete storage volume resource object. Storage backend path information is extracted from the attribute fields of this resource object, and auxiliary resource references associated with the storage backend path information are also extracted. These auxiliary resource references point to other resource objects containing connection endpoints and authentication information.

[0067] Understandably, this step extracts the core data required for mounting from the storage volume resource object, including the specific path of the storage volume in the storage backend and the associated resource references for obtaining connection endpoints and authentication information, providing a data source for subsequently obtaining complete storage backend access information.

[0068] Step A23: Based on the auxiliary resource reference, query the auxiliary resource through the Kubernetes API to extract the connection endpoint and authentication information of the storage backend from the auxiliary resource; It should be noted that auxiliary resources refer to the associated resources referenced by the storage volume resource object, including storage cluster configuration objects (such as ConfigMap, which contains a list of endpoint addresses for the storage backend), credential objects (such as Secret, which contains user identifiers and keys), and service discovery objects (such as Service, which provides network access addresses for the storage service).

[0069] Connection endpoints refer to the network access addresses of the storage backend, such as the monitor address list of a Ceph cluster or the service IP address of an NFS server.

[0070] Authentication information refers to the authentication credentials required to access the storage backend, such as usernames and keys.

[0071] In this embodiment, based on the auxiliary resource references extracted in step A22, the application programming interface of the container orchestration platform is invoked to query the corresponding auxiliary resources. The connection endpoints and authentication information of the storage backend are then extracted from the auxiliary resources.

[0072] Understandably, this step completes the network address and authentication credentials required for storage access, expanding the mount parameters from containing only path information to including complete connection information, ensuring that subsequent mount operations can successfully establish a connection with the storage backend.

[0073] Step A24: Assemble the connection endpoint, the storage backend path information, the authentication information, and the mount options into the mount parameters.

[0074] In this embodiment, the storage backend path information extracted in step A22, the connection endpoint and authentication information extracted in step A23, and the mount options in the mount declaration are assembled into a unified mount parameter structure. If a subpath is specified in the mount declaration, the subpath is appended to the end of the storage backend path information to form the path portion of the final mount source string.

[0075] Understandably, this step integrates various information sources from scattered sources into standardized mounting parameters, providing a unified and complete execution basis for subsequent actual mounting operations.

[0076] Specifically, before the step of mounting based on the mounting parameters, steps A25 to A27 are also included: Step A25: Enter the target container's mount namespace to obtain the current mount status of the target path based on the mount information query tool; It should be noted that the target container refers to the container instance specified in the mount declaration that needs to mount the storage volume.

[0077] Mount namespace refers to one of the namespace isolation mechanisms provided by the Linux kernel, used to isolate the list of file system mount points seen by processes. Each container has its own independent mount namespace.

[0078] Mount information query tools are operating system tools used to query the mount status of file systems. They can obtain detailed information such as whether a specified path is a mount point, the corresponding mount source, and the file system type.

[0079] In this embodiment, the target container's process identifier is used to enter the target container's mount namespace via the Linux namespace injection mechanism. Within this namespace, a mount information query tool is invoked to obtain the current mount status information of the target path specified in the mount declaration.

[0080] Understandably, this step accurately assesses the mounting status of the target path before performing the mounting operation, providing a data foundation for subsequent idempotent mounting judgments and avoiding duplicate mounting or mounting overwriting issues caused by blindly performing mounting.

[0081] Step A26: If the target path is not a mount point, mount the target path. In this embodiment, the determination is made based on the mount status query result obtained in step A25. If the query result indicates that the target path is not currently a mount point, then a mount operation is performed to mount the storage backend to the target path.

[0082] Understandably, this step is performed only after confirming that the target path has not been mounted, in order to avoid interfering with existing mount points.

[0083] Step A27: If the target path is already a mount point, extract the current mount source and current file system type from the results of the mount information query tool, compare the current mount source with the expected mount source to obtain a first comparison result, and compare the current file system type with the expected file system type to obtain a second comparison result. If both the first and second comparison results are successful, skip the mount operation and return a mount success message; if either the first or second comparison result is a comparison failure, record a mount conflict error and return a mount failure message.

[0084] It should be noted that the current mount source refers to the actual storage source address currently mounted on the target path, extracted from the results returned by the mount information query tool.

[0085] The expected mount source refers to the target mount source determined based on the mount declaration and parameter parsing results, that is, the storage source address that this operation expects to mount to the target path.

[0086] The current file system type refers to the file system type currently being used by the target path, extracted from the results returned by the mount information query tool.

[0087] The expected file system type refers to the target file system type determined based on the mount declaration and storage type, i.e., the file system type expected to be used in this operation.

[0088] In this embodiment, if the mount status query result indicates that the target path is already a mount point, the current mount source and the current file system type are extracted from the query result. The current mount source is compared with the desired mount source to obtain a first comparison result, and the current file system type is compared with the desired file system type to obtain a second comparison result. If both comparison results are consistent, the existing mount is determined to meet the requirements, the mount operation is skipped, and a success is returned; if either comparison result is inconsistent, a mount conflict is determined, the error is recorded, and a failure is returned.

[0089] Understandably, this step achieves idempotent mounting through a dual comparison of the mount source and file system type, ensuring that existing mounts will not be overwritten or destroyed in scenarios of repeated triggering or container restart, while accurately identifying mount conflicts caused by configuration changes.

[0090] Step A30: Mount the device based on the mounting parameters.

[0091] In this embodiment, using the mount parameters assembled in step A24, the system enters the target container's mountnamespace and performs the actual kernel mount operation, mounting the storage backend to the target path within the container.

[0092] Understandably, this step performs the actual mount operation, attaching the storage volume to the container file system, enabling the container process to access the storage data via the target path.

[0093] Specifically, the step of mounting based on the mounting parameters further includes steps A31 to A32: Step A31: Based on the mount parameters, recursively create the target directory within the container's mount namespace; In this embodiment, within the target container's mount namespace, it checks whether the parent directory of the mount target path exists. If it does not exist, it creates it level by level, eventually creating a complete mount target directory in the container's file system.

[0094] Understandably, this step ensures that the target path actually exists in the container file system, providing a valid mount point directory for subsequent mount operations and preventing mount failure due to the target directory not existing.

[0095] Step A32: Based on the container's mount namespace, PID namespace, and the target directory, perform a standard file system mount operation to mount the storage backend's mount source to the target path.

[0096] It should be noted that the PID namespace is one of the namespace isolation mechanisms provided by the Linux kernel, used to isolate the process ID numbering space. Containers have their own independent PID namespace, and the PIDs of processes within a container are numbered starting from 1.

[0097] In this embodiment, the system simultaneously enters the target container's mount namespace and PID namespace, executes a standard Linux file system mount system call, and mounts the storage backend's mount source to the target directory created in step A31. After mounting, the storage volume becomes immediately visible in the container's file system namespace.

[0098] Understandably, this step completes the kernel-level mount directly within the target container's namespace, bypassing the host's global directory or the container's intermediate directory's bind-mount, thus achieving a single, direct mount of the storage volume to the container's file system.

[0099] Specifically, after the step of mounting the storage backend source to the target path, steps A33-A35 are also included: Step A33: Based on the container's mount namespace, obtain the file system group identifier from the container group's security context; It should be noted that security context refers to the container security policy configuration defined in the container orchestration platform, which includes access control parameters such as file system group identifier and security label.

[0100] The file system group identifier is a group identifier configured in the security context, which is used to control the access permissions of container processes to mounted volumes. Processes inside the container will use this group identifier as supplementary group permissions to access the contents of the file system.

[0101] In this embodiment, after the mount operation is completed, the file system group identifier configuration is obtained from the security context of the container group.

[0102] Understandably, this step obtains the permission control parameters of the dynamically mounted directory, providing a basis for setting the access permissions of the mounted directory in the future.

[0103] Step A34: Based on the file system group identifier, recursively modify the file ownership group of the target directory within the container's mount namespace, and grant group access permissions corresponding to the file system group identifier; In this embodiment, within the mount namespace of the target container, the group ownership information of the target directory, its subdirectories, and files is recursively modified based on the file system group identifier obtained in step A33, and group access permissions corresponding to the file system group identifier are granted.

[0104] Understandably, this step sets the correct file ownership and group permissions for dynamically mounted storage volume directories to ensure that container processes can access mounted content in accordance with platform security policies.

[0105] Step A35, and based on the container's mount namespace, recursively set the security context label of the target directory, the security context label being used to allow container processes to access the target directory.

[0106] It should be noted that security context labels are security attribute labels used in Linux security modules (such as SELinux) to mark files or directories. The container runtime uses these labels to determine whether to allow container processes to access resources.

[0107] In this embodiment, within the target container's mount namespace, security context labels are recursively set for the target directory and all its subdirectories and files. These labels match the container runtime's security policy, allowing the container runtime to permit container processes to access the target path.

[0108] Understandably, this step configures security labels for dynamically mounted directories to ensure that storage volume directories introduced through dynamic mounting can pass security policy checks when accessed, thus resolving the issue that security labels are not automatically inherited after the mounting operation is separated from the container and a link is created.

[0109] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the dynamic mounting method of container storage volumes in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0110] This application also provides a device for dynamically mounting container storage volumes; please refer to [reference needed]. Figure 4 The container storage volume dynamic mounting device includes: The acquisition module 10 is used to obtain the mount declaration from the Kubernetes Pod Annotation in response to the event listening module detecting a new mount requirement in the Kubernetes Pod Annotation. Mounting module 20, which is used to mount based on the mounting declaration and return the mounting result; The loop module 30 is used to return to the mounting step if the mounting result is a mounting failure, until the mounting is successful.

[0111] The container storage volume dynamic mounting device provided in this application, employing the container storage volume dynamic mounting method in the above embodiments, can solve the technical problem of dynamic mounting of container storage volumes. Compared with related technologies, the beneficial effects of the container storage volume dynamic mounting device provided in this application are the same as those of the container storage volume dynamic mounting method provided in the above embodiments, and other technical features in the container storage volume dynamic mounting device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0112] This application provides a container storage volume dynamic mounting device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the container storage volume dynamic mounting method in the above embodiment 1.

[0113] The following is for reference. Figure 5 This document illustrates a structural schematic diagram of a container storage volume dynamic mounting device suitable for implementing embodiments of this application. The container storage volume dynamic mounting device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The illustrated container storage volume dynamic mounting device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0114] like Figure 5As shown, the container storage volume dynamic mounting device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the container storage volume dynamic mounting device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the container storage volume dynamic mounting device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a container storage volume dynamic mounting device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0115] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0116] The container storage volume dynamic mounting device provided in this application, employing the container storage volume dynamic mounting method in the above embodiments, can solve the technical problem of dynamic mounting of container storage volumes. Compared with related technologies, the beneficial effects of the container storage volume dynamic mounting device provided in this application are the same as those of the container storage volume dynamic mounting method provided in the above embodiments, and other technical features in this container storage volume dynamic mounting device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0117] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0118] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0119] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the container storage volume dynamic mounting method in the above embodiments.

[0120] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0121] The aforementioned computer-readable storage medium may be included in a container storage volume dynamic mount device; or it may exist independently and not be mounted in a container storage volume dynamic mount device.

[0122] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a container storage volume dynamic mount device, cause the container storage volume dynamic mount device to: In response to the event listening module detecting a new mount requirement in the Kubernetes Pod Annotation, the mount declaration is obtained from the Kubernetes Pod Annotation; Based on the mount declaration, mount the device and return the mount result; If the mounting result is a mounting failure, return to the mounting steps until the mounting is successful.

[0123] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0126] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described container storage volume dynamic mounting method, thereby solving the technical problem of dynamic mounting of container storage volumes. Compared with related technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the container storage volume dynamic mounting method provided in the above embodiments, and will not be elaborated here.

[0127] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the container storage volume dynamic mounting method described above.

[0128] The computer program product provided in this application can solve the technical problem of dynamic mounting of container storage volumes. Compared with related technologies, the beneficial effects of the computer program product provided in this application are the same as those of the dynamic mounting method of container storage volumes provided in the above embodiments, and will not be repeated here.

[0129] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A method for dynamically mounting a container storage volume, characterized in that, The method for dynamically mounting container storage volumes includes: In response to the event listening module detecting a new mount requirement in the Kubernetes Pod Annotation, the mount declaration is obtained from the Kubernetes Pod Annotation; Based on the mount declaration, mount the device and return the mount result; If the mounting result is a mounting failure, return to the mounting steps until the mounting is successful.

2. The method for dynamically mounting container storage volumes as described in claim 1, characterized in that, After the steps leading up to successful mounting, the following are also included: If an abnormal restart of a container is detected, during the container startup process, based on the runtime plugin module, the mount operation is executed sequentially on all mount declarations in the Kubernetes Pod Annotation, resulting in multiple mount results; If any of the mounting results fail, the event listening module will re-attack the mounting operation corresponding to the failed mounting during the normal operation of the container until all mounting results are successful.

3. The method for dynamically mounting container storage volumes as described in claim 1, characterized in that, The mount declaration includes a storage volume identifier, a mount target path, a storage type, a subpath, and mount options. The step of mounting based on the mount declaration further includes: Based on the storage type, determine the resolution link; Based on the parsing link, the mount declaration is parsed to assemble mount parameters; Mounting is performed based on the aforementioned mounting parameters.

4. The method for dynamically mounting container storage volumes as described in claim 3, characterized in that, The step of parsing the mount declaration based on the parsing link to assemble mount parameters further includes: When the storage volume identifier is a user-side storage declaration identifier, query the storage volume resource identifier bound to the user-side storage declaration identifier based on the Kubernetes API; Based on the Kubernetes API and the storage volume resource identifier, obtain the storage volume resource object, extract the storage backend path information from the attribute fields of the storage volume resource object, and extract the auxiliary resource references associated with the storage backend path information; Based on the auxiliary resource reference, the auxiliary resource is queried through the Kubernetes API to extract the connection endpoint and authentication information of the storage backend from the auxiliary resource; The connection endpoint, the storage backend path information, the authentication information, and the mount options are assembled into the mount parameters.

5. The method for dynamically mounting container storage volumes as described in claim 3, characterized in that, Before the step of mounting based on the mounting parameters, the method further includes: Enter the target container's mount namespace to obtain the current mount status of the target path based on the mount information query tool; If the target path is not a mount point, mount the device. If the target path is already a mount point, the current mount source and current file system type are extracted from the results of the mount information query tool. The current mount source is compared with the expected mount source to obtain a first comparison result, and the current file system type is compared with the expected file system type to obtain a second comparison result. If both the first and second comparison results are successful, the mount operation is skipped, and a mount success is returned. If either the first or second comparison result fails, a mount conflict error is recorded, and a mount failure is returned.

6. The method for dynamically mounting container storage volumes as described in claim 3, characterized in that, The step of mounting based on the mounting parameters further includes: Based on the mount parameters, the target directory is recursively created within the container's mount namespace; Based on the container's mount namespace, PID namespace, and the target directory, standard file system mount operations are performed to mount the storage backend's mount source to the target path.

7. The method for dynamically mounting container storage volumes as described in claim 6, characterized in that, After the step of mounting the storage backend source to the target path, the method further includes: Based on the container's mount namespace, obtain the file system group identifier from the container group's security context; Based on the file system group identifier, recursively modify the file ownership group of the target directory within the container's mount namespace, and grant group access permissions corresponding to the file system group identifier; Based on the container's mount namespace, the security context label of the target directory is recursively set, and the security context label is used to allow the container process to access the target directory.

8. A container storage volume dynamic mounting device, characterized in that, The device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the container storage volume dynamic mounting method as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the container storage volume dynamic mounting method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the container storage volume dynamic mounting method as described in any one of claims 1 to 7.

Images