Persistent Volumes and Claims

Pods are born and die, but your application's data often needs to live on. Think of a database or user-uploaded files.

• When a Pod restarts or is rescheduled, any data stored directly within its container filesystem is lost.
• This ephemeral nature is fine for stateless applications, but critical data needs a durable solution.
• Kubernetes provides a powerful system to manage persistent storage that survives Pod lifecycles.

A PersistentVolume (PV) is a piece of storage in your Kubernetes cluster.

• It's a cluster-scoped resource, meaning it doesn't belong to any specific namespace.
• PVs are provisioned by an administrator or dynamically by a StorageClass.
• They abstract away the details of the underlying storage technology (e.g., Google Persistent Disk, AWS EBS, NFS share).

PVs are defined with details like capacity, access modes, and the storage type. This YAML describes a PV using a hostPath (for local testing) with 5 Gigabytes of storage.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

Note: hostPath is typically for single-node development and not recommended for production.

A PersistentVolumeClaim (PVC) is a request for storage by a user or an application within a specific namespace.

• Pods don't directly consume PVs; they request storage through a PVC.
• PVCs are namespace-scoped, so they live within a specific project or team's area.
• They specify the desired size, access modes, and optionally, a storage class.

Kubernetes automatically matches a PVC to an available PV through a process called binding.

• When a PVC is created, Kubernetes searches for a PV that meets the PVC's requirements (size, access modes, storage class).
• Once a suitable PV is found, they are "bound" together in a one-to-one relationship.
• This binding ensures the PVC gets the specific storage it asked for.

Access modes define how the storage can be mounted and used by Pods. These modes are requested by PVCs and supported by PVs:

• ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node.
• ReadOnlyMany (ROX): The volume can be mounted as read-only by many nodes.
• ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes.

The availability of these modes depends on the specific storage provider.

Storage Classes provide a way for administrators to describe "classes" of storage (e.g., "fast-ssd", "slow-hdd").

• Instead of manually creating PVs, a StorageClass can dynamically provision a PV when a PVC requests it.
• This automates the creation of PVs based on predefined templates.
• It separates the storage provisioning from its consumption, making it easier for users.

Let's create a PVC that requests 1 Gigabyte of storage with ReadWriteOnce access. This PVC will look for an existing PV or trigger dynamic provisioning via a StorageClass.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard # Optional: if you have a 'standard' StorageClass

Save this as pvc.yaml and apply with kubectl apply -f pvc.yaml.

Once a PVC is bound, a Pod can use it by referencing the PVC's name in its volume configuration. The Pod doesn't need to know about the underlying PV, just the PVC.

apiVersion: v1
kind: Pod
metadata:
  name: my-data-pod
spec:
  containers:
    - name: data-container
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello from CoddyKit!' > /mnt/data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /mnt/data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: my-app-pvc

This Pod will write a file to the mounted persistent volume.

You can monitor the status of your persistent storage resources using kubectl:

• To see all PVs: kubectl get pv
• To see all PVCs in your namespace: kubectl get pvc
• To get detailed information, including status and events:
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

Ensure your PVs are Bound and PVCs are Bound to the correct PV.

A user wants to deploy a database that needs 50GB of persistent storage. Which Kubernetes resource directly represents the request for this storage from the user's application?

We've covered how Kubernetes manages durable storage for your applications:

• PersistentVolumes (PVs) are cluster resources, representing actual storage.
• PersistentVolumeClaims (PVCs) are user requests for storage.
• Kubernetes binds PVCs to suitable PVs based on requirements.
• Access Modes define how storage can be used (RWO, ROX, RWX).
• Storage Classes enable dynamic provisioning of PVs, automating setup.

This system ensures your application data persists even if Pods come and go, providing reliability for stateful applications.