Mount NFS volumes in containers & Pods

Mount nfs in the container

running container

docker ps | grep cmdb
docker inspect 17ecedc669e6 | grep -i merged
cd /var/lib/docker/overlay2/649696272be1e9073ed8afd085c77b31e3423e93ead825f172f476be46eab8da/merged
mkdir nfs1
mount -t nfs x.x.x.5:/backup/nfs nfs1
docker exec -it 17ecedc669e6 bash
ls /nfs1

mount at runtime

docker run --mount type=volume,source=/path/to/shared/directory,target=/mnt/nfs,volume-driver=local,volume-opt=type=nfs,volume-opt=device=IP_ADDRESS:/path/to/shared/directory,readonly mycontainer

Mount in Pod

apiVersion: v1
kind: Pod
metadata:
  name: nfs-pod
spec:
  containers:
    - name: app-container
      image: your-image
      volumeMounts:
        - mountPath: /path/to/mount
          name: nfs-volume
  volumes:
    - name: nfs-volume
      nfs:
        server: nfs-server-ip
        path: /path/on/nfs/server

GraphDriver

GraphDriver": {
    
    
            "Data": {
    
    
                "LowerDir": "/var/lib/docker/overlay2/b47eed97a959e733f2f5583d689a884d4d8c73f510872b0b1ba429140b8a8d49-init/diff:/var/lib/docker/overlay2/2fb3706abf15c0aef48416ff665012d38d6c7692a16245ac570d14d1df3a8c9e/diff:/var/lib/docker/overlay2/18f09190247c06ef5cb98494b5919f94cedd3a38a1a822dcbe319447a456825f/diff:/var/lib/docker/overlay2/e11e2abdfe4bd69b64f42b9f127be980e3cd1491ef70ea8e3bb9420b4a8ffeef/diff",
                "MergedDir": "/var/lib/docker/overlay2/b47eed97a959e733f2f5583d689a884d4d8c73f510872b0b1ba429140b8a8d49/merged",
                "UpperDir": "/var/lib/docker/overlay2/b47eed97a959e733f2f5583d689a884d4d8c73f510872b0b1ba429140b8a8d49/diff",
                "WorkDir": "/var/lib/docker/overlay2/b47eed97a959e733f2f5583d689a884d4d8c73f510872b0b1ba429140b8a8d49/work"
            },
            "Name": "overlay2"

This code is an example of Docker's GraphDriver configuration. GraphDriver is used to manage the storage and file system of Docker containers.

The "Data" field contains four subfields:
- "LowerDir": The bottom directory, which contains the read-only content of the mirror layer.
- "MergedDir": The merged directory, which contains the merged results of the image layer and the container layer.
- "UpperDir": The upper directory, which contains the writable content of the container.
- "WorkDir": working directory, used for temporary file operations.
The "Name" field specifies the driver type to use, here is "overlay2". Overlay2 is a Docker storage driver that provides high performance and low storage overhead on Linux systems.

The paths in this example are all for the default location where Docker is stored on the host. These paths are used to manage the container's filesystem and ensure changes to the container are properly recorded and stored.

Union File System

Docker uses the Union File System (Union File System) to separate the image layer of the container from the container layer. This file system consists of four main directories:

LowerDir (underlying directory): It contains the read-only content of the image layer. The image layer contains the operating system and basic applications, etc., and can be shared by multiple containers. When multiple containers run the same image, they share the same underlying directory.
MergedDir (Merged Directory): It is the merged result of the underlying directory and the upper directory. In this directory, the files and directories of the lower and upper directories are merged into a single view. In this way, the container can see all files and directories in the underlying directory and the upper directory.
UpperDir (upper directory): It contains the writable content of the container. When the file is written in the container, these modifications will be saved in the upper directory. This makes the previous modifications persist after the container is restarted. Upper-level directories are associated with each container instance, so upper-level directories are independent between different containers.
WorkDir (working directory): It is used for temporary file operations. Containers may need to create temporary files during execution, and these files are usually located in the working directory. The contents of this directory are writable while the container is running, but are not saved.

The design of this union file system allows containers to share the underlying image and provides a lightweight and efficient way to manage writable content of containers. It allows files to be shared between containers, saves storage space, and provides consistency and isolation. Each container can have its own upper-level directory, so that each container can maintain its own state and modification.

Mount Namespace

Mount Namespace (mount namespace) is an isolation mechanism in the Linux kernel that allows processes to run in an independent mounting environment, providing an independent view of the file system mount point. This concept was first proposed by Linux container technology and became part of the Linux namespace.

In a traditional Linux system, all processes share the same mount namespace. This means that the operation of a process on the file system will affect the access of other processes, and may even cause system instability. The introduction of Mount Namespace solves this problem, so that each process has its own independent mount namespace.

The creation and management of Mount Namespace clone()is implemented through system calls. When a process calls clone()create new, CLONE_NEWNSflags can be specified to create a new Mount Namespace. This new Namespace will inherit the existing mount point information of the parent process, but can be modified and added in the new Namespace.

Through Mount Namespace, a process can perform the following operations on the file system without affecting other processes:

Mount and unmount filesystems : Processes can mount filesystems privately or sharedly to specified directories without affecting mount points in other namespaces.
View mount information : The process can obtain mount point information in the current namespace, including the type of the mounted file system, source path, and target path.
Modify mount options : A process can modify the mount options of an existing mount point, such as setting read-only permissions or remounting to update the options.

The application scenarios of Mount Namespace are mainly containerization technology (such as Docker, LXC, etc.) and virtualization technology, which provides an isolated file system environment for each container or virtual machine. This isolation enables each process to safely manipulate the file system in its own mount namespace, while increasing the flexibility and reliability of the system.
mount namespace

lsns -t mnt