A follow-up to blog post Adding OpenStack Cloud Provider To Rancher Cluster
Tested on Rancher 2.2.4
Storage In Containerized World
Docker containers are transient. Once they fulfill their purpose and are deleted, they do not retain any data.
With the adoption and the growing use cases of Docker, an option to store container data was required.
There are two popular mechanisms for persistent storage for containers:
- Docker Volumes  - Areas on the filesystem which Docker manages. Volumes are managed directly by Docker binaries, can be shared between containers, works across the platform, is easy to backup/migrate and contain drivers that allow storing data on various storage backends (one of them is OpenStack Cinder).
- Bind Mounts  - A file/directory which is bound to a container. They rely on the host machine's filesystem and can not be shared between containers.
Persistent Storage In Kubernetes
Kubernetes leverages docker volumes to provide persistent storage capabilities.
A persistent Volume Claim is a request for storage that consumes Persistent Volume. Claims can request specific sizes and access modes.
OpenStack Cinder As A Persistent Kubernetes Storage Backend
Kubernetes natively supports OpenStack Cinder as one of its storage backends .
OpenStack Cinder based volumes only support a single access mode,
ReadWriteOnce, a single container may only read and write to a volume, and the data can not be shared between containers.
Configuring OpenStack Cinder As A Storage Backend in Rancher
Requires to have OpenStack configured as a Kubernetes Cloud Provider
Navigate to the Rancher dashboard and select the cluster containing an OpenStack cloud provider:
Add Storage Class
Storage > Storage Classes from the top menu:
Add a storage class to the cluster by clicking on
Add Storage Class view:
OpenStack Cinder from the dropdown menu:
OpenStack Cinder Storage Class Options:
- Name - Name given to Storage Class
- Description - Description of Storage Class Entity
- Provisioner - Kubernetes Storage Provisioner to use
- Parameters - Extra params for Storage Class:
- Volume Type - Cinder backend to use for Storage Class (OpenStack Cinder has the option to expose multiple backends to the operator )
- Availability Zone - Nova availability that contains Cinder backend
- Customize - Advanced options:
- Reclaim Policy - Set if volumes should be deleted after containers are deleted
- Mount Options - Additional mount options passed to Docker volume
Once Storage Class is created, it will appear as:
Testing OpenStack Cinder Storage
There are several ways of creating persistent volumes, which are not all covered in this section
To verify that your Storage Class allows creating persistent volumes, we'll deploy a workload (refer to workload deployment 
Creating Persistent Volume Claim
During workload creation, we can create a pvc based on a previously configured storage class:
Add Volume Claim view:
- Name - Name given to volume claim
- Description - Description of volume claim
- Source - Source which fulfills the volume claim
- Storage Class - Storage class to use for volume claim
- Capacity - Storage capacity to provision
- Customize - Set access mode of volume.
OpenStack Cinder supports only 'Single Node Read-Write'.
Configure volume mount on created persistent volume:
- Volume Name - Name given to volume
- Volume Type - Kubernetes volume types , in our case it will be persistentVolumeClaim
- Mount Point - Mount point to be used in container
- Sub Path in Volume - Sub path inside root directory of volume 
- Read Only - Set Read Only to mount
If the storage configuration is valid, a workload should be spawned, and it should appear in the Persistent Volumes in Cluster dashboard:
The created volume will appear in the OpenStack dashboard as well:
Docker volumes allow persistent storage capabilities in Kubernetes.
OpenStack Cinder is a block based storage that is used as part of OpenStack clouds.
Kubernetes Storage Classes allow operators to leverage various storage solutions.