Azure Kubernetes中NFS VolumeMount subPath始终指向根目录问题

我在Azure环境中用Kubernetes通过Azure NFS文件共享创建了Persistent Volume（PV），想要把NFS里的多个子目录挂载到Pod的不同路径，但用volumeMount的subPath选项时，所有挂载路径都指向PV的根目录，达不到预期效果。

PV和PVC配置 #

apiVersion: v1
kind: PersistentVolume
metadata:
  name: file-share
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: {server info}
    path: /path-inside-file-share
  mountOptions:
    - vers=4
    - minorversion=1
    - noac
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: file-share
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 100Gi
  volumeName: file-share

Deployment配置 #

apiVersion: apps/v1
kind: Deployment
metadata:
  name: debug
spec:
  replicas: 1
  selector:
    matchLabels:
      app: debug
  template:
    metadata:
      labels:
        app: debug
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
      - name: debug
        image: docker.io/ubuntu
        command: ["/bin/sh"]
        args:
        - -c
        - >- 
            tail -f /dev/null

        volumeMounts:
        - name: file-share
          mountPath: /test/root

        - name: file-share
          mountPath: /test/foo1
          subpath: foo/
          
        - name: file-share
          mountPath: /test/foo2
          subpath: /foo/

        - name: file-share
          mountPath: /test/foo3
          subpath: /path-inside-file-share/foo/
          
        - name: file-share
          mountPath: /test/foo4
          subpath: foo

        - name: file-share
          mountPath: /test/foo5
          subpath: /foo

        - name: file-share
          mountPath: /test/foo6
          subpath: /path-inside-file-share/foo

      volumes:
      - name: file-share
        persistentVolumeClaim:
          claimName: file-share

测试结果 #

我尝试了各种斜杠组合和路径写法，所有以foo开头的挂载目录内容都和根目录完全一致。PV根目录下确实存在名为foo的子目录，但挂载后并未指向该子目录：

root@debug-65668dcf88-qnxtm:/# cd test/
root@debug-65668dcf88-qnxtm:/test# ls
foo1  foo2  foo3  foo4  foo5  foo6  root
root@debug-65668dcf88-qnxtm:/test# ls root/
bar  foo  test.txt
root@debug-65668dcf88-qnxtm:/test# ls foo1  
bar  foo  test.txt
root@debug-65668dcf88-qnxtm:/test# ls foo2  
bar  foo  test.txt
root@debug-65668dcf88-qnxtm:/test# ls foo3  
bar  foo  test.txt
root@debug-65668dcf88-qnxtm:/test# ls foo4  
bar  foo  test.txt
root@debug-65668dcf88-qnxtm:/test# ls foo5  
bar  foo  test.txt
root@debug-65668dcf88-qnxtm:/test# ls foo6  
bar  foo  test.txt
root@debug-65668dcf88-qnxtm:/test#

另外，我跳过PV直接挂载NFS驱动器做了同样测试，结果还是一样。

疑问 #

我是不是漏了什么配置项？Azure NFS文件共享是不是不支持subPath挂载子目录的功能？

解答 #

这是Azure NFS文件共享的已知限制：Azure NFS 4.1文件共享不支持subPath选项，不管是通过PV/PVC挂载还是直接挂载NFS，都会出现这个问题。

解决方法有两个：

• 为每个需要挂载的子目录单独创建PV/PVC：每个PV的nfs.path直接指向NFS共享里的对应子目录，比如要挂载foo子目录，PV的path就设为/path-inside-file-share/foo，然后在Deployment里用不同的PVC分别挂载到Pod的不同路径。
• 在Pod启动脚本中手动挂载子目录：先将整个NFS共享挂载到Pod的一个临时路径，然后在容器启动命令里通过mount --bind将子目录绑定到目标路径，示例命令如下：

  tail -f /dev/null &
  mount --bind /test/root/foo /test/foo1
  wait
  

  注意这种方式需要容器拥有CAP_SYS_ADMIN权限，或者在Deployment的securityContext里设置privileged: true。

内容的提问来源于stack exchange，提问作者Dalton Baker