A method, medium and apparatus for dynamically mounting a file system in a container

Abstract

This invention relates to the field of container orchestration and storage mounting, and more particularly to a method, medium, and device for dynamically mounting a file system in a container. The method involves an execution module that completes the file system mounting and binding the injected path into the container on the host machine, allowing the mounting process to be completed under normal container conditions without destroying or rebuilding the container. It also provides a unified request interface for all file systems, all of which are injected into the container via binding, reducing the complexity of using different file systems. A proxy module handles mounting requests and forwards them to the execution module, which then calls the mounting program and completes the mounting. This transfers the core mounting operations to the proxy and execution modules, eliminating the need for any privileges or calling permissions within the container. This avoids the security risks associated with privileged containers compromising isolation, thus achieving the requirement for secure, unified, and convenient dynamic file system mounting without rebuilding the container or granting it privileges.

Description

Technical Field

[0001] This invention relates to the field of container orchestration and storage mounting, and in particular to a method, medium, and device for dynamically mounting a file system in a container. Background Technology

[0002] In modern application deployments based on container orchestration platforms such as Kubernetes, persistent storage mounting for Pods is a fundamental and critical requirement. Currently, mounting file systems typically relies on declaring Volume and VolumeMount in the Pod's YAML configuration file. This static declarative mounting method has the following inherent drawbacks: First, mounting operations are only performed when a Pod is created. Once a Pod is running, if new storage needs to be mounted or existing mounts changed, the Pod must be rebuilt. This rebuilding process interrupts the application services running within it, rendering it unavailable—unacceptable for production environments requiring high availability. Second, a common alternative for runtime dynamic mounting is using privileged containers. This involves granting containers privileged:true permissions or advanced Linux capabilities like SYS_ADMIN, allowing them to execute system-level commands like `mount` directly within the container. However, this approach significantly compromises the security isolation of containers. Furthermore, different file system types (such as NFS, CIFS, or JuiceFS distributed file systems) have unique mount commands, parameter formats, and client dependencies. This necessitates pre-packaging all possible mount tools and dependency libraries into the container image, increasing its complexity and size, and adding extra burden and complexity to operations and management.

[0003] For example, the invention patent "A Container Creation Method, System and Node" (publication number CN117827363A, publication date April 5, 2024) saves local storage space on the node by mounting the directory of the image file to remote storage before the container is created. The invention patent "A Container Operation Method, System and Storage Medium and Server" (publication number CN113590266B, publication date November 2, 2021) intercepts the container operation request by the container scheduling node to the container operation platform, and determines the processing time based on the extended parameters of the corresponding container. When the processing time arrives, the corresponding processing is performed based on the extended parameters of the corresponding container, thereby improving the efficiency and stability of container management. The two patents mentioned above are completely unsuitable if a new file system that was not declared at the time of creation needs to be mounted on a container that has already been created and is running. The only solution is still to rebuild the container, which cannot avoid service interruption. Furthermore, they focus on storage and management optimization of the container and do not cover how to safely perform mount operations within a running container. If this mode is to be extended to runtime dynamic mounting, it is still necessary to rely on privileged containers or grant high-level permissions to the container to execute mount commands. Moreover, they do not provide a unified mounting interface for heterogeneous file systems.

[0004] Therefore, existing technologies suffer from problems such as service interruption due to the need to rebuild the running container, security risks caused by the need for privileged permissions for dynamic mounting, and the complexity of mounting due to the diversity of file system types and the lack of a unified interface. How to provide a method that can securely, uniformly and conveniently implement dynamic mounting of file systems without rebuilding the container or granting privileges to the container has become an urgent problem to be solved. Summary of the Invention

[0005] To address the aforementioned technical problems, the present invention provides a method for dynamically mounting a file system in a container, the method comprising the following steps: S1, in response to the needs of the application within the target container, initiates a mount request for the target file system through the proxy module. The mount request includes at least the file system type, source address, and target mount path.

[0006] S2 forwards the mount request from the proxy module to the execution module on the host node.

[0007] S3 is the execution module that receives and parses the mount request, calls the mount program corresponding to the file system type, completes the mount of the target file system on the host machine's operating system, and obtains the mount path on the host machine.

[0008] S4: The execution module obtains the mount namespace of the target container through the container runtime interface, and injects the host mount path into the target mount path of the target container using the binding mount method.

[0009] The present invention also provides a non-transitory computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described method for dynamically mounting a file system in a container.

