Shared filesystems in the 1.5.3 release are currently in Technology Preview, and are only available using the CSI driver. This experimental feature is not yet intended for production use.
Shared Filesystem support allows volumes to be mounted for read & write access
by multiple containers simultaneously, even from different nodes. In
Kubernetes, shared filesystems are referred to as
ReadWriteMany or RWX
See the architecture for more information about the Shared Filesystem components.
How to provision ReadWriteMany Volumes
RWX Volumes are dynamically provisioned by StorageOS when using a StorageOS
Kubernetes StorageClass. To create an RWX volume set the AccessMode
for the PVC to
An example of a RWX PersistentVolumeClaim is shown below:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: shared-vol labels: storageos.com/replicas: "1" # Enable features using Labels # You can enable replication in the # StorageClass params to set defaults spec: storageClassName: "fast" # StorageOS StorageClass accessModes: - ReadWriteMany # AccessMode that triggers creation of an NFS based StorageOS Volume resources: requests: storage: 20Gi
The following Deployment example shows how multiple Nginx Pods can mount the same shared filesystem PVC.
apiVersion: apps/v1 kind: Deployment metadata: name: nginx labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 volumeMounts: - name: docroot mountPath: /usr/share/nginx/html volumes: - name: docroot persistentVolumeClaim: claimName: shared-vol
Only installations of StorageOS using CSI support RWX Volumes.
Shared volumes can be deleted through standard Kubernetes PVC deletion. When
a RWX PVC is deleted, StorageOS acts differently according to the
ReclaimPolicy of the PVC. For more information about the
field see the Kubernetes
The default reclaim policy for a PVC, PV pair is defined in the StorageClass.
All PVs created by a StorageClass inherit the
in the StorageClass.
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: labels: app: storageos name: storageos parameters: csi.storage.k8s.io/fstype: ext4 pool: default provisioner: storageos reclaimPolicy: Delete # <----- Default reclaim policy
If the RWX PVC is deleted then the RWX PV is deleted along with the NFS server StatefulSet and its underlying RWO volume. As such data written to the RWX volume is non-recoverable after deletion.
The RWX PVC is deleted but the PV remains available. The NFS server StatefulSet remains untouched along with its associated RWO PVC. Hence, it is possible to reuse the volume and have access to data written to the RWX volume after the RWX PVC has been deleted.
In order to reuse the NFS server to serve a different RWX PVC, it is is necessary to “unlock” the PV, which only Kubernetes administrators with privileges can do. The PV is “unlocked” by deleteing the
spec.claimReffield from the PV.
For instance given a RWX PVC,
pvc-1was bound to the PV
pvc-1was deleted. Then in order to reuse
pv-1edit the PV, i.e
kubectl edit pv pv-1and delete the
Deletion of the
spec.claimReffield makes the PV available for any new PVC whose requirements are met by the PV. Therefore creating a new RWX volume with the previously used; StorageClass, capacity, access type and filesystem will make the PVC bind to the previously used RWX PV, even if the new PVC is provisioned in a different namespace.