Persistent volume claims vs subPath-CodePudding

I would like to use a single mount point on a node (ie /data) and have a different sub folder for each PersistentVolumeClaim that I am going to use in my cluster.

At the moment I have multiple StorageClass and PersistentVolume for each sub folder, for example:

---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: prometheus
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: prometheus
  labels:
    type: local
spec:
  storageClassName: prometheus
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteOnce
  local:
    path: "/data/prometheus"
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: disk
              operator: In
              values:
                - local

As you can image having a StorageClass, a PersistentVolume for each PersistentVolumeClaim looks a bit of an overkill.

I have tried to use a single StorageClass and PersistentVolume (just pointing to /data), the usePath option (ie prometheus) with multiple PersistentVolumeClaim. But I have noticed that if the securityContext.fsGroupChangePolicy option is enabled it will apply the user/group changes to root of the volume (ie /data) not to the subPath (ie /data/prometheus).

Is there a better solution?

Thanks

CodePudding user response：

As you can image having a StorageClass, a PersistentVolume for each PersistentVolumeClaim looks a bit of an overkill.

That's exactly how dynamic storage provisioning works. Single storage class specified in PVC used by a pod will provision single PV for that PVC. There's nothing wrong with it. I'd suggest using it if you are ok with its default volume reclaim policy of delete.

CodePudding user response：

local-path-provisioner seems to be a good solution.