[0010] The present invention also provides an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0011] This invention offers at least the following advantages: By responding to the needs of applications within the target container, the proxy module initiates a mount request, eliminating the need to pre-configure mount settings before container creation. Applications within the container can trigger mounts at any time during runtime based on business requirements, avoiding the limitations of pre-planning configurations for new mounts. Furthermore, the execution module completes file system mounting and binding the mount injection container path on the host machine, ensuring the entire mounting process is completed while the container is running normally, without the need to destroy or rebuild the container. This completely avoids application service interruptions caused by mount operations. Additionally, it provides a unified request interface for all file systems, allowing applications within the container to focus on the differences between file systems without needing to worry about them; they only need to pass parameters in a fixed format. Regardless of the file system, the final result is always achieved through... By binding the mount method into the container, applications within the container access the mount path in a completely consistent manner, further reducing the complexity of applications using different file systems. A proxy module handles application mount requests and forwards them to the host execution module, transferring core mount operations from within the container to the host side. The target container does not need any privileges; it only needs to initiate requests through the proxy module. The execution module calls the mount program and obtains the mount namespace via the container runtime interface. All system-level operations are completed by the execution module, and the container has no system call permissions, avoiding the security risks of privileged containers breaking isolation. Thus, without rebuilding the container or granting it privileges, the requirement for dynamically mounting file systems is securely, uniformly, and conveniently achieved. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a method for dynamically mounting a file system in a container, as provided in Embodiment 1 of the present invention. Detailed Implementation

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

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It is understood that, where appropriate, the terms used to distinguish similar objects can be interchanged so that the invention can also be implemented in other embodiments besides the illustrated or described embodiments. Furthermore, the terms "including," "having," and any variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0016] Example 1 This embodiment provides a method for dynamically mounting a file system in a container, such as... Figure 1 As shown, the method includes the following steps: S1, in response to the needs of the application within the target container, initiates a mount request for the target file system through the proxy module. The mount request includes at least the file system type, source address, and target mount path.

[0017] The target container is the container where the application that initiated the mount request resides. The application's requirement within the target container is the access need to persistent storage or external storage generated by the business program (such as a data analysis program or a web application) running inside the target container during runtime, which serves as a trigger signal to start the entire dynamic mount process.

[0018] A proxy module is an auxiliary component deployed inside or closely adjacent to the target container. It can be a standalone sidecar container, a library integrated into the application code, or part of the host daemon, acting as an intermediary and protocol converter between the application and external execution modules.

[0019] The target file system is an external file system that the application wants to access but has not yet been mounted in the current container. It can be a variety of specific storage systems, such as NFS shared directories, JuiceFS based on object storage, CIFS / Samba shares, etc.

[0020] The mount request is a structured data object generated by the proxy module. It contains the most basic information required to successfully mount a file system. It serves as a communication contract and operational basis between the proxy module and the execution module, ensuring the accurate transmission of information.

[0021] The file system type specifies the type of the target file system, such as NFS, CIFS, JuiceFS, etc. The execution module can then determine which specific mount tool to call (e.g., / sbin / mount.nfs or the JuiceFS client) and how to parse other parameters based on the file system type.

[0022] The source address is used to locate the network location or access endpoint of the target file system, providing the target address for the mount operation.

[0023] The target mount path specifies a directory path inside the container, indicating the access location within the target container after the target file system is successfully mounted. Applications within the container can access the target file system by reading and writing files under the target mount path.

[0024] As described above, by triggering standardized mount requests through the application and encapsulating them with a proxy module, dynamic awareness and on-demand supply of storage needs are achieved. This frees mount operations from the strict restriction that they must be completed before container startup, avoiding application service interruptions caused by rebuilding Pods to mount new storage, and significantly improving business continuity and flexibility. By encapsulating diverse and complex file system mount commands and dependencies into a simple and unified general request structure, applications do not need to concern themselves with the underlying mount details, nor do they need to pre-install all possible client tools in the container image, greatly simplifying application development and container image maintenance complexity. By introducing a proxy module as an intermediary, privileged mount operations are isolated from ordinary application containers, making it possible to securely complete mounts in the target container without privileges, fundamentally eliminating dependence on privileged containers and improving overall security.

[0025] In one specific embodiment, S1 includes the following steps: S11, the proxy module verifies the validity of the parameters of the mounting request and obtains the verification result and error type. The verification result is either pass or fail, and the error type is either no error, missing parameters, or incorrect format.

[0026] S12, if the verification result is unsuccessful, the error type is reported back to the application in the target container to obtain a new mount request.

