Kubernetes 101 : Choosing the right persistent volume type - RWO, RWX, ... -

Storage volumes differ in the way they are accessed and used by the  pods.

There are storage type for example that could be read and written to simultaneously, and there are other volume types that don't offer that possibility.

NFS for example supports: 
  • ReadWriteOnce
  • ReadOnlyMany
  • ReadWriteMany
And AWS EBS only supports:
  • ReadWriteOnce
We could define these storage characteristics we want for our pods using the below access modes which are specified in Yaml files of the persistent volume and the persistent volume claim:
  • RWO - ReadWriteOnce - :  The persistent volume can only be mounted by one pod as read-write.
  • ROX - ReadOnlyMany - : The persistent volume can be mounted by many pods as read-only.
  • RWX - ReadWriteMany - : The persistent volume can be mounted by more that one pod as read-write.
  • RWOP - ReadWriteOncePod - This feature gives us the possibility to limit access to a storage to one specific pod in the cluster. 
Below is a simple diagram the summarizes the relationship between the pod, the persistent volume and the persistent volume claim:

Below is the Yaml file of a persistent volume with a - ReadWriteOnce - access mode:

We can mention the access modes in the corresponding persistent volume claim as we can see below:


Persistent volumes are assigned to persistent volume claims that have similar access modes and sizes.

Our pod that is using the persistent volume claim "pvc-5Gi" could look something like the below:

We check our persistent volume using the below command:

After we create the persistent volume claim that matches our persistent volume, we get the below:

We check our persistent volume again and we could see that it is now attached to persistent volume claim "pvc-5Gi":


When doing dynamic provisioning for persistent volumes, we specify the "provider" of the persistent Volumes - we don't need to set these up manually -.
The "provider" is called a Storage Class
The persistent volume claim requests a persistent volume directly from the storage class which gets a a persistent volume ready and assigns it to the persistent volume claim.


Leave as a comment: