Introduction to Persistent Storage

Kubernetes is designed to run stateless applications, but many applications need to store data persistently. To address this, Kubernetes offers several mechanisms for managing persistent storage, such as **Persistent Volumes (PVs)** and **Persistent Volume Claims (PVCs)**.

In Kubernetes, **Persistent Volumes (PVs)** are pieces of storage that are provisioned either manually or dynamically, and **Persistent Volume Claims (PVCs)** are requests for storage by users.

Persistent Volumes (PVs)

A **Persistent Volume (PV)** is a piece of storage that has been provisioned in the cluster. PVs exist independent of Pods and are managed by Kubernetes. They can be backed by different storage backends such as local storage, NFS, or cloud-based storage (e.g., AWS EBS, GCP Persistent Disks).

Example of a Persistent Volume definition:

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

In this example, the PV is using a local path `/mnt/data` and has a capacity of `5Gi`. The access mode `ReadWriteOnce` means that only one node can mount the volume for read and write.

Persistent Volume Claims (PVCs)

A **Persistent Volume Claim (PVC)** is a request for storage by a user. It specifies the amount of storage, access modes, and other properties. PVCs allow you to request specific resources without having to worry about how the underlying storage is provisioned.

Example of a Persistent Volume Claim definition:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

In this example, the PVC requests a `3Gi` storage volume with the access mode `ReadWriteOnce`.

Binding PVCs to PVs

Once a PVC is created, Kubernetes will attempt to bind it to an appropriate PV. If a matching PV exists (e.g., one with enough capacity and compatible access modes), the PVC will be bound to the PV automatically.

Using PVC in Pods

After the PVC is created and bound to a PV, you can mount the volume into your Pods. Here's an example of how to mount a PVC into a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: my-container
      image: myapp:latest
      volumeMounts:
        - mountPath: /data
          name: my-storage
  volumes:
    - name: my-storage
      persistentVolumeClaim:
        claimName: my-pvc

In this example, the PVC `my-pvc` is mounted to the `/data` directory inside the container.

Dynamic Provisioning of PVs

Kubernetes supports **dynamic provisioning** of Persistent Volumes. This means that you can automatically provision storage when a PVC is created without needing to manually define PVs.

To enable dynamic provisioning, a StorageClass is defined in the cluster. The PVC will reference this StorageClass, and Kubernetes will provision the required storage dynamically.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2

The above `StorageClass` configures dynamic provisioning using AWS EBS with the `gp2` volume type.

Storage Reclaim Policy

After a PVC is deleted, the associated PV can either be deleted or retained based on the **Reclaim Policy**. The policy can be set to either `Delete` (delete the PV when the PVC is deleted) or `Retain` (keep the PV even after the PVC is deleted).

Conclusion

Kubernetes provides powerful mechanisms for managing persistent storage using Persistent Volumes and Persistent Volume Claims. Whether you are using local storage or cloud-based storage, Kubernetes allows you to easily manage data persistence across Pod restarts and failures.