[0027] S13, repeat step S11 until the verification result is passed, and obtain the final mount request for the target file system.

[0028] The proxy module receives the original mount request from the application within the target container. Since the original mount request may have non-standard parameter formats (e.g., only transmitting the request to mount JuiceFS without providing the source address), it initiates parameter validity checks, including but not limited to existence checks, format checks, and preliminary security checks. These checks ensure that only requests with correct formats and basic validity are forwarded to the backend execution module, blocking invalid requests. For example, the existence check verifies whether all necessary parameters are provided and cannot be null or empty strings; the format check verifies whether the parameter format meets expectations, such as whether the source address contains valid characters, whether the target mount path starts with " / ", and whether the file system type is in the supported list; the preliminary security check checks whether the target mount path attempts to mount sensitive system directories (such as / etc, / bin).

[0029] If all parameters of the mount request pass the validation, the validation result is considered successful and the request can be forwarded to the execution module.

[0030] If one or more parameters in the mount request fail validation, the validation result is determined to be failed, and the request is invalid. By statistically analyzing the reasons for the failed validations, the error type is obtained. The proxy module then feeds back the error type as structured information to the target application in the container via a bidirectional communication channel (such as a gRPC interface or HTTP callback interface agreed upon with the application in the container), assisting the application in the target container to fix the problem in a targeted manner.

[0031] Error types include, but are not limited to, no error, missing parameters, and format errors. Specifically, if the validation result is successful, the error type is no error; if the validation result is unsuccessful and necessary request fields are missing, such as a missing source address or file system type, the error type is missing parameters; if the validation result is unsuccessful and the parameter values ​​exist, but their format does not meet the requirements, such as a garbled string for the source address or a relative path data / mount for the target mount path, the error type is format errors.

[0032] After receiving the error feedback, the application inside the target container corrects the parameter issues according to the error type and re-initiates the mount request to the proxy module.

[0033] As described above, by implementing parameter validation and establishing a feedback loop within the proxy module, early interception of errors is achieved, avoiding invalid requests from consuming network bandwidth and the computing resources of the execution module, and significantly improving the processing efficiency of the backend execution module and the resource utilization of the entire system.

[0034] S2 forwards the mount request from the proxy module to the execution module on the host node.

[0035] In one specific embodiment, S2 includes the following steps: S21. Obtain the list of host nodes and the deployment status of each execution module on each host node through the API interface of the container orchestration platform, wherein the deployment status is either running or not running.

[0036] S22, determine the host node where the target container is located as the target node.

[0037] S23, based on the deployment status of each execution module on each host node, match the execution modules that are running on the target node.

[0038] S24, the mount request is encrypted and transmitted to the matching execution module through a preset protocol.

[0039] The container orchestration platform's API interface is a programming interface provided by the platform for managing and querying cluster status. By calling this interface, the proxy module can obtain the most real-time and accurate node and Pod (execution module) information in the cluster, eliminating the need to maintain its own service discovery system.

[0040] The host node list is a collection of all worker nodes in the current cluster, obtained from the API interface. Each node is typically represented by a unique identifier, such as a node name or IP address.

[0041] The deployment status of execution modules refers to the current running status of execution modules deployed on each host node in the form of DaemonSets, etc. A running status indicates that the execution module Pod is in a normal, running state and can receive and process requests. A non-running status indicates that the execution module Pod may be in an abnormal state such as Pending, Failed, Succeeded, Unknown, or CrashLoopBackOff, and cannot reliably process requests. Specifically, Pending indicates that the Pod has been accepted by the system, but the container image has not yet been downloaded or node resources are insufficient; Failed indicates that the containers in the Pod have terminated, and at least one container exited abnormally; Succeeded indicates that the containers in the Pod have successfully completed execution and exited; Unknown indicates that the Pod's status cannot be obtained; CrashLoopBackOff indicates that the container is continuously failing to start and is retrying.

[0042] Therefore, for several execution modules corresponding to the target node, the execution modules that are running on the target node are matched by the deployment status. Then, the mount request is encrypted and transmitted to the matching execution module through a preset protocol (such as gRPC or HTTPS). The encryption method can be TLS encryption corresponding to gRPC or SSL / TLS encryption corresponding to HTTPS to ensure that sensitive information in the mount request (such as authentication information contained in the source address) is not leaked.

