All the volumes we've worked with so far have been ephemeral, meaning when the associated pod is deleted the volume is deleted as well. This is fine for some use cases, but for most CRUD apps we want to persist data even if the pod is deleted.
If you think about it, it's not even just when pods are explicitly deleted with kubectl that we need to worry about data loss. Pods can be deleted for several reasons:
In all of these cases, we want to make sure that our data is still available. Persistent volumes allow us to do this.
Instead of simply adding a volume to a deployment, a persistent volume is a cluster-level resource that is created separately from the pod and then attached to the pod. It's similar to a ConfigMap in that way.
PVs can be created statically or dynamically.
Generally speaking, and especially in the cloud-native world, we want to use dynamic PVs. It's less work and more flexible.
A persistent volume claim is a request for a persistent volume. When using dynamic provisioning, a PVC will automatically create a PV if one doesn't exist that matches the claim.
The PVC is then attached to a pod, just like a volume would be.
Create a new file called api-pvc.yaml and add the following:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: xxx
spec:
accessModes:
- xxx
resources:
requests:
storage: xxx
Add the following properties:
metadata/name: synergychat-api-pvcspec/accessModes: An array with one entry:
ReadWriteOncespec/resources/requests/storage: 1GiThis creates a new PVC called synergychat-api-pvc with a few properties that can be read from and written to by multiple pods at the same time. It also requests 1GB of storage.
Apply the PVC.
Run both of these commands:
kubectl get pvc
kubectl get pv
You should see that a new PV was created automatically!
Now delete the PVC:
kubectl delete pvc <pvc-name>
Make sure both the PVC and PV are gone:
kubectl get pvc
kubectl get pv
Now recreate the PVC. Dynamic provisioning is awesome! Run:
kubectl proxy
Run and submit the CLI tests.