What is the purpose of the capacity parameter on a Persistent Volume that is in ReadOnlyMany mode?

PersistentVolume(PV) is an object usually created by an administrator or auto-provisioned by a cloud provider.

You can imagine it as flash drives laying on a table and available for claiming.

PersistentVolumeClaim(PVC) is a minimum specification that PV should comply with.

Continuing the flash drive analogy, we can imagine that we need a flash drive that is:

1. red, (color=red) (strict clause)
2. Produced in the USA (manufactured=usa) (strict clause)
3. Has a minimum capacity of 2Gb (capacity>=2gb) (I put “more or equal” here because that is how kubernetes selects PV by capacity) (not so strict)

(Workaround: You can put capacity value to label and use a selector to filter only the size you want, not less, not more. We skip it for now)

And we can find on the table two flash drives that are:

1. red, (exact match) (don’t care about other colors)
2. Manufactured in the USA (exact match) (don’t care about those produced in China or Vietnam)
3. Have a capacity of 16 Gb and 4Gb

As soon as we need only 2Gb, we take the flash-drive with 4Gb capacity, which is closer to our needs.

After you choose the correct “flash drive” (bound PV to your container), you can use its full capacity (4Gb available) even if your claim was smaller (2Gb would be enough).

But when you take the flash drive from the table, nobody else can claim it (in case you took the last one). In kubernetes, PV and PVC bind as 1-to-1. So, if you have one PV of 50Gb and two claims of 5GB, only one claim will be satisfied.

You can imagine that ReadOnlyMany and ReadWriteOnce mode in PV as a pile of CD or DVD disks with the same data. You can write something on it and then anybody can read it many times. ReadWriteOnce PV can be bound to only one container with write access, but still can be bound to many containers with read only access (take one disk from the pile, there are more of them).

There is not much sense to search information by size in our case, so in PVC you can use any number that is smaller than expected from PV, and use selector, access mode, and storage class to find exactly what you need.

For example, you can create PV that has NFS share under the hood:

apiVersion: v1  kind: PersistentVolume  metadata:    name: pv-with-data    labels:      version: stable      capacity: 50Gi  <-(workaround I’ve mentioned before)  spec:    capacity:      storage: 50Gi    accessModes:    - ReadWriteOnce    - ReadOnlyMany  <- (yes, you can have several modes in PV specification)    persistentVolumeReclaimPolicy: Retain    nfs:      path: /opt/export      server: 10.10.0.10  

The PVC would be something like this:

apiVersion: v1  kind: PersistentVolumeClaim  metadata:    name: data-claim  spec:    accessModes:    - ReadWriteOnce    resources:      requests:        storage: 25Gi    selector:      matchLabels:        version: "stable"      matchExpressions:      - key: capacity        operator: In        values: [25Gi, 50Gi]  

More (boring) information can be found in the documentation:

Volumes
Persistent Volumes
Storage Classes
Dynamic Volume Provisioning
Gigi Sayfan, Mastering Kubernetes

I found this comment on an issue in the Kubernetes project, titled "Kubernetes persistentvolume capacity not work #48701", that describes capacity as just a label. So basically it doesn't have any impact from what I'm gathering:

this is working as intended, kube can't/won't enforce the capacity of PVs, the capacity field on PVs is just a label. It's up to the "administrator" i.e. the creator of the PV to label it accurately so that when users create PVCs that needs >= X Gi, they get what they want.

For a hostPath PV, assigning a capacity may be difficult when the user can use as much free space as there is at that host path, but for e.g. EBS you can of course make capacity match the actual disk size.

Source: https://github.com/kubernetes/kubernetes/issues/48701#issuecomment-314929576