[0043] As described above, by directly querying the container orchestration platform, the status of nodes and execution modules is automatically obtained, enabling the proxy module to dynamically and accurately locate healthy service endpoints. This avoids the tediousness and errors of manually configuring service addresses, greatly improving the system's automation level. By identifying the host node where the target container resides as the target node and performing local matching, all mount request communication occurs within the node, avoiding bandwidth consumption and network latency across network nodes, significantly improving the response speed of mount operations and the overall system processing efficiency. By checking the deployment status of execution modules, it is ensured that requests are only sent to healthy execution modules. At the same time, an encrypted transmission channel adds a critical security protection layer to the system, meeting the security compliance requirements of the production environment.

[0044] In one specific implementation, the container orchestration platform is a Kubernetes platform, and the agent module obtains the list of host nodes and the deployment status of the execution modules on each host node through the Node API interface and Pod API interface of the Kubernetes platform.

[0045] Among them, the Kubernetes platform is an open-source, production-grade container orchestration system used to automate the deployment, scaling, and management of containerized applications. It provides various abstract resources centered around Pods, such as Node, Deployment, DaemonSet, and Service. In this embodiment, it provides the source of all API interfaces and resource status information.

[0046] The Node API is a dedicated endpoint in the Kubernetes API for managing and querying node resources. By calling the Node API (e.g., / api / v1 / nodes), you can list all worker nodes in the cluster and obtain detailed information for each node, such as node name, IP address, tag, resource capacity, and current condition status.

[0047] The Pod API is a dedicated endpoint in the Kubernetes API for managing and querying Pod resources. Through the Pod API, you can retrieve detailed information about all Pods within a specific namespace, including the Pod name, the node it resides on, its status, and its associated tag.

[0048] The agent module uses the Pod API to filter and query all Pods with execution module-specific tags (such as app=storage-agent). For each Pod found, it checks its status.phase to see if it's Running and its container ready state to determine its deployment status, i.e., running or not. By examining the Pod's spec.nodeName field, it can pinpoint exactly which Pod is running on which node, thus completing the mapping between nodes and execution module instances.

[0049] In Kubernetes, the deployment status of a Pod is a comprehensive reflection of its Pod Status. When the Pod's status.phase is Running, and all containers' readiness probes detect success, it indicates that the Pod has been successfully scheduled onto the node, and its internal containers are running normally and can receive network traffic. Then, its corresponding execution module is matched for subsequent tasks.

[0050] As described above, by directly utilizing Kubernetes as the data source for cluster status, the proxy module can dynamically, in real time, and accurately perceive the health status of cluster node topology and execution modules, completely avoiding static configuration and greatly improving the reliability and maintainability of the system in dynamic cluster environments.

[0051] S3 is the execution module that receives and parses the mount request, calls the mount program corresponding to the file system type, completes the mount of the target file system on the host machine's operating system, and obtains the mount path on the host machine.

[0052] In one specific embodiment, S3 includes the following steps: S31, the execution module parses the mount request and matches the corresponding plugin module from the preset plugin directory according to the parsed file system type.

[0053] S32, the matched plugin module processes the parsed source address and generates a mount command that meets the requirements of the target file system.

[0054] S33 creates a unique subdirectory in the host machine's temporary directory as the host machine's mount path, and fills the mount path as a parameter into the mount command.

[0055] S34 executes the mount command and confirms the completion status of the mount operation by calling the return code through the monitoring system.

[0056] S35, if the return code is 0, the mounting operation is considered successful, and an available host mounting path is obtained.

[0057] The plugin directory, located at a specified path in the execution module's configuration file (e.g., / opt / agent / plugins / ), stores all plugin files. The plugin directory supports hot-swapping, meaning it allows for the dynamic addition, removal, or updating of plugin modules without stopping or restarting the execution module's main process. The execution module periodically scans the plugin directory or listens for file system events to load new plugins, improving flexibility and maintainability.

[0058] The execution module parses the file system type key field in the mount request and uses it as a lookup key to match it in the preset plugin directory to find the plugin module that can handle this type of request.

[0059] The plugin module translates generic, abstract mount request parameters into concrete command-line instructions that the underlying operating system can understand and execute, thereby generating mount commands. Specifically, the plugin module validates the source address in the mount request, checking things like the IP address format and shared directory path of the NFS address, and the database connection format of the JuiceFS address. Then, based on the mount command specifications of the target file system, it combines the source address with default parameters (such as the NFS mount version and the JuiceFS cache path) to generate a mount command that can be directly executed on the host machine. The source address processing includes source address format validation, parameter completion, and encryption of sensitive information to ensure that the source address meets the file system mount requirements while preventing the leakage of sensitive information.

[0060] To ensure that each mount operation is isolated, does not affect others, and is easy to clean up later, the execution module creates a unique subdirectory in the host machine's temporary directory using a naming convention of random string + timestamp. This subdirectory is the host machine mount path, ensuring that mount paths for different file systems do not conflict. Then, this host machine mount path is used as a parameter to replace the target path placeholder in the mount command, generating the final executable complete mount command.

[0061] Furthermore, the execution module executes the final mount command on the host machine via Linux system calls, while simultaneously starting a monitoring thread to capture the system call return codes corresponding to the mount command in real time. The return code is the core identifier for the operating system to report the command execution result; different values ​​represent different states, such as return code 0 indicating successful execution, return code 1 indicating parameter errors, and return code 32 indicating the source address is unreachable.

[0062] The monitoring thread continuously waits for the command execution to complete and obtain the return code to prevent the mount command from blocking subsequent processes. If the return code is 0, it is determined that the target file system has been successfully mounted to the host machine mount path, which has read and write access capabilities from this moment on and can be used for subsequent operations injected into the container. If the return code is not 0, an error message is generated according to the error type corresponding to the return code (such as parameter error, source address unreachable), and fed back to the agent module. The agent module then notifies the application in the container that the mount has failed and deletes the created temporary subdirectory on the host machine to avoid invalid paths occupying resources.

[0063] As described above, the plug-in module matching mechanism can flexibly adapt to multiple file systems, adding file system support without modifying the core code of the execution module, greatly improving system scalability. By processing the source address and generating mount commands through plug-in modules, the mount parameter verification and command generation logic of the file system are decoupled from the execution module. The dedicated logic of each file system is handled by the corresponding plug-in module, reducing the maintenance complexity of the execution module. At the same time, it ensures that the mount commands conform to the specifications of each file system, reducing mount failures caused by command format errors. By creating a unique host temporary subdirectory, the host path of different mount tasks does not conflict, avoiding mount overwriting or data corruption caused by duplicate paths. By monitoring the return code of system calls, the reliability of mount result determination is improved.

[0064] S4: The execution module obtains the mount namespace of the target container through the container runtime interface, and injects the host mount path into the target mount path of the target container using the binding mount method.

[0065] In one specific embodiment, S4 includes the following steps: S41, the execution module queries the runtime status of the target container through the container runtime interface, where the runtime status includes the running state and other states.

[0066] S42, when the runtime status is confirmed to be running, obtain the file descriptor of the mount namespace corresponding to the target container on the host machine.

[0067] S43, based on the file descriptor, uses the setns system call to switch the currently executing thread into the target container's mount namespace and obtain file system operation permissions within the mount namespace.

[0068] S44. If the target mount path exists within the mount namespace, verify that the file system operation permissions have the correct directory structure and access permissions.

[0069] S45. If the target mount path does not exist in the mount namespace, create the target mount path and set the permission attributes consistent with the host mount path.

[0070] S46 uses the mount system call to perform a binding mount operation, associating the mounted storage path on the host machine with the target mount path inside the target container.

[0071] S47, the execution thread is switched back to the original namespace via the setns system call, and the file descriptor of the mounted namespace is closed.

[0072] S48, send mount response information to the agent module, wherein the mount response information includes mount result status, accessible mount path, mount timestamp and mount identifier information.

[0073] Among them, the container runtime interface (such as CRI) is a standardized interface between the container orchestration platform and the container runtime (such as containerd, Docker), defining the communication specifications for core operations such as creating, querying, and destroying containers. The execution module can obtain container information across runtimes through the container runtime interface, eliminating the need to develop dedicated query logic for different runtimes and ensuring system compatibility.

[0074] The execution module first determines the target container for which the mount path needs to be injected. By calling the container runtime interface and passing in identification information such as the container name or tag, it queries and obtains the unique identifier container ID of the target container for precise location. At the same time, it obtains the current runtime status of the target container (such as running, stopped, terminated, or pending startup). If the running status is not running, subsequent mount injection operations are paused to avoid injecting invalid paths into containers that cannot function properly.

[0075] Once the target container is confirmed to be running, the execution module obtains the process ID (PID) of the target container, i.e., the ID of the initialization process within the container, through the container runtime interface. Then, in the host machine's ` / proc` filesystem, it locates the directory corresponding to this PID (e.g., ` / proc / 1234`), and the `ns / mnt` file within it (i.e., ` / proc / 1234 / ns / mnt`) is the target container's mount namespace file. The mount namespace file is a special file in Linux that represents a mount namespace, storing metadata about the file system mount points within that namespace, such as mount path, file system type, and mount permissions. By manipulating the mount namespace file, processes can switch between different mount namespaces, making it the core carrier of container file system isolation.

[0076] The execution module first opens the target container's mount namespace file ( / proc / 1234 / ns / mnt) and obtains its file descriptor (e.g., fd=5), which is used to identify the mount namespace file in the program. Then, it calls the Linux system call `setns`, passing in the file descriptor and the `CLONE_NEWNS` parameter, which indicates that the mount namespace is being switched. After a successful call, the execution module's current worker process enters the target container's mount namespace. At this point, the filesystem view seen by the process is completely consistent with that seen by the application inside the target container, such as the ` / data` path within the target container, rather than the ` / data` path on the host machine.

[0077] The execution thread checks whether the target mount path (e.g., / data / storage) exists within the target container's mount namespace using the stat() system call. If it exists, the execution thread further verifies two aspects: first, the directory structure validity, confirming that the target mount path is a directory rather than a file to avoid data loss due to binding and overwriting existing files, and that the parent directory hierarchy of the path is complete (e.g., if / data already exists, / data / storage is a valid subdirectory); second, access permission matching, that is, obtaining the permission attributes of the target mount path (e.g., rwxr-xr-x) using getfacl() or stat() and comparing them with the permissions of the host machine mount path to ensure consistency. If the host machine path is read-only, the path inside the container must also be read-only to avoid permission denial errors when the application accesses it later.

[0078] If the `stat()` system call returns a non-existent path, the execution thread creates the target mount path using the `mkdir -p` command. The `-p` parameter ensures that if the parent directory (e.g., ` / data`) does not exist, it will be automatically created to avoid creation failure due to a missing parent directory. For example, when directly creating ` / data / storage`, if ` / data` does not exist, `mkdir -p` will create ` / data` first, and then create ` / data / storage`. After the path is created, the thread calls the `chmod()` system call to set the permission attributes of the target mount path within the target container to be exactly the same as the host machine mount path, ensuring that subsequent application access permissions are normal.

[0079] Within the container's mount namespace, the execution module executes the command `mount --bind host-mount path target mount path inside the container` (e.g., `mount --bind / var / lib / dynamic-mounts / mnt-678 / data / juicefs`). This bind mount maps the file system from the host path to the container path, ensuring both point to the same storage data. Modifications to files on the host path are synchronized to the container path, and vice versa. Furthermore, it eliminates the need to remount the entire file system; only the path association needs to be established, resulting in extremely high efficiency. After binding, the execution module calls the `setns` system call to switch back to the host mount namespace or exits the current process, avoiding continuous occupation of the container's namespace resources.

[0080] The execution thread calls the `mount()` system call within the target container's mount namespace, passing in four core parameters: mount type set to `bind`, source path set to the host mount path, target path set to the target mount path, and mount option set to `MS_BIND`. Upon successful call, a mapping is established between the host mount path and the target mount path, meaning both point to the same storage data block. File modifications on the host mount path are synchronized to the target mount path in real time, and vice versa. Furthermore, there's no need to remount the entire file system; only the path association needs to be established, making the operation extremely time-consuming.

[0081] After the mount operation is complete, the execution thread first calls the `setns` system call, passing in the file descriptor of the host machine's original namespace (pre-saved in the execution module process), and switches back to the host machine's default mount namespace. This ensures that subsequent thread operations (such as handling mount requests from other containers) do not inadvertently affect the target container's file system. Subsequently, the thread calls the `close()` system call to close the target container's mount namespace file descriptor, releasing this process-level resource and preventing file descriptor leaks. If it is not closed for an extended period, the execution module may run out of available file descriptors and be unable to handle new mount requests.

[0082] The original namespace is the host machine's mount namespace where the execution module process defaults to when it starts, containing a complete view of the host machine's file system. Switching back to the original namespace is a necessary step to ensure the normal operation of the execution module and to prevent functional abnormalities caused by threads being in the container's namespace for an extended period.

[0083] After switching back to the original namespace and closing the file descriptors, the execution module organizes all information from this mount operation, generates standardized mount response information, and sends it to the agent module via a preset communication protocol. Specifically, the execution module extracts core data from the local operation log, confirms the execution result (success / failure) of the binding mount as the mount result status; extracts the accessible target mount path within the container as the accessible mount path; records the system time of completing the binding mount as the mount timestamp; and generates a unique identifier composed of the container ID, file system type, and a random string as the mount identifier information.

[0084] If the mount is successful, the response message will also include the host machine mount path association for subsequent uninstallation operations; if the mount fails, the error code and error reason will be provided, such as EACCES - insufficient permissions, to help the proxy module locate the problem.

[0085] The execution module sends the response information to the agent module through an encrypted communication channel to ensure that the data is not tampered with or stolen during the data transmission process. After receiving the response, the agent module will further feed back the mount result status and accessible mount path to the application in the target container, informing it whether the file system can be accessed normally.

[0086] As described above, by using an independent execution thread to enter the namespace, the main thread of the execution module can handle other mount requests normally, improving system processing efficiency; by explicitly obtaining and closing the mount namespace file descriptors, file descriptor leakage is avoided, ensuring that the execution module's resources are not exhausted during long-term operation, while preventing other processes from illegally accessing the target container's mount namespace, thus improving system security; by directly executing the binding mount by calling the mount system call, compared to executing the mount--bind command, the overhead of process creation and destruction is reduced, improving the real-time performance of mount injection; by refining the permission verification and setting steps, the permissions of the target mount path in the container are ensured to be completely consistent with those of the host machine, completely avoiding application access errors caused by permission mismatches, reducing operation and maintenance troubleshooting costs, and improving business continuity; by sending standardized mount response information to the proxy module, the proxy module can clearly obtain the complete result of the mount operation, avoiding the problem of unknown mount status due to missing information, and providing data support for the proxy module to feed back results to the application in the container, ensuring a closed loop in the process of mount request and result feedback.

[0087] In one specific embodiment, the method for dynamically mounting a file system in the container further includes the following steps: S5 periodically checks whether the target container exists through the container runtime interface.

[0088] S6. If the target container has been destroyed, unbind the mount, unmount the target file system on the host machine's operating system, and delete the temporary directory.

[0089] After sending the mount response information, the execution module creates a lifecycle monitoring task for this mount operation and adds it to a periodic scheduling queue, such as based on Linux cron or a custom timer. Specifically, the execution module extracts the target container ID from the mount identification information as the core basis for periodic checks; it also presets the check period, typically from 30 seconds to 5 minutes, which can be configured according to business needs, such as setting it to 30 seconds for high resource-sensitive scenarios and 5 minutes for ordinary scenarios.

[0090] When each inspection cycle is triggered, the execution module sends a container existence query request to the container runtime through the container runtime interface, passing in the target container ID to obtain the current existence status of the container. This existence status is divided into existence, which means that the container is running normally or has stopped but not destroyed, and destruction, which means that the container has been deleted and there is no record of the container in the container runtime.

[0091] The execution module associates each inspection result (inspection time, container existence status) with the corresponding mount identification information and stores it in the local database or cache to form an audit log of the mount lifecycle, which facilitates subsequent traceability and problem investigation.

[0092] When the target container is detected to have been destroyed, the execution module triggers a resource reclamation process. Based on historical data associated with the mount identifier information (such as the host mount path, target mount path, and file system type), it performs operations such as unbinding the mount, unmounting the target file system on the host, deleting temporary directories, and cleaning up monitoring tasks and logs. This end-to-end control of mount-monitoring-reclamation better meets the stringent requirements of production environments for system stability and resource utilization.

[0093] As described above, by responding to the needs of the application within the target container, the proxy module initiates a mount request. There's no need to pre-configure mount settings before container creation; the application within the container can trigger mounts at any time during runtime based on business needs, avoiding the limitations of pre-planning and configuring new mounts. The execution module completes the file system mount and bind the injected container path on the host machine, ensuring the entire mount process is completed while the container is running normally. This eliminates the need to destroy or rebuild the container, completely preventing application service interruptions caused by mount operations. Furthermore, a unified request interface is provided for all file systems, allowing applications within the container to focus on the differences between file systems without needing to worry about them. They only need to pass parameters in a fixed format, and regardless of the file system, the final mount is achieved through binding. By injecting into the container, applications within the container access the mount path in a completely consistent manner, further reducing the complexity of applications using different file systems. A proxy module handles application mount requests and forwards them to the host execution module, transferring core mount operations from within the container to the host side. The target container does not need any privileges; it only needs to initiate requests through the proxy module. The execution module calls the mount program and obtains the mount namespace via the container runtime interface. All system-level operations are completed by the execution module, and the container has no system call permissions, avoiding the security risks of privileged containers breaking isolation. Thus, without rebuilding the container or granting it privileges, the need for dynamically mounting file systems is securely, uniformly, and conveniently achieved.

[0094] Example 2 Embodiment 2 of the present invention provides a non-transitory computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiment. The at least one instruction or at least one program is loaded and executed by the processor to implement the method of dynamically mounting a file system in a container provided in the above embodiment.

[0095] Example 3 Embodiment 3 of the present invention provides an electronic device, which includes a processor and the non-transitory computer-readable storage medium of Embodiment 2 of the present invention.

[0096] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for dynamically mounting a file system in a container, characterized in that, The method includes the following steps: S1, in response to the needs of the application within the target container, initiates a mount request for the target file system through the proxy module, wherein the mount request includes at least the file system type, source address, and target mount path; S2, the mounting request is forwarded by the proxy module to the execution module on the host node; S3, the execution module receives and parses the mount request, calls the mount program corresponding to the file system type, completes the mount of the target file system on the host machine's operating system, and obtains the host machine mount path; S4, the execution module obtains the mount namespace of the target container through the container runtime interface, and injects the host mount path into the target mount path of the target container using the binding mount method.

2. The method for dynamically mounting a file system in a container according to claim 1, characterized in that, S1 includes the following steps: S11, the proxy module verifies the validity of the parameters of the mounting request and obtains the verification result and error type, wherein the verification result is pass or fail, and the error type is no error, missing parameters or format error; S12, If the verification result is unsuccessful, the error type is fed back to the application in the target container to obtain a new mounting request; S13, repeat step S11 until the verification result is passed, and obtain the final mount request for the target file system.

3. The method for dynamically mounting a file system in a container according to claim 1, characterized in that, S2 includes the following steps: S21. Obtain the list of host nodes and the deployment status of each execution module on each host node based on the API interface of the container orchestration platform, wherein the deployment status is either running or non-running. S22, the host node where the target container is located is determined as the target node; S23, Match the execution modules that are running on the target node according to the deployment status of each execution module on each host node; S24, the mounting request is encrypted and transmitted to the matching execution module through a preset protocol.

4. The method for dynamically mounting a file system in a container according to claim 3, characterized in that, The container orchestration platform is a Kubernetes platform. The proxy module obtains the list of host nodes and the deployment status of the execution modules on each host node through the NodeAPI and PodAPI interfaces of the Kubernetes platform.

5. The method for dynamically mounting a file system in a container according to claim 1, characterized in that, S3 includes the following steps: S31, the execution module parses the mount request and matches the corresponding plugin module from the preset plugin directory according to the parsed file system type; S32, the matched plug-in module processes the parsed source address to generate a mount command that meets the requirements of the target file system; S33, create a unique subdirectory in the host machine's temporary directory as the host machine's mount path, and fill the mount path as a parameter into the mount command; S34, Execute the mount command and confirm the completion status of the mount operation by calling the return code through the monitoring system; S35, if the return code is 0, the mounting operation is considered successful, and an available host mounting path is obtained.

6. The method for dynamically mounting a file system in a container according to claim 5, characterized in that, The method further includes the following steps: S5, periodically check whether the target container exists through the container runtime interface; S6. If the target container has been destroyed, unbind the mount, unmount the target file system on the host machine's operating system, and delete the temporary directory.

7. The method for dynamically mounting a file system in a container according to claim 1, characterized in that, S4 includes the following steps: S41, the execution module queries the runtime status of the target container through the container runtime interface, wherein the runtime status includes the running status and other statuses; S42, when it is confirmed that the runtime state is running, obtain the file descriptor of the mount namespace corresponding to the target container on the host machine; S43, Based on the file descriptor, the current execution thread is switched to the mount namespace of the target container through the setns system call to obtain file system operation permissions within the mount namespace; S44, if the target mount path exists in the mount namespace, then verify whether the file system operation permissions have the correct directory structure and access permissions; S45, if the target mount path does not exist in the mount namespace, then create the target mount path and set the permission attributes consistent with the host mount path; S46, Use the mount system call to perform a binding mount operation, associating the storage path already mounted on the host machine with the target mount path in the target container; S47, the execution thread is switched back to the original namespace via the setns system call, and the file descriptor of the mounted namespace is closed.

8. The method for dynamically mounting a file system in a container according to claim 7, characterized in that, S4 also includes the following steps: S48, send mount response information to the agent module, wherein the mount response information includes mount result status, accessible mount path, mount timestamp and mount identifier information.

9. A non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the method of dynamically mounting a file system in a container as described in any one of claims 1-8.

10. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 9.

Images