This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.3.4. Persistent storage using Cinder
OpenShift Container Platform supports OpenStack Cinder. Some familiarity with Kubernetes and OpenStack is assumed.
Cinder volumes can be provisioned dynamically. Persistent volumes are not bound to a single project or namespace; they can be shared across the OpenShift Container Platform cluster. Persistent volume claims are specific to a project or namespace and can be requested by users.
Additional resources
- For more information about how OpenStack Block Storage provides persistent block storage management for virtual hard drives, see OpenStack Cinder.
3.4.1. Manual provisioning with Cinder 复制链接链接已复制到粘贴板!
Storage must exist in the underlying infrastructure before it can be mounted as a volume in OpenShift Container Platform.
Prerequisites
- OpenShift Container Platform configured for Red Hat OpenStack Platform (RHOSP)
- Cinder volume ID
3.4.1.1. Creating the persistent volume 复制链接链接已复制到粘贴板!
You must define your persistent volume (PV) in an object definition before creating it in OpenShift Container Platform:
Procedure
Save your object definition to a file.
cinder-persistentvolume.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The name of the volume that is used by persistent volume claims or pods.
- 2
- The amount of storage allocated to this volume.
- 3
- Indicates
cinder
for Red Hat OpenStack Platform (RHOSP) Cinder volumes. - 4
- The file system that is created when the volume is mounted for the first time.
- 5
- The Cinder volume to use.
重要Do not change the
fstype
parameter value after the volume is formatted and provisioned. Changing this value can result in data loss and pod failure.Create the object definition file you saved in the previous step.
oc create -f cinder-persistentvolume.yaml
$ oc create -f cinder-persistentvolume.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.1.2. Persistent volume formatting 复制链接链接已复制到粘贴板!
You can use unformatted Cinder volumes as PVs because OpenShift Container Platform formats them before the first use.
Before OpenShift Container Platform mounts the volume and passes it to a container, the system checks that it contains a file system as specified by the fsType
parameter in the PV definition. If the device is not formatted with the file system, all data from the device is erased and the device is automatically formatted with the given file system.
3.4.1.3. Cinder volume security 复制链接链接已复制到粘贴板!
If you use Cinder PVs in your application, configure security for their deployment configurations.
Prerequisites
-
An SCC must be created that uses the appropriate
fsGroup
strategy.
Procedure
Create a service account and add it to the SCC:
oc create serviceaccount <service_account>
$ oc create serviceaccount <service_account>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm policy add-scc-to-user <new_scc> -z <service_account> -n <project>
$ oc adm policy add-scc-to-user <new_scc> -z <service_account> -n <project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow In your application’s deployment configuration, provide the service account name and
securityContext
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The number of copies of the pod to run.
- 2
- The label selector of the pod to run.
- 3
- A template for the pod that the controller creates.
- 4
- The labels on the pod. They must include labels from the label selector.
- 5
- The maximum name length after expanding any parameters is 63 characters.
- 6
- Specifies the service account you created.
- 7
- Specifies an
fsGroup
for the pods.