You can provision your OpenShift Container Platform cluster with storage dynamically when running in a cloud environment. The Kubernetes persistent volume framework allows administrators to provision a cluster with persistent storage and gives users a way to request those resources without having any knowledge of the underlying infrastructure.
Many storage types are available for use as persistent volumes in OpenShift Container Platform. While all of them can be statically provisioned by an administrator, some types of storage can be created dynamically using an API. These types of storage can be provisioned in an OpenShift Container Platform cluster using the new and experimental dynamic storage feature.
|
Dynamic provisioning of persistent volumes is currently a Technology Preview feature, introduced in OpenShift Container Platform 3.1.1. This feature is experimental and expected to change in the future as it matures and feedback is received from users. New ways to provision the cluster are planned and the means by which one accesses this feature is going to change. Backwards compatibility is not guaranteed. |
OpenShift Container Platform provides the following provisioner plug-ins, which have generic implementations for dynamic provisioning that use the cluster’s configured cloud provider’s API to create new storage resources:
| Storage Type | Provisioner Plug-in Name | Required Cloud Configuration | Notes |
|---|---|---|---|
OpenStack Cinder |
|
||
AWS Elastic Block Store (EBS) |
|
For dynamic provisioning when using multiple clusters in different zones, each
node must be tagged with |
|
GCE Persistent Disk (gcePD) |
|
In multi-zone configurations, it is recommended that you run one OpenShift Container Platform cluster per GCE project to avoid the creation of PVs in zones where no node from the current cluster exists. |
|
For any chosen provisioner plug-ins, the relevant cloud configuration must also be set up, per Required Cloud Configuration in the above table. |
When your OpenShift Container Platform cluster is configured for EBS, GCE, or Cinder, the associated provisioner plug-in is implied and automatically enabled. No additional OpenShift Container Platform configuration by the cluster administration is required for dynamic provisioning.
For example, if your OpenShift Container Platform cluster is configured to run in AWS, the EBS provisioner plug-in is automatically available for creating dynamically provisioned storage requested by a user.
Future provisioner plug-ins will include the many types of storage a single provider offers. AWS, for example, has several types of EBS volumes to offer, each with its own performance characteristics; there is also an NFS-like storage option. More provisioner plug-ins will be implemented for the supported storage types available in OpenShift Container Platform.
Users can request dynamically provisioned storage by including a storage class annotation in their persistent volume claim:
kind: "PersistentVolumeClaim"
apiVersion: "v1"
metadata:
name: "claim1"
annotations:
volume.alpha.kubernetes.io/storage-class: "foo" (1)
spec:
accessModes:
- "ReadWriteOnce"
resources:
requests:
storage: "3Gi"| 1 | The value of the volume.alpha.kubernetes.io/storage-class annotation is
not meaningful at this time. The presence of the annotation, with any arbitrary
value, triggers provisioning using the single implied
provisioner plug-in per cloud. |
For dynamically provisioned storage, OpenShift Container Platform defines three key/value pairs, collectively known as the volume owner information, and arranges for the storage to associate this triplet with the provisioned volume. The keys are normally not visible to OpenShift Container Platform users, while the values are taken from user-visible PV and PVC objects.
Keys
kubernetes.io/created-for/pv/nameName of the PersistentVolume.
There is no key for the PV namespace because that has value
default and cannot be changed.
|
kubernetes.io/created-for/pvc/namespacekubernetes.io/created-for/pvc/nameNamespace and name, respectively, of the PersistentVolumeClaim.
Other Terms for Volume Owner Information
Each storage type saves the volume owner information in its own way. When communicating with the storage administrator, use these specific terms to avoid confusion:
| Term for Key/Value Pairs | Storage Type |
|---|---|
tags |
AWS EBS |
metadata |
OpenStack Cinder |
JSON-in-description |
GCE PD |
Using Volume Owner Information
The main benefit of saving the volume owner information is to enable storage administrators to recognize volumes dynamically created by OpenShift Container Platform.
Example scenarios:
OpenShift Container Platform terminates unexpectedly and the dynamically provisioned AWS EBS contains useful data that must be recovered. The OpenShift Container Platform users provide the storage administrators with a list of affected projects and their PVCs:
| Project Name | PVC Name |
|---|---|
app-server |
a-pv-01 |
a-pv-02 |
|
notifications |
n-pv-01 |
The storage administrators search for the orphaned volumes,
matching project names and PVC names to the
kubernetes.io/created-for/pvc/namespace and
kubernetes.io/created-for/pvc/name tags, respectively.
They find them and arrange to make them available again for data-recovery efforts.
The users do not explicitly delete the dynamically provisioned storage
volumes when they are finished with a project.
The storage administrators find the defunct volumes and delete them.
Unlike the preceding scenario, they need match only the project names
to kubernetes.io/created-for/pvc/namespace.
Volumes created dynamically by a provisioner have their
persistentVolumeReclaimPolicy set to Delete. When a persistent volume
claim is deleted, its backing persistent volume is considered released of its
claim, and that resource can be reclaimed by the cluster. Dynamic provisioning
utilizes the provider’s API to delete the volume from the provider and then
removes the persistent volume from the cluster.