Versions Compared

Old Version 7

changes.mady.by.user Francesco Sinisi

Saved on

compared with

New Version 8

changes.mady.by.user Francesco Sinisi

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.
  • Class. A PV can have a class, which is specified by setting the storageClassNameattribute the storageClassName attribute to the name of a SC. A PV of a particular class can only be bound to PVCs requesting that class. A PV with no storageClassName has no class and can only be bound to PVCs that request no particular class. In the static case, therefore, the class merely has the function of a label.
  • Reclaim Policy. Current reclaim policies are listed below. As in the case of access mode, policy support depends on the provider used.
    • Retain: manual reclamation;
    • Recycle: basic scrub (rm -rf /thevolume/*);
    • Delete: associated storage asset  is deleted.
  • Mount Option. A Kubernetes administrator can specify additional mount options for when a PV is mounted on a node, using the mountOptions attribute. Mount options are not validated, so mount will simply fail if one is invalid. Again, not all persistent volume types support mount options.
  • Node Affinity. Kubernetes offers us the possibility to create a sub-selection of nodes, from which the volume can be accessed. Pods that use a PV will only be scheduled to nodes that are selected by the node affinity.
  • Phase. Even if it does not represent a parameter, we conclude the part on the PV with a picture regarding the possible status it can assume.
    • Available: a free resource that is not yet bound to a claim;
    • Bound: the volume is bound to a claim;
    • Released: the claim has been deleted, but the resource is not yet reclaimed by the cluster;
    • Failed: the volume has failed its automatic reclamation;

...

  • Capacity. Claims, like Pods, can request specific quantities of a resource. In this case, the request is for storage and use the same convention as PV.
  • Volume mode. Same conventions as PV.
  • Access Mode. Same conventions as PV.
  • Selector. Claims can specify a label selector to further filter the set of volumes. Only the volumes whose labels match the selector can be bound to the claim.
  • Class. A claim can request a particular class by specifying the name of a StorageClass using the attribute storageClassName. In the static provisioning, only PVs of the requested class, ones with the same storageClassName as the PVC, can be bound to the PVC. As mentioned, this parameter is not mandatory, in fact it can be set with the name of the class, it can be empty (storageClassName set equal to "") and completely missing. What happens if the parameter is absent? The system behavior depends on whether the DefaultStorageClass admission plugin is:
    • ON. The administrator may specify a default SC. All PVCs that have no storageClassName can be bound only to PVs of that default. Specifying a default SC is done by setting the annotation storageclass.kubernetes.io/is-default-class: "true" in a SC object. If the administrator does not specify a default, the cluster responds to PVC creation as if the admission plugin were turned off. If more than one default is specified, the admission plugin forbids the creation of all PVCs.
    • OFF.  There is no notion of a default SC. All PVCs that have no storageClassName can be bound only to PVs that have no class.