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?
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
PersistentVolumeClaim and I must admit that what I found in official kubernetes docs did not safisfy me:
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:<blockquote>
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.</blockquote>
And now probably the most important part:<blockquote>
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
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...<blockquote>
Why is this allowed? What is the actual behavior of the volume in this case? Read only? Read and write?</blockquote>
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
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:<blockquote>
Why can you set multiple accessModes on a persistent volume?</blockquote>
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
PersistentVolulmeClaim definition we say:
<em>"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!"</em>
I believe that further explanation why <em>an array</em> is used here is not needed.
A persistent volume can be mounted by multiple pods on the different node at the same. One pod can mount a persistent volume with only one access mode at a time and other pods can mount the same persistent volume with different access mode. But a pod can mount the persistent volume with only one access mode.
Documentation reference for those who didn't understand the question: persistent volume access modes