...

In the static approach, if no PV present on the cluster meets the user's needs, the latter will have to contact the administrator and request the creation of a new PV with the desired specifications. This scenario, although more controlled than the dynamic one, can be inefficient if the requests become numerous.

Parameterization

These Kubernetes components can be finely customized thanks to a number of parameters. We briefly present the theoretical aspects concerning their personalization.

Persistent Volume

The aspects concerning the PV are:

• Capacity. A PV will have a specific storage capacity. This is set using the PV's capacity attribute. An example list of accepted values are 500K, 100M, 5G, 800Ki, 350Mi, 1Ti. The letter "i" accompanying the various SI prefixes indicates numbers on a binary basis, rather than a decimal basis (more details here).
• Volume mode. Kubernetes supports  Filesystem (default) and Block volume modes. In the first case, a volume is mounted into Pods into a directory. In the second, volume is presented into a Pod as a block device, without any filesystem on it.  This mode is useful to provide a Pod the fastest possible way to access a volume, without any filesystem layer between the Pod and the volume.
• Access Mode. The ways of accessing the volume are shown below. Not all providers, however, support the 3 modes listed.
  • 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.