Creating persistent volumes in Kubernetes

You want to create a persistent volume in Kubernetes? Here you can find out how this works with Openstack Cinder in NWS Managed Kubernetes. Pods and containers are by definition more or less volatile components in a Kubernetes cluster and are created and destroyed as required. However, many applications such as databases can rarely be operated sensibly without long-lived storage. With the industry standard Container Storage Interface (CSI), Kubernetes offers a standardized integration for various storage backends for the integration of persistent volumes. For our Managed Kubernetes solution, we use the Openstack component Cinder to provide persistent volumes for pods. The CSI Cinder Controller is already active for NWS Kubernetes from version 1.18.2 and you can use persistent volumes with just 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 sent to your cluster in YAML format and kubectl apply:

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

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

You can use get and describe to check whether the creation has worked:

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

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

You can now create any number of volumes based on this storage class.

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

You can create a new volume with the help of a peristentVolumeClaim. The PVC claims a persistentVolume resource for you. If no suitable PV resource is available, this is created dynamically by the CSI cinder controller. The PVC and PV are bound to each other and are available exclusively for you. Without further configuration, a dynamically created PV is immediately deleted when the associated PVC is deleted. This behavior can be overridden in the StorageClass defined above using the reclaimPolicy. pvc.yaml :

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

---
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 have created the PVC in the cluster with kubectl apply, a new volume is created in the storage backend in the background. In the case of our NETWAYS Managed Kubernetes, Cinder creates a volume as an RBD in the Ceph cluster. In the next step, your new volume is mounted in the document root of an Nginx pod.

kubectl describe pvc nginx-documentroot

kubectl describe pvc nginx-documentroot

Pods and persistent volumes

Volumes are usually defined in the context of a pod and therefore have the same life cycle as the pod. However, if you want to use a volume that is independent of the pod and container, you can reference the PVC you have just created in the volumes area and then include it in the container under volumeMounts. In the example, the document root of an 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: 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

---
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 on the same worker node. With kubectl you can also quickly customize the index.html and start the K8s proxy and you can access your new index.html 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

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 Contoller, you can create and manage persistent volumes quickly and easily. Additional features for creating snapshots or enlarging volumes are already included. And options such as multinode attachment are already being planned. So nothing stands in the way of your database cluster in Kubernetes.