使用Helm Release.Name作为PV的shareName值时Azure File挂载失败求助

问题场景 #

使用Helm管理Kubernetes PersistentVolume时，硬编码Azure File共享子路径可正常自动创建文件夹并挂载，但替换为Helm模板变量（{{ .Release.Name }}）后出现挂载失败。

PV模板代码 #

{{ if .Values.useSystemFilesPV}}
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mono-pv-{{ .Release.Name }}
spec:
  capacity:
    storage: {{ .Values.pvStorage }}
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  azureFile:
    secretName: mono
    secretNamespace: {{ .Release.Name }}
    shareName: mono-sua-tst-man-yv/idit-core-pen  # 硬编码时正常工作
    # shareName: mono-sua-tst-man-yv/{{ .Release.Name }}  # 使用变量时挂载失败
    readOnly: false
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=1000
    - gid=1000
    - mfsymlinks
    - nobrl
{{ end }}

挂载错误信息 #

MountVolume.MountDevice failed for volume "mono-pv-idit-core-pen" : rpc error: code = Internal desc = volume(#mono#mono-sua-tst-man-yv/idit-core-pen#mono-pv-idit-core-pen#idit-core-pen) mount //euaidtcoretrunkaks.file.core.windows.net/mono-sua-tst-man-yv/idit-core-pen on /var/lib/kubelet/plugins/kubernetes.io/csi/pv/mono-pv-idit-core-pen/globalmount failed with mount failed: exit status 32 Mounting command: mount Mounting arguments: -t cifs -o dir_mode=0777,file_mode=0777,uid=1000,gid=1000,mfsymlinks,nobrl,actimeo=30, //euaidtcoretrunkaks.file.core.windows.net/mono-sua-tst-man-yv/idit-core-pen /var/lib/kubelet/plugins/kubernetes.io/csi/pv/mono-pv-idit-core-pen/globalmount Output: mount error(2): No such file or directory

原因分析 #

Azure File CSI驱动仅会对静态硬编码的子路径自动创建不存在的文件夹；当shareName包含动态渲染的模板变量时，驱动无法识别需要创建的目标子目录，仅尝试挂载已存在的路径，导致"文件不存在"错误。

解决方案 #

方案1：通过Helm钩子提前创建子文件夹（推荐） #

将子文件夹创建逻辑集成到Helm部署流程中，在PV创建前自动执行：

1. 创建钩子Job文件templates/hooks/create-azure-subdir.yaml：

apiVersion: batch/v1
kind: Job
metadata:
  name: create-azure-file-subdir
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-weight": "1"
    "helm.sh/hook-delete-policy": hook-succeeded,hook-failed
spec:
  template:
    spec:
      containers:
      - name: az-cli
        image: mcr.microsoft.com/azure-cli:latest
        command:
        - /bin/sh
        - -c
        - |
          az storage directory create \
            --account-name euaidtcoretrunkaks \
            --share-name mono-sua-tst-man-yv \
            --name {{ .Release.Name }} \
            --auth-mode login
      restartPolicy: OnFailure
      serviceAccountName: azure-file-creator-sa  # 需提前创建拥有存储账户操作权限的ServiceAccount

2. 提前创建具备Azure存储目录创建权限的ServiceAccount及RBAC绑定，确保钩子Job能正常执行。

方案2：用InitContainer挂载根共享并创建子目录 #

在使用该PV的业务Pod中添加InitContainer，先挂载根共享并创建目标子文件夹：

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  initContainers:
  - name: prepare-subdir
    image: busybox:1.36
    command: ["mkdir", "-p", "/mnt/azure/{{ .Release.Name }}"]
    volumeMounts:
    - name: root-share
      mountPath: /mnt/azure
  containers:
  - name: app-container
    image: your-app-image
    volumeMounts:
    - name: app-volume
      mountPath: /app/data
  volumes:
  - name: root-share
    persistentVolumeClaim:
      claimName: root-share-pvc  # 绑定根共享mono-sua-tst-man-yv的PVC
  - name: app-volume
    persistentVolumeClaim:
      claimName: app-pvc  # 绑定使用mono-sua-tst-man-yv/{{ .Release.Name }}的PVC

方案3：修改CSI驱动配置（不推荐） #

部分Azure File CSI驱动版本支持通过--auto-create-directory=true参数开启全局自动创建子目录特性，但该配置会影响所有使用该驱动的PV，存在全局风险，不建议生产环境使用。

内容的提问来源于stack exchange，提问作者Ron.k