Creating Persistent Volumes in Kubernetes

You want to create a persistent volume in Kubernetes? Here you can learn how it works with Openstack Cinder in a NWS Managed Kubernetes plan.

Pods and containers are by definition more or less ephemeral components in a Kubernetes cluster and are created and destroyed as needed. However, many applications such as databases can rarely be operated meaningfully without long-lived storage. With the industry-standard Container Storage Interface (CSI) spec, Kubernetes offers an abstraction for different storage backends for the integration of persistent volumes.

In case of our Managed Kubernetes solution, we use the Openstack component Cinder to provide persistent volumes for pods. The CSI Cinder controller is already active in NWS Kubernetes clusters starting with version 1.18.2. You can start using persistent volumes with only a few K8s objects.

Creating Persistent Volumes with CSI Cinder Controller

Before you can create a volume, a StorageClass must be created with Cinder as the provisioner. As usual, the K8s objects are applied to your cluster in the YAML format and by using kubectl apply:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cinderstorage
provisioner: cinder.csi.openstack.org
allowVolumeExpansion: true

With get and describe you can check whether the creation was successful:

$ kubectl apply -f storageclass.yaml
$ kubectl get storageclass
$ kubectl describe storageclass cinderstorage

With the help of this storage class, you can create as many volumes as your quota allows.

Persistent Volume (PV) and Persistent Volume Claim (PVC)

You can create a new volume with the help of a persistentVolumeClaim. The PVC claims a persistentVolume resource for you. If no sufficiently sized PV is available, it is dynamically created by the Cinder CSI Controller. PVC and PV are bound to each other and are exclusively available for you. The attached PV by default will follow the life-cycle of the pvc. So deleting a PVC will permanently remove it’s associated PV as well. This behaviour can be overridden in the StorageClass defined above with the help of the reclaimPolicy.

pvc.yaml:

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-documentroot
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: cinderstorage

In addition to the name, other properties such as size and accessMode are defined in the PVC-Object. After you’ve created the volume with kubectl apply, a new volume is automatically created in the appropriate storage backend managed by cinder. In the case of our NETWAYS Managed Kubernetes, Cinder creates a RBD-volume in the Ceph cluster. In the next step, we’ll mount the new volume in the document root of a Nginx pod to make the website’s data persistent.

To make sure the PVC creation was successful. You can describe the new resource as follows. The status must be bound and the events show “ProvisioningSucceeded” in order for the next step to work.

$ kubectl describe pvc nginx-documentroot

Pods and persistent Volumes

Usually, volumes are defined in the context of a pod and therefore have the same life cycle as them. However, if you want to use a volume that is independent of the pod and container, you can reference the PVC you just created in the volumes section and then include it in the container under volumeMounts. In this example, the document root of a Nginx is replaced.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
          - mountPath: /usr/share/nginx/html
            name: documentroot
      volumes:
      - name: documentroot
        persistentVolumeClaim:
          claimName: nginx-documentroot
          readOnly: false

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: nginx

Kubernetes and the CSI Cinder Controller naturally ensure that your new volume and the associated pods are always started at the same worker node. With kubectl you can also quickly adjust the index.html, port-foward the services port and access your newly created index.html living in the persistent volume:

$ kubectl exec -it deployment/nginx — bash -c ‘echo “CSI FTW” > /usr/share/nginx/html/index.html’
$ kubectl port-forward service/nginx-svc 8080:80

Conclusion

With the CSI Cinder Controller, you can create and manage persistent volumes quickly and easily. Further features for creating snapshots or enlarging volumes are already included. And options such as Multinode Attachment re already being planned. So nothing stands in the way of your database cluster in Kubernetes and the next exciting topic in our Kubernetes Blog series has been decided!