Use persistent volumes

View as Markdown

A persistent volume is storage that is kept when a pod restarts or moves to another node, for data such as a database’s files. You create the first one on the cluster’s Persistent Volume tab; after that, you can also create volumes from claims inside the cluster. Persistent volumes are available on clusters in Delhi.

Before you begin

Your cluster is in Delhi and reads Running. The Persistent Volume tab is available on clusters in Delhi; for a cluster in Chennai, see Other storage for your pods.
kubectl is connected to the cluster. See Connect to a cluster with kubectl.

Create a persistent volume in MyAccount

In MyAccount, under Compute, click Kubernetes, click your cluster’s name, and open the Persistent Volume tab.
Click Add Volume. Add Persistent Volume opens.
Choose a Persistent Volume Size from the list, with room for your data to grow. Sizes are in GB; Kubernetes counts in GiB, so a 10 GB volume shows about 9.5G inside a pod.
Persistent Volume Name is filled in as PV-<size>- and random characters. Keep it, or enter your own name of up to 50 letters, digits, and hyphens. The name must not be used by another of your volumes, and must not start with csi-vol-.
Check the cost the dialog shows, and click Create.

The volume is listed on the tab, with Persistent Volume creation initiated. It will be bound shortly.

Creating the first volume also adds the storage class csi-rbd-sc to the cluster, which you use to create more volumes from claims. The volume arrives bound to a claim named pvc-<id> in the default namespace, ready for a pod to use. This first volume has no storage class; claims you make through csi-rbd-sc have one, so use those for data you back up; see Back up a cluster with Velero.

Use the volume from a pod

Find the claim’s name:

kubectl get pvc -n default

The claim reads Bound, and its name starts with pvc-:

NAME        STATUS   VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-<id>    Bound    <volume>      <size>     <mode>                        2m

Write a pod that mounts the claim. Replace <claim-name> with the name from the previous command:

apiVersion: v1
kind: Pod
metadata:
  name: data-test
  namespace: default
spec:
  containers:
    - name: app
      image: busybox
      command: ["sleep", "3600"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: <claim-name>

Save it as data-test.yaml, apply it, and check it:

kubectl apply -f data-test.yaml
kubectl get pod data-test -n default

The pod reads Running. Write a file on the volume, and read it back:

kubectl exec data-test -n default -- sh -c 'echo hello > /data/hello.txt'
kubectl exec data-test -n default -- cat /data/hello.txt

kubectl prints hello. To see that the data outlives the pod, delete the pod, apply the same file again, and run the same command: it prints hello again, because the file is on the volume, not in the pod.

kubectl delete pod data-test -n default
kubectl apply -f data-test.yaml
kubectl exec data-test -n default -- cat /data/hello.txt

A pod can use a claim in its own namespace, so run pods that use this claim in default.

Create a volume from a claim

Once the cluster has its first volume made on the Persistent Volume tab, a claim that names the storage class csi-rbd-sc creates a volume for itself, in any namespace:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
  namespace: <namespace>
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: csi-rbd-sc
  resources:
    requests:
      storage: 20Gi

Replace <namespace> with your application’s namespace, and 20Gi with the size you need. Save it as app-data.yaml, and run kubectl apply -f app-data.yaml. Then kubectl get pvc -n <namespace> shows the claim as Bound:

NAME       STATUS   VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
app-data   Bound    <volume>      20Gi       RWO            csi-rbd-sc     20s

A pod then mounts it by its name, app-data, as in Use the volume from a pod.

To grow a volume, raise storage in the claim and apply it again. A claim’s size can go up but not down. The storage class’s reclaim policy is Delete, so deleting the claim deletes its volume and the data on it.

Delete a volume

Deleting a volume deletes the data on it for good.

Delete the pod that uses the volume. A volume that a pod still uses is refused with Pod attach to PVC. Please delete pod first. For the test pod on this page, run:
```
kubectl delete pod data-test -n default
```
Delete the volume from the Persistent Volume tab: check I understand and I want to delete Persistent Volume: ., where <name> is the volume’s name, and confirm.
Delete the volume’s claim and PersistentVolume from the cluster. They stay there reading Bound after the storage is gone, and a pod that uses the claim would wait in ContainerCreating. Find their names with kubectl get pvc --namespace default, then run:
```
kubectl delete pvc <claim> --namespace default
kubectl delete pv <volume>
```

Delete is not available while a volume reads Creating or Terminating; wait for it to finish.

Volumes that your claims create appear in the tab’s list within about 15 minutes, named csi-vol-<id> and marked Dynamic. They are deleted from the cluster, not from the tab: delete the claim, and the volume leaves the list within about 30 minutes:

kubectl delete pvc <claim-name> -n <namespace>

Understand how volumes are billed and removed

Every persistent volume is billed by size from when it is created until it is removed from storage. That includes the volumes your claims create. For current prices, see E2E’s pricing page.

Deleting a cluster also deletes its persistent volumes, the ones your claims created included. Copy out any data you want to keep before you delete a cluster; see Delete a cluster.

Other storage for your pods

For a file system that several pods can mount at once, use SFS; see Use an SFS from Kubernetes.
For files your application reads and writes over an S3 API, use a bucket in Object Storage, with an access key your pods read from a Kubernetes secret.

Data on these volumes stays when pods restart or move. If a claim stays Pending, see A volume claim stays Pending.