Standalone Cinder for the Dynamic Volume Provisioning
Recently, I installed OpenStack to get confidence with it.
The OpenStack installation comes with the Cinder component, so I decided to enable dynamic volume provisioning on my Kubernetes cluster, but since the Kubernetes cluster is not distributed on OpenStack, to integrate them I chose an alternative way among those proposed: standalone-cinder external provisioner.
- Kubernetes cluster
- OpenStack cluster
- admission plugins DefaultStorageClass enabled on k8s API server for defaulting behavior
- - enable-admission-plugins = … , DefaultStorageClass, …
- since I’ll deploy an iscsi storage on a K8s cluster, deployed with hyperkube, the following iscsi paths are needed into the kubelet container
/etc/iscsi/, /sbin/iscsiadm, /var/lib/iscsi, /lib/modules
The resources, stored into this git repository, are subdivided into the following files:
- cinder-provisioner-ctl.yaml: standalone cinder provisioner used to communicate with OpenStack.
- sc-pvc.yaml: a storage class with provisioner openstack.org/standalone-cinder and a persistent volume claim that uses the storage class
- deploy.yaml: a simple deploy in order to test the dynamic volume provisioning
Step 1: standalone cinder provisioner
The most interesting part of cinder-provisioner-ctl.yaml is given by the following environment variables
All values are easy to find in OpenStack except the value of the OS_TENANT_ID, Its value is the “project id” reported into OpenStack menù “Identity -> Projects”.
With the following command, it is possible to deploy the cinder provisioner.
$ kubectl create -f cinder-provisioner-ctl.yaml
Whereas in the image below the logs of the controller creation are shown.
After the deployment of the standalone-cinder, it is possible to create the storage class named “base” and the persistent volume claim associated with it.
$ kubectl create -f sc-pvc.yaml
In the following image it is reported the event generated by cinder provisioner.
A new Persistent Volume has been created into Kubernetes and then it has been associated with the Persistent Volume Claim “base-claim”.
Furthermore the new volume has been created by Cinder into OpenStack.
Step 3: delete anything
Since the reclaim policy of the storage class is set to delete, the deletion of Persistent Volume Claim “base-claim” removes both the persistent volume object from Kubernetes, as well as the associated storage asset in the OpenStack cluster as shown in the following images.
$ kubectl delete -f sc-pvc.yaml
Standalone cinder provisioner could be a very useful way to handle the storage with OpenStack.
In order to deepen these topics, I suggest the following links