PersistentVolumes and claims

Exam tasks: 4.2 (volume types, access modes, reclaim policies), 4.3 (PersistentVolumes and PersistentVolumeClaims)

The decision: how long must this data live, who has to share it, and which PV and PVC fields have to agree before the claim binds?

Pick the volume by lifetimeCopy Anchor Link

How a claim bindsCopy Anchor Link

• A PV is cluster-scoped, a PVC is namespaced. Binding is exclusive: one PV, one PVC, even if the PV is far bigger than the request. The claim reports the PV's full capacity.
• The control loop picks the smallest matching PV. To force a specific one, set spec.volumeName on the PVC (and optionally spec.claimRef on the PV to reserve it).
• A selector.matchLabels on the PVC limits candidates to labelled PVs. A claim with a selector is never dynamically provisioned.

Static PV, claim and PodCopy Anchor Link

apiVersion: v1
kind: PersistentVolume
metadata:
  name: tidepool-pv
  labels:
    tier: archive
spec:
  capacity:
    storage: 2Gi
  accessModes: ["ReadWriteOnce"]
  persistentVolumeReclaimPolicy: Retain   # the default for hand-made PVs
  storageClassName: manual
  volumeMode: Filesystem
  hostPath:                               # fine for a lab, not for production
    path: /srv/tidepool
    type: DirectoryOrCreate
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tidepool-data
  namespace: harbor
spec:
  storageClassName: manual
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: tidepool
  namespace: harbor
spec:
  containers:
  - name: app
    image: busybox:1.37
    command: ["sh", "-c", "sleep 1d"]
    volumeMounts:
    - name: data
      mountPath: /var/tidepool
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: tidepool-data

• There is no kubectl create pv or kubectl create pvc. Copy a skeleton from the docs page and edit it.
• hostPath PVs only work if the Pod lands on the node that has the directory. For real node-local disks use a local PV, which requires spec.nodeAffinity so the scheduler knows where the disk is.

Access modesCopy Anchor Link

• Access modes are a matching rule, not write protection. Only RWOP is actually enforced at mount time: a second Pod using an RWOP claim stays Pending.
• A volume is mounted with one mode at a time, even if the PV lists several.
• To mount read-only in a Pod, set readOnly: true on the volumeMounts entry or on the persistentVolumeClaim volume source.

Volume modeCopy Anchor Link

• Filesystem (default): the volume is formatted and mounted at mountPath through volumeMounts.
• Block: the Pod gets a raw device. The container uses volumeDevices with a devicePath such as /dev/xvda instead of volumeMounts. Used by databases that manage their own on-disk format.
• volumeMode is part of binding: a Block claim won't bind a Filesystem PV. kubectl get pv -o wide shows the VOLUMEMODE column.

What happens when the claim is deletedCopy Anchor Link

• A Released PV still has spec.claimRef pointing at the old claim's UID, so no new claim can bind. After checking or wiping the data, clear the reference: kubectl patch pv tidepool-pv --type=merge -p '{"spec":{"claimRef":null}}'. The PV goes back to Available.
• Change a policy on a live PV with kubectl patch pv <name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'. Do this before deleting a dynamically provisioned claim whose data you need.

ScenariosCopy Anchor Link

DrillCopy Anchor Link

kubectl config use-context cka-storage

1. Create a PersistentVolume reef-pv: 1Gi, ReadWriteOnce, reclaim policy Retain, storage class slow-lab, backed by hostPath /srv/reef.
2. In namespace coral, create a PVC reef-claim requesting 512Mi that binds to reef-pv.
3. Run a Pod reef-writer (image busybox:1.37) in coral that mounts the claim at /data and writes the date into /data/stamp.txt.
4. Delete the Pod and the PVC, then make reef-pv available for a new claim without losing the file.

# reef.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: reef-pv
spec:
  capacity:
    storage: 1Gi
  accessModes: ["ReadWriteOnce"]
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow-lab
  hostPath:
    path: /srv/reef
    type: DirectoryOrCreate
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: reef-claim
  namespace: coral
spec:
  storageClassName: slow-lab
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 512Mi
---
apiVersion: v1
kind: Pod
metadata:
  name: reef-writer
  namespace: coral
spec:
  containers:
  - name: w
    image: busybox:1.37
    command: ["sh", "-c", "date > /data/stamp.txt && sleep 3600"]
    volumeMounts:
    - name: d
      mountPath: /data
  volumes:
  - name: d
    persistentVolumeClaim:
      claimName: reef-claim

k create ns coral            # skip if it exists
k apply -f reef.yaml
k get pv reef-pv; k get pvc -n coral reef-claim      # both Bound
k exec -n coral reef-writer -- cat /data/stamp.txt

k delete pod -n coral reef-writer
k delete pvc -n coral reef-claim
k get pv reef-pv                                     # STATUS Released
k patch pv reef-pv --type=merge -p '{"spec":{"claimRef":null}}'
k get pv reef-pv                                     # STATUS Available

Further readingCopy Anchor Link

• Persistent Volumes
• Volumes
• Configure a Pod to use a PersistentVolume for storage
• Change the reclaim policy of a PersistentVolume