How to Add Block Storage Volumes to Kubernetes Clusters Limited Availability

Kubernetes is currently in limited availability. 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
  name: csi-pvc
  - ReadWriteOnce
      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. accessModes must be set to ReadWriteOnce. The other parameters, ReadOnlyMany and ReadWriteMany, are 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
  name: my-csi-app
    - name: my-frontend
      image: busybox
      - mountPath: "/data"
        name: my-do-volume
    - name: my-do-volume
        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:

pvc-0213ed0abexample   5Gi        RWO            Delete           Bound     default/csi-pvc   do-block-storage             11s


For more about managing persistent volumes see: