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 deleted, they do no retain any data.
With the adoption and the growing use cases of Docker, an option to store container data was required.
There are 2 popular mechanisms for persistent storage for containers:
- Docker Volumes  - Areas on the filesystem which are managed by Docker. Volumes are managed directly by Docker binaries, can be shared between containers, works cross platform, easy to backup/migrate and contain drivers that allow to store data on various storage backends (one of them is OpenStack Cinder).
- Bind Mounts  - A file/directory which are bound to a container. They rely on the host machine's filesystem and can not be shared between containers.
Persistent Storage In Kubernetes
Kubernets leverages docker volumes in order to provide persistent storage capabilities.
Persistent Volume Claim is request for storage that consumes Persistent Volume. Claims can request specific size and access mode.
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, 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 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 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
- Decription - Description of Storage Class Entity
- Provisioner - Kubernetes Storage Provisioner to use
- Paramaters - Extra params for Storage Class:
- Volume Type - Cinder backend to use for Storage Class (OpenStack Cinder has an 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:
Testing OpenStack Cinder Storage
There are several ways of creating persistent volumes which are not all covered in this section
In order to verify that your Storage Class allows to create 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 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 OpenStack dashboard as well:
Docker volumes allow persistent storage capabilities in Kubernetes.
OpenStack Cinder is a block based storage which is used as part of OpenStack clouds.
Kuberenetes Storage Classes allow operators to leverage various storage solutions.