4

I am trying to understand different access modes for Persistent Volume Claims in Openshift. Found the following information from here

Access Mode         CLI Abbreviation             Description
ReadWriteOnce           RWO               The volume can be mounted as read-write by a single node.

ReadOnlyMany            ROX               The volume can be mounted read-only by many nodes.

ReadWriteMany           RWX               The volume can be mounted as read-write by many nodes.

I know that PVC are bound to single project/namespace and can be extended to different projects as well.

But the confusion here is, what does "single node" or "many nodes" mean here. For example, in RWO mode, "The volume can be mounted as read-write by a single node". What node it is referring to.

Can someone give me the significance of these modes with respect to single project/namespace. Does the storage with RWO can have write permission for only one application or all the applications within the project?

Here_2_learn
  • 5,013
  • 15
  • 50
  • 68

1 Answers1

7

The whole RWO vs RWX concept is related to the issue of mounting the same filesystem on multiple hosts, which requires support for things like ie. distributed locking. There are specific implementations that can handle this like ie. NFS, Ceph, GlusterFS etc. generally network/cluster oriented filesystems. Other filesystems are unable to operate correctly if you try to mount them on different servers at the same time (usually they will just not allow this).

So, node, in this case, means particular kubernetes cluster node (be it baremetal server or vm). But, by extension, you should think about it in scope of POD as well, cause in most cases pods can spin up on different nodes, meaning they could not use the same volume or you can not assume that this volume will have coherent shared state, as would happen ie. using HostPath volumes that are unique per every node in cluster.

To clarify for the question below :

RWO volumes have 1:1 relation to pod in general. While in some cases you can define RWO volumes to point to the same physical resource like hostPath, technically they will always be tightly coupled to exclusively one POD. This is specially visible if you use PhysicalVolumes / PhysicalVolumeClaims objects, which will take into account these restrictions for binding PV to PVC. Only RWX volumes give you a storage shared by multiple pods with all pods being able to write to it.

Radek 'Goblin' Pieczonka
  • 21,554
  • 7
  • 52
  • 48
  • another confusion, assume 3 PODS(replicas) running for an application in 3 different nodes. If I select the storage RWO, does it mean that only 1 POD from 1 node can write to that storage? Could you explain this? – Here_2_learn Feb 14 '18 at 16:43
  • To clarify further. If you use RWO with a scaled application, if an instance is scheduled on a host different to the first pod, then the deployment of the latter will hang and eventually fail. This is because Kubernetes can't satisfy the requirement of mounting the persistent volume as it is already mounted on another node for use by the first pod. In short, don't use RWO for scaled applications or with rolling deployments. The latter will not work as even if you have only one replica, it creates a second during the deployment. – Graham Dumpleton Feb 15 '18 at 02:07
  • @GrahamDumpleton: If I understand correctly, 1) Use RWO only for the applications without scaling/rolling deployments. 2) Use RWO for only one POD/application, but not for multiple applications. 3) RWX for any number of applications/PODS within the project......Could you confirm are these points valid? – Here_2_learn Feb 15 '18 at 06:47
  • 1
    not exactly, there are valid cases to use RWO for pods that are scaled. Just that each pod will get it's own, not shared volume. Imagine something like a database server cluster - clustering is done in DB engine, so all you need is a dedicated storage space for the engine - RWO gives exactly that (ie. if you define volume in pod directly or via volumeClaimTemplate). – Radek 'Goblin' Pieczonka Feb 15 '18 at 08:00
  • For the normal use case of DeploymentConfig/ReplicationController/Pod, you are not going to have unique RWO volume per pod. Bringing it, and StatefulSet up, for someone who is trying to learn the basics is just confusing. So yes there are exceptions, but one step at a time. – Graham Dumpleton Feb 15 '18 at 09:49
  • I agree this is not exactly entry level knowledge, but then again it explains why `Use RWO only for the applications without scaling/rolling deployments.` is a flawed statement, specially considering most of the stuff you do should be as Deployments, ergo - scaling/rolling. But yea, it does imply some more digging to understand :) – Radek 'Goblin' Pieczonka Feb 15 '18 at 10:08