I am struggling to understand the concept of the Capacity parameter on the PersistentVolume, and similarly the storage Request on the PersistentVolumeClaim when dealing with ReadOnlyMany storage. If the storage is mounted in read only- what exactly is the Capacity/Request in relation to?
i.e.
spec:
storageClassName: manual
capacity:
storage: 50Gi
accessModes:
- ReadOnlyMany
hostPath:
path: "/foo/bar"
spec:
storageClassName: manual
accessModes:
- ReadOnlyMany
resources:
requests:
storage: 1Mi
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:
(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:
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With