In these examples we will walk through a few scenarios of various configuratons of StorageClasses and Dynamic Provisioning using Google Cloud Platform Compute Engine (GCE). These examples assume some familiarity with Kubernetes, GCE and Persistent Disks and OpenShift Container Platform is installed and properly configured to use GCE.
StorageClasses can be used to differentiate and delineate storage levels and
usages. In this case, the cluster-admin or storage-admin sets up two
distinct classes of storage in GCE.
slow: Cheap, efficient, and optimized for sequential data operations (slower reading and writing)
fast: Optimized for higher rates of random IOPS and sustained throughput (faster reading and writing)
By creating these StorageClasses, the cluster-admin or storage-admin
allows users to create claims requesting a particular level or service of
StorageClass.
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: slow (1)
provisioner: kubernetes.io/gce-pd (2)
parameters:
type: pd-standard (3)
zone: us-east1-d (4)| 1 | Name of the StorageClass. |
| 2 | The provisioner plug-in to be used. This is a required field for StorageClasses. |
| 3 | PD type. This example uses pd-standard, which has a slightly lower cost, rate of sustained IOPS, and throughput versus pd-ssd, which carries more sustained IOPS and throughput. |
| 4 | The zone is required. |
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd
zone: us-east1-dAs a cluster-admin or storage-admin, save both definitions as YAML files.
For example, slow-gce.yaml and fast-gce.yaml. Then create the StorageClasses.
# oc create -f slow-gce.yaml storageclass "slow" created # oc create -f fast-gce.yaml storageclass "fast" created # oc get storageclass NAME TYPE fast kubernetes.io/gce-pd slow kubernetes.io/gce-pd
|
|
As a regular user, create a new project:
# oc new-project rh-eng
Create the claim YAML definition, save it to a file (pvc-fast.yaml):
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-engineering
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
storageClassName: fastAdd the claim with the oc create command:
# oc create -f pvc-fast.yaml persistentvolumeclaim "pvc-engineering" created
Check to see if your claim is bound:
# oc get pvc NAME STATUS VOLUME CAPACITY ACCESSMODES AGE pvc-engineering Bound pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX 2m
|
Since this claim was created and bound in the rh-eng project, it can be shared by any user in the same project. |
As a cluster-admin or storage-admin user, view the recent dynamically provisioned Persistent Volume (PV).
# oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX Delete Bound rh-eng/pvc-engineering 5m
|
Notice the RECLAIMPOLICY is Delete by default for all dynamically provisioned volumes. This means the volume only lasts as long as the claim still exists in the system. If you delete the claim, the volume is also deleted and all data on the volume is lost. |
Finally, check the GCE console. The new disk has been created and is ready for use.
kubernetes-dynamic-pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 SSD persistent disk 10 GB us-east1-d
Pods can now reference the persistent volume claim and start using the volume.
In this example, a cluster-admin or storage-admin enables a default
storage class for all other users and projects that do not implicitly specify a
StorageClass in their claim. This is useful for a cluster-admin
or storage-admin to provide easy management of a storage volume without having
to set up or communicate specialized StorageClasses across the cluster.
This example builds upon Scenario 1: Basic Dynamic Provisioning with Two Types of StorageClasses. The cluster-admin or storage-admin
will create another StorageClass for designation as the default
StorageClass.
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: generic (1)
annotations:
storageclass.kubernetes.io/is-default-class: "true" (2)
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
zone: us-east1-d| 1 | Name of the StorageClass, which needs to be unique in the cluster. |
| 2 | Annotation that marks this StorageClass as the default class. You must
use "true" quoted in this version of the API. Without this
annotation, OpenShift Container Platform considers this not the default StorageClass. |
As a cluster-admin or storage-admin save the definition to a YAML file
(generic-gce.yaml), then create the StorageClasses:
# oc create -f generic-gce.yaml storageclass "generic" created # oc get storageclass NAME TYPE generic kubernetes.io/gce-pd fast kubernetes.io/gce-pd slow kubernetes.io/gce-pd
As a regular user, create a new claim definition without any StorageClass
requirement and save it to a file (generic-pvc.yaml).
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-engineering2
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5GiExecute it and check the claim is bound:
# oc create -f generic-pvc.yaml
persistentvolumeclaim "pvc-engineering2" created
3s
# oc get pvc
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
pvc-engineering Bound pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX 41m
pvc-engineering2 Bound pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX 7s (1)
| 1 | pvc-engineering2 is bound to a dynamically provisioned Volume by default. |
As a cluster-admin or storage-admin, view the Persistent Volumes defined so
far:
# oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX Delete Bound rh-eng/pvc-engineering2 5m (1) pvc-ba4612ce-8b4d-11e6-9962-42010af00004 5Gi RWO Delete Bound mytest/gce-dyn-claim1 21h pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX Delete Bound rh-eng/pvc-engineering 46m (2)
| 1 | This PV was bound to our default dynamic volume from the default StorageClass. |
| 2 | This PV was bound to our first PVC from Scenario 1: Basic Dynamic Provisioning with Two Types of StorageClasses with our fast StorageClass. |
Create a manually provisioned disk using
GCE (not dynamically
provisioned). Then create a Persistent Volume that connects to the new GCE disk (pv-manual-gce.yaml).
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-manual-gce
spec:
capacity:
storage: 35Gi
accessModes:
- ReadWriteMany
gcePersistentDisk:
readOnly: false
pdName: the-newly-created-gce-PD
fsType: ext4Execute the object definition file:
# oc create -f pv-manual-gce.yaml
Now view the PVs again. Notice that a pv-manual-gce volume is Available.
# oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pv-manual-gce 35Gi RWX Retain Available 4s pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX Delete Bound rh-eng/pvc-engineering2 12m pvc-ba4612ce-8b4d-11e6-9962-42010af00004 5Gi RWO Delete Bound mytest/gce-dyn-claim1 21h pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX Delete Bound rh-eng/pvc-engineering 53m
Now create another claim identical to the generic-pvc.yaml PVC definition but
change the name and do not set a storage class name.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-engineering3
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 15GiBecause default StorageClass is enabled in this instance, the manually created PV does not satisfy the claim request. The user receives a new dynamically provisioned Persistent Volume.
# oc get pvc NAME STATUS VOLUME CAPACITY ACCESSMODES AGE pvc-engineering Bound pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX 1h pvc-engineering2 Bound pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX 19m pvc-engineering3 Bound pvc-6fa8e73b-8c00-11e6-9962-42010af00004 15Gi RWX 6s
|
Since the default StorageClass is enabled on this system, for the manually created Persistent Volume to get bound by the above claim and not have a new dynamic provisioned volume be bound, the PV would need to have been created in the default StorageClass. |
Since the default StorageClass is enabled on this system, you would need to create the PV in the default StorageClass for the manually created Persistent Volume to get bound to the above claim and not have a new dynamic provisioned volume bound to the claim.
To fix this, the cluster-admin or storage-admin user simply needs to create
another GCE disk or delete the first manual PV and use a PV object definition
that assigns a StorageClass name (pv-manual-gce2.yaml)
if necessary:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-manual-gce2
spec:
capacity:
storage: 35Gi
accessModes:
- ReadWriteMany
gcePersistentDisk:
readOnly: false
pdName: the-newly-created-gce-PD
fsType: ext4
storageClassName: generic (1)| 1 | The name for previously created generic StorageClass. |
Execute the object definition file:
# oc create -f pv-manual-gce2.yaml
List the PVs:
# oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pv-manual-gce 35Gi RWX Retain Available 4s (1) pv-manual-gce2 35Gi RWX Retain Bound rh-eng/pvc-engineering3 4s (2) pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX Delete Bound rh-eng/pvc-engineering2 12m pvc-ba4612ce-8b4d-11e6-9962-42010af00004 5Gi RWO Delete Bound mytest/gce-dyn-claim1 21h pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX Delete Bound rh-eng/pvc-engineering 53m
| 1 | The original manual PV, still unbound and Available. This is because it was not created in the default StorageClass. |
| 2 | The second PVC (other than the name) is bound to the Available manually created PV pv-manual-gce2. |
|
Notice that all dynamically provisioned volumes by default have a RECLAIMPOLICY of Delete. Once the PVC dynamically bound to the PV is deleted, the GCE volume is deleted and all data is lost. However, the manually created PV has a default RECLAIMPOLICY of Retain. |