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.
The example configuration defines two types of objects:
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.
my-csi-app, which will create containers, then add a mountpoint to the first object and mount the volume there.
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:
name must be lowercase alphanumeric values and dashes only and unique within the cluster. Within these constraints, you can name it whatever you want.
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.
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.
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.
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
my-do-volume and mounts it within the container at
/data on the filesystem.
Within the cluster, volumes will be identified by their names as defined in the
claimNamename parameter. In the example above, the name is
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
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
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.
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.