Persistent data storage

A container is ephemeral : it starts, runs and at some point will eventually stop.
While a container is started from an image, that contains files and folders, any change to this file system will be lost when the container stops.

To circumvent this, Kubernetes introduces the concept of PersistentVolume.
The purpose of this Kubernete resource is to register the means of accessing a persistent data storage location, whether it is local to a node of the cluster or on any kind of network storage.
Then, another resource called PersistentVolumeClaim allows users to map this persistent data storage location to a particular place in one or several containers within a Pod.

More info on PersistentVolumes and associated resources can be found on the Kubernetes Documentation.

Creating persistent volumes

PersistentVolumes cannot be created or handled by regular users, they must either be created manually by a cluster admin, or automatically through a StorageClass.
Most of the time, StorageClass are the way to go because it allows for self provisioning of storage resources.
However, some specific use cases (such as accessing a specific storage platform) may require requesting a cluster admin for provisiong, if possible, such a resource.

When creating PersistentVolumeClaims targeting a StorageClass, the corresponding PersistentVolume will be provisioned automatically, if the request is allowed (with regards to quotas, permissions, etc).

Available storage classes

A StorageClass is a cluster specific resource that allows for provisioning PersistentVolumes in an automated way, via PersistentVolumeClaims.

The table below lists the storage classes available on the WoK platform:

Storage class name	Storage provisioner	Reclaim Policy	Volume Expansion Capable
csi-cephfs-sc (default)	cephfs.csi.ceph.com	Delete	yes
csi-rbd-sc	rbd.csi.ceph.com	Delete	yes

The storage provisioner is the underlying driver used to provisiong the PersistentVolumes and may give you hints on the technology used.

The reclaim policy is the policy assigned as a default to newly provisioned volumes and that takes effect when the claim is deleted.
More info on reclaim policies is available on the Kubernetes documentation.

An expansion capable volume is a volume whose sized can be increased after its creation.
It is useful in situations where more capacity is required over time.

Moreover, it is also possible to list available storage classes from the CLI:

$ oc get sc
NAME                      PROVISIONER           RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
csi-cephfs-sc (default)   cephfs.csi.ceph.com   Delete          Immediate           true                   2y64d
csi-rbd-sc                rbd.csi.ceph.com      Delete          Immediate           true                   2y64d

Creating a persistent volume claim

Creating a PersistentVolumeClaim can be done as any other resource, with a yaml definition.
For instance, the following bit of yaml defines a claim for a volume using the default storage class (here it will rely on CephFS):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myvolume
  namespace: test-mkdocs-qs1
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi

Since it's the default storage class, we do not even need to specify it in the claim definition.

However, if we wanted to use the Ceph RBD storage class, whose name is csi-rbd-sc, we could define it like shown below:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myvolume
  namespace: test-mkdocs-qs1
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  storageClassName: csi-rbd-sc
  resources:
    requests:
      storage: 1Gi

You can display persistent volume claims with the usual get resource command:

$ oc get pvc
NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
myvolume   Bound    pvc-95364f8f-e4fb-48de-b397-7b1af2e3a10a   1Gi        RWO            csi-rbd-sc     13m

Managing volume access modes

Once created, a PersistentVolume will be eventually "mounted" into one or several pods.
The capability to be mounted is directed by the volume "access mode".

There are several access modes defined in the Kubernetes technology, the most common are listed below:

Mode name	Mode short name	Description
ReadWriteOnce	RWO	The volume can be mounted as read-write by a single node.
ReadOnlyMany	ROX	The volume can be mounted as read-only by many nodes.
ReadWriteMany	RWX	The volume can be mounted as read-write by many nodes.

Tip

ReadWriteOnce access mode still can allow multiple pods to access the volume when the pods are running on the same node.

More information is available on the Kubernetes documentation.