Why can you set multiple accessModes on a persistent volume?

Question

For example in the following example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: exmaple-pvc
spec:
  accessModes:
    - ReadOnlyMany
    - ReadWriteMany
  storageClassName: standard
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi

Why is this allowed? What is the actual behavior of the volume in this case? Read only? Read and write?

Answer 1

To be able to fully understand why a certain structure is used in a specific field of yaml definition, first we need to understand the purpose of this particular field. We need to ask what it is for, what is its function in this particular kubernetes api-resource.

I struggled a bit finding the proper explanation of accessModes in PersistentVolumeClaim and I must admit that what I found in official kubernetes docs did not safisfy me:

A PersistentVolume can be mounted on a host in any way supported by the resource provider. As shown in the table below, providers will have different capabilities and each PV’s access modes are set to the specific modes supported by that particular volume. For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV’s capabilities.

Fortunately this time I managed to find really great explanation of this topic in openshift documentation. We can read there:

Claims are matched to volumes with similar access modes. The only two matching criteria are access modes and size. A claim’s access modes represent a request. Therefore, you might be granted more, but never less. For example, if a claim requests RWO, but the only volume available is an NFS PV (RWO+ROX+RWX), the claim would then match NFS because it supports RWO.

Direct matches are always attempted first. The volume’s modes must match or contain more modes than you requested. The size must be greater than or equal to what is expected. If two types of volumes, such as NFS and iSCSI, have the same set of access modes, either of them can match a claim with those modes. There is no ordering between types of volumes and no way to choose one type over another.

All volumes with the same modes are grouped, and then sorted by size, smallest to largest. The binder gets the group with matching modes and iterates over each, in size order, until one size matches.

And now probably the most important part:

A volume’s AccessModes are descriptors of the volume’s capabilities. They are not enforced constraints. The storage provider is responsible for runtime errors resulting from invalid use of the resource.

I emphasized this part as AccessModes can be very easily misunderstood. Let's look at the example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: exmaple-pvc-2
spec:
  accessModes:
  - ReadOnlyMany
  storageClassName: standard
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi

The fact that we specified in our PersistentVolumeClaim definition only ReadOnlyMany access mode doesn't mean it cannot be used in other accessModes supported by our storage provider. It's important to understand that we cannot put here any constraint on how the requested storage can be used by our Pods. If our storage provider, hidden behind our standard storage class, supports also ReadWriteOnce, it will be also available for use.

Answering your particular question...

Why is this allowed? What is the actual behavior of the volume in this case? Read only? Read and write?

It doesn't define behavior of the volume at all. The volume will behave according to its capabilities (we don't define them, they are imposed in advance, being part of the storage specification). In other words we will be able to use it in our Pods in all possible ways, in which it is allowed to be used.

Let's say our standard storage provisioner, which in case of GKE happens to be Google Compute Engine Persistent Disk:

$ kubectl get storageclass
NAME                 PROVISIONER            AGE
standard (default)   kubernetes.io/gce-pd   10d

currently supports two AccessModes:

• ReadWriteOnce
• ReadOnlyMany

So we can use all of them, no matter what we specified in our claim e.g. this way:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: debian
  template:
    metadata:
      labels:
        app: debian
    spec:
      containers:
      - name: debian
        image: debian
        command: ['sh', '-c', 'sleep 3600']
        volumeMounts:
         - mountPath: "/mnt"
           name: my-volume
           readOnly: true
      volumes:
      - name: my-volume
        persistentVolumeClaim:
          claimName: example-pvc-2
      initContainers:
      - name: init-myservice
        image: busybox
        command: ['sh', '-c', 'echo "Content of my file" > /mnt/my_file']
        volumeMounts:
         - mountPath: "/mnt"
           name: my-volume

In the above example both capabilities are used. First our volume is mounted in rw mode by the init container which saves to it some file and after that it is mounted to the main container as read-only file system. We are still able to do it even though we specified in our PersistentVolumeClaim only one access mode:

spec:
  accessModes:
  - ReadOnlyMany

Going back to the question you asked in the title:

Why can you set multiple accessModes on a persistent volume?

the answer is: You cannot set them at all as they are already set by the storage provider, you can only request this way what storage you want, what requirements it must meet and one of these requirements are access modes it supports.

Basically by typing:

spec:
  accessModes:
    - ReadOnlyMany
    - ReadWriteOnce

in our PersistentVolulmeClaim definition we say:

"Hey! Storage provider! Give me a volume that supports this set of accessModes. I don't care if it supports any others, like ReadWriteMany, as I don't need them. Give me something that meets my requirements!"

I believe that further explanation why an array is used here is not needed.