Change the Access Mode of a PersistentVolume to ReadWriteOncePod [page]deterministic

This page shows how to change the access mode on an existing PersistentVolume to use `ReadWriteOncePod`.

##

> Note: The `ReadWriteOncePod` access mode graduated to stable in the Kubernetes v1.29 release. If you are running a version of Kubernetes older than v1.29, you might need to enable a feature gate. Check the documentation for your version of Kubernetes.

> Note: The `ReadWriteOncePod` access mode is only supported for volumes. To use this volume access mode you will need to update the following [CSI sidecars](https://kubernetes-csi.github.io/docs/sidecar-containers.html) to these versions or greater:

* [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0) * [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0) * [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0)

## Why should I use `ReadWriteOncePod`?

Prior to Kubernetes v1.22, the `ReadWriteOnce` access mode was commonly used to restrict PersistentVolume access for workloads that required single-writer access to storage. However, this access mode had a limitation: it restricted volume access to a single *node*, allowing multiple pods on the same node to read from and write to the same volume simultaneously. This could pose a risk for applications that demand strict single-writer access for data safety.

If ensuring single-writer access is critical for your workloads, consider migrating your volumes to `ReadWriteOncePod`.

## Migrating existing PersistentVolumes

If you have existing PersistentVolumes, they can be migrated to use `ReadWriteOncePod`. Only migrations from `ReadWriteOnce` to `ReadWriteOncePod` are supported.

In this example, there is already a `ReadWriteOnce` "cat-pictures-pvc" PersistentVolumeClaim that is bound to a "cat-pictures-pv" PersistentVolume, and a "cat-pictures-writer" Deployment that uses this PersistentVolumeClaim.

> Note: If your storage plugin supports [Dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/), the "cat-pictures-pv" will be created for you, but its name may differ. To get your PersistentVolume's name run:

```shell kubectl get pvc cat-pictures-pvc -o jsonpath='{.spec.volumeName}' ```

And you can view the PVC before you make changes. Either view the manifest locally, or run `kubectl get pvc <name-of-pvc> -o yaml`. The output is similar to:

```yaml # cat-pictures-pvc.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: cat-pictures-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi ```

Here's an example Deployment that relies on that PersistentVolumeClaim:

```yaml # cat-pictures-writer-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: cat-pictures-writer spec: replicas: 3 selector: matchLabels: app: cat-pictures-writer template: metadata: labels: app: cat-pictures-writer spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 volumeMounts: - name: cat-pictures mountPath: /mnt volumes: - name: cat-pictures persistentVolumeClaim: claimName: cat-pictures-pvc readOnly: false ```

As a first step, you need to edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy` and set it to `Retain`. This ensures your PersistentVolume will not be deleted when you delete the corresponding PersistentVolumeClaim:

```shell kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' ```

Next you need to stop any workloads that are using the PersistentVolumeClaim bound to the PersistentVolume you want to migrate, and then delete the PersistentVolumeClaim. Avoid making any other changes to the PersistentVolumeClaim, such as volume resizes, until after the migration is complete.

Once that is done, you …(trimmed)