...

Storage Class

Each SC contains fields which are used when a PersistentVolume belonging to the class needs to be dynamically provisioned. The name of a SC object is significant, and is how users can request a particular class. Administrators set the name and other parameters of a class when first creating SC objects, and the objects cannot be updated once they are created. The aspects concerning the SC are:

• Provisioner. It determines what volume plugin is used for provisioning PVs (the list is available on the official documentation). This field must be specified.
• Reclaim Policy.  PVs that are dynamically created by a SC will have the reclaim policy specified in the reclaimPolicy field of the class. The possible values are the same presented in the section of the PV. PVs that are created manually (static provisioning) and managed via a SC will have whatever reclaim policy they were assigned at creation.
• Allow Volume Expansion. PVs can be configured to be expandable (in some provisioners). This feature when set to true, allows the users to resize the volume by editing the corresponding PVC object. You can only use this feature to grow a Volume, not to shrink it.
• Mount Options. PVs that are dynamically created by a SC will have the mount options specified in the mountOptions field of the class. If the volume plugin does not support mount options but mount options are specified, provisioning will fail.
• Volume binding Mode.  The volumeBindingMode field controls when volume binding and dynamic provisioning should occur. There are two ways:
  • Immediate mode: volume binding and dynamic provisioning occurs once the PVC is created.
  • WaitForFirstConsumer mode: delay the binding and provisioning of a PV until a Pod using the PersistentVolumeClaim is created. Until then, the PVC waits in the pending state.
• Parameters. Storage Classes have parameters that describe volumes belonging to the storage class. Different parameters may be accepted depending on the provisioner. When a parameter is omitted, some default is used.

Persistent Volume

The following parameters can be managed only if the static mode is chosen, since in the dynamic case the PVs are generated on the basis of the SC and the PVCs. The aspects concerning the PV are:

...

• 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.

To activate this plugin you need the administrator needs to edit the /etc/kubernetes/manifests/kube-apiserver.yaml file (the path may be different), inserting DefaultStorageClass in the specifications.

spec:
  containers:
  - command:
    - kube-apiserver
#   other commands...
    - --enable-admission-plugins=NodeRestriction,DefaultStorageClass

Storage Class

Each SC contains fields which are used when a PersistentVolume belonging to the class needs to be dynamically provisioned. The name of a SC object is significant, and is how users can request a particular class. Administrators set the name and other parameters of a class when first creating SC objects, and the objects cannot be updated once they are created. The aspects concerning the SC are:

...

• Immediate mode: volume binding and dynamic provisioning occurs once the PVC is created.
• WaitForFirstConsumer mode: delay the binding and provisioning of a PV until a Pod using the PersistentVolumeClaim is created. Until then, the PVC waits in the pending state.

...

Lifecycle of a volume and claim

...