Day 28/#30daysofK8s

PersistentVolume — is a pool of storage centrally allocated.

PersistentVolumeClaims — is what pods use to claim some space on the PersistentVolumes.

pv-def.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  hostPath:
    path: /tmp/data

There are various accessModes — ReadWriteOnce, ReadWriteMany, ReadOnlyMany.

Ideally, hostPath that points to the local path must not be used in production, instead, cloud storage should be used.

With PVC, it is bonded to PV that matches its criteria, kinda like how pods are scheduled on nodes depending on the resources they need or labels they match. The same goes for PVC-PV binding. PV that matches PVC’s resource requirements, accessModes, storage class, volume modes, selector is bound to it.

pvc-def.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  resources:
    requests:
      storage: 500Mi
  accessModes:
  - ReadWriteMany

If the PV matching requirement is not available, the PVC stays in the pending state, until a matching PV is created or found.

In case we delete the PVC, the PV bound to it is affected by the policy defined by persistenVolumeReclaimPolicy(Delete, Retain, Recycle)

In case of delete — the bounded PV will also be deleted, retain — PV will retain along with any data stored into it, recycle — PV will be retained, but any data stored will be scrubbed off so that PV can be used by other PVCs.

PVCs can be used in pod(and rc and deployments) like —

apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - name: frontend
    image: nginx
    volumeMounts:
    - mountPath: "/var/www/html"
      name: mypd
  volumes:
  - name: mypd
    persistentVolumeClaim:
      claimName: pvc1