Application code is used to store the transactional data into the database and that datastore should be the persistent. Kubernetes provide a way to manage the data management through the Persistent Volume and Pods are associated with PersistentVolumeClaim to use PersistentVolume.

PersistentVolume can be understood as the storage on the cluster. This storage is provisioned by the cluster administrator statically. This storage can also be provisioned dynamically using the storage class. PersistentVolume can be considered as the storage plugin for which, implementation is provided by the many vendors (like Cloud providers, NFS).

Example for Creating Persistent Volume

apiVersion: v1
kind: PersistentVolume
metadata: 
    name: mysql-bill-pv
    labels: 
       app: mysql-bill-pv-app 
spec: 
    storageClassName: standard
    capacity: 
        storage: 256Mi
    accessModes: 
        - ReadWriteOnce
    hostPath: 
        path: "docker-data/restaurant/k8/mysql-billing"
    persistentVolumeReclaimPolicy: Retain

PersistentVolumeClaim is using the PersistentVolume to store the data produced by the pods (Containers). PVC has its own set of specification that is matched with the PV while binding, which include the accessModes, storage capacity etc.

Example for Creating Persistent Volume Claim

apiVersion: v1
kind: PersistentVolumeClaim
metadata: 
    name: mysql-order-pvc
    labels: 
       app: mysql-order-pvc-app
    
spec: 
    storageClassName: standard
    accessModes:
        - ReadWriteOnce
    resources: 
        requests:
           storage: 250Mi 

PersistentVolume are the resource on the cluster and PVC are the request to that resource. So Pods are accessing storage in form of PersistentVolume through the PersistentVolumeClaim.

apiVersion: v1
kind: PersistentVolume
metadata: 
    name: mysql-order-pv
    labels: 
       app: mysql-order-pv-app 
spec: 
    storageClassName: standard
    capacity: 
        storage: 256Mi
    accessModes: 
        - ReadWriteOnce
    hostPath: 
        path: <HOST-PATH> #LOCAL PATH TO THE SYSTEM 
    persistentVolumeReclaimPolicy: Retain

apiVersion: apps/v1
kind: StatefulSet
metadata: 
 name: mysql-order-server
 labels:   
   app: mysql-order-server-app
spec: 
 selector: 
   matchLabels:
      app: mysql-order-app-pod
   replicas: 1
   template: 
    metadata: 
      name: mysql-order-pod
      labels: 
        app: mysql-order-app-pod
    spec: 
     containers: 
      - name: mysql-container
        image:  mysql/mysql-server:8.0.23
        ports:
          - containerPort: 3306
        env:
        volumeMounts: 
          - name: mysql-server-storage
            mountPath: /var/lib/mysql
      volumes:
        - name: mysql-server-storage
          persistentVolumeClaim: 
            claimName:  mysql-order-pvc

Above configuration for PersistentVolume is a storage with capacity 256Mi and accessMode is created.

StatefulSet mysql-order-server claim this storage through the PersistentVolumeClaim mysql-order-pvc

Volume and claim have the following lifecycle

Provisioning a resource can be interpreted as

apiVersion: storage.k8s.io/v1
kind: StorageClass
metdata: 
  name: itlogiclab-google-storage
  labels: 
      app: itlogiclab-storage
provisioner: kubernetes.io/gce-pd

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata: 
    name: mysql-order-pvc
    labels: 
       app: mysql-order-pvc-app
spec: 
    storageClassName: itlogiclab-google-storage
    accessModes:
        - ReadWriteOnce
    resources: 
        requests:
           storage: 250Mi 

StorageClass config is used to dynamically provision the google storage through the provisioner kubernetes.io/gce-pd . This StorageClass then associated with PVC under storageClassName field.

Note: When PVC is created, then the storage class associated with it use the defined provisioner to provision the new disk on the provisioner provider (GCP). Then it bind the PVC with the volume defined in the pod specification. PV are still get created, but it is created by the StorageClass.

Binding is a process, when Persistent Volume is bind with the Persistent Volume Claim. When Persistent Volume and claims are created, they bound with each other on the basis of few factors like their size. Control plane consist of control loop which look for new PVC, then it find the PV (if available) and bind.

With dynamic provisioning, PV is always bind with PVC in case of the dynamic provisioning.

Persistent Volumes are attached in pods through persistent Volume Claim. using the storage as claim as a volume mount.

The snippet below is used, when pod need to access a storage. Details are described as in the table.

VolumeMounts:

Volume:

POD: volumeMount and Volume Specification: 
          volumeMounts: 
            - name: mysql-server-storage
              mountPath: /var/lib/mysql

    volumes:
        - name: mysql-server-storage
          persistentVolumeClaim: 
              claimName:  mysql-order-pvc

When storage volume are detached from the pod, then based on the reclaim policy defined in the PersistentVolume , cluster reclaim the storage resource after it has been released with the PVC. Volume can have following reclaim policy.

This is a very brief introduction of the storage in kubernetes. With this basic understanding can be develop. Thanks for reading.

Credit: 
Kubenetes docs