[Feature Request] Share a PV across namespaces

[panpan0000]

Is your feature request related to a problem?/Why is this needed

Describe the solution you'd like in detail

Denote below scenario:

two AI teams belong to two different namespaces.

Team 1 want to share some data(on NFS) to Team2: Team 1 has trained a model and wants to share it with Team 2, or Team 1 has prepared a training dataset to further train Team 2.

Team 1 initially creates a PV associated with NFS 10.20.20.1:/nfs/team-1. Subsequently, Team 1 also has a corresponding PVC in namespace NS1, associated with the above PV.

Now, we want Team 2 to use the data in 10.20.20.1:/nfs/team-1.

But without directly mounting this location(maybe security concern) and without creating a PV (assuming Team 2 does not have permission to create cluster-level resources), the best way for Team 2 may want to create a new PVC in NS2 and bind it to the above PV--- Oops --- Kubernetes prevents this behavior because one PV can only be mounted by one PVC, regardless of whether it is RWX/RWO.

Currently, the only option left is for Team 2 to beg the administrator people to create a duplicate PV for them.

However, as PV is a cluster-level resource, in the NFS scenario, it may be desired to be shared by PVCs from different namespaces.

Is there a flag field in the StorageClass, that can relax the restriction of "one PV can only be mounted by one PVC" in such NFS scenarios?

Thank you very much

Describe alternatives you've considered

Additional context

[andyzhangx]

@panpan0000 I think you only need to ask admin to create a storage class with server: 10.20.20.1:/nfs/team-1 parameter, and then the two teams could create two PVCs referencing to that storage class, k8s would create separate PVs automatically bound to those two PVCs, does it work?

[panpan0000]

although it works in theory, but actually, there will be flood of StorageClass which are hard to be managed.. and each time , team 1 want to share/public something , it will be quite troublesome for admin to handle StorageClass one by one....

[panpan0000]

a reference below, to help us to understand the situation better ( as well, below states an implementation by Alluxio/Fluid) https://www.alibabacloud.com/blog/fluid-sharing-dataset-across-kubernetes-namespaces_599739

[andyzhangx]

then you could use a root directory in storage class, e.g. server: 10.20.20.1:/nfs/ instead of server: 10.20.20.1:/nfs/team-1

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[panpan0000]

then you could use a root directory in storage class, e.g. server: 10.20.20.1:/nfs/ instead of server: 10.20.20.1:/nfs/team-1

it breaks the isolation rule between teams (say, Team-3 will access all data , but Team-1 never be willing to share with Team-3), Aka, we want team isolation as well as team collaboration , which the true world is.

typical scenario:

Team 1 : having by-default-private NFS PV 10.20.20.1:/nfs/team-1, may want to share this Volume with Team 2 only, at same day. Team 2 : having by-default-private NFS PV 10.20.20.1:/nfs/team-2 Team 3 : having by-default-private NFS PV 10.20.20.1:/nfs/team-3