How to Add Block Storage Volumes to a Kubernetes Cluster

Kubernetes is currently in limited availability, so it may not be visible or available for your account. Learn more.

When you need to write and access persistent data in a Kubernetes cluster, you can create and access DigitalOcean block storage volumes by creating a PersistentVolumeClaim as part of your deployment.

The claim can allow cluster workers to read and write database records, user-generated website content, log files, and other data that should persist after a process has completed.

Create a Configuration File

The example configuration defines two types of objects:

  1. The PersistentVolumeClaim called csi-pvc which is responsible for locating the block storage volume by name if it already exists and creating the volume if it does not.

  2. The Pod named my-csi-app, which will create containers, then add a mountpoint to the first object and mount the volume there.

Define the Persistent Volume Claim

The first resource definition to define the PVC can look like this:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: do-block-storage

This example creates a 5GB block storage volume that will be available to the cluster by the name csi-pvc. If a volume by that name does not exist, one will be created. If one already exists, then the existing volume will be mounted on the first object.

The three values highlighted below can be customized as follows:

  1. The name must be lowercase alphanumeric values and dashes only and unique within the cluster. Within these constraints, you can name it whatever you want.

  2. The accessModes can be set to ReadWriteOnce and ReadOnlyMany. The additional parameter, ReadWriteMany, is not supported by DigitalOcean volumes. See the Kubernetes documentation for more about accessModes.

  3. The [storage] value specifies the size of the volume and can be customized to meet your needs. DigitalOcean storage values can range from 1GB to 10,000GB.

Changing the storage value in the resource definition after the volume has been created will have no effect. To resize the volume, you can delete and reprovision the pod, resize the volume with the control panel, or resize the volume using the API.

Billing for the block storage volume begins when the object is successfully created. To end billing, you must explicitly delete the volume.

Define the Pod

The second resource definition, which defines the pod, might look like:

---
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeMounts:
      - mountPath: "/data"
        name: my-do-volume
  volumes:
    - name: my-do-volume
      persistentVolumeClaim:
        claimName: csi-pvc

This adds a pod called my-csi-app based on the Linux BusyBox image that names the csi-pvc volume my-do-volume and mounts it within the container at /data on the filesystem.

Show Volumes

Within the cluster, volumes will be identified by their names as defined in the claimNamename parameter. In the example above, the name is csi-pvc.

Regardless of what you set this name to be, the name of the volume on DigitalOcean will begin with pvc- and end with a unique identifying number, something like pvc-0213ed0abexample. You can list the storage volumes associated with a cluster with the get pv command:

kubectl -kubeconfig=[full path to cluster config file] get pv

The output looks something like:

NAME                   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM             STORAGECLASS       REASON    AGE
pvc-0213ed0abexample   5Gi        RWO            Delete           Bound     default/csi-pvc   do-block-storage             11s

Delete Volumes

You’ll typically use a block storage volume when you want data to persist after a container process exits. If you delete volumes with kubectl using the pv, pvc, or pod option, the block storage volume will be permanently deleted.

When you’ve deleted a cluster from the control panel, the volume will not be automatically deleted and billing will continue. In this case, visit the control panel and manually delete the block storage volume.

References

For more about managing persistent volumes see:

Note that while you can currently delete block storage volumes and load balancers from the control panel, we recommend that you use kubectl to manage all cluster-related resources.