What are Persistent Volume?

Persistent Volumes provides a way to manage and use storage in a flexible and durable manner, separate from the pods that consume it. They help ensure that data persists even when pods come and go. PVs are separate entities from pods. They're like external hard drives attached to a computer. PV is used for storing data that needs to persist even if the pod using it is deleted or recreated. For example, a database would store its data in a Persistent Volume so that even if the database pod is restarted or moved, the data remains intact. There are different types of Persistent Volumes, like network-based storage (e.g., NFS, iSCSI), cloud storage (e.g., AWS EBS, Google Cloud Persistent Disks), or local storage. PV provide an abstraction layer, allowing developers to define storage requirements separately from the pods that use them. This separation simplifies management and makes it easier to reuse storage across different pods.

What are Persistent Volume Claims?

A Persistent Volume Claim (PVC) in Kubernetes is like a request form for storage. It's used by pods to ask for a specific amount and type of storage they need. Once approved, Kubernetes finds an appropriate Persistent Volume (PV) to fulfill that request, allowing the pod to use it as storage. Think of it as a way for pods to "claim" the storage they require. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany, ReadWriteMany, or ReadWriteOncePod.

Task 1: Add a Persistent Volume to your Deployment todo app.

• Create a Persistent Volume using a file on your node.

  Note:The deployment file used is the same one as of Day 35.

  Let's create a persistent Volume file containing the path of the disk.

apiVersion: v1
kind: PersistentVolume
metadata: 
    name: mysql-pv
    namespace: mysql
    labels:
      app: mysql
spec:
  storageClassName: manual
  capacity:
    storage: 2Gi
  accessModes: 
    - ReadWriteOnce
  hostPath:
    path: "/home/ubuntu/mysql"

We need to provide storageClassName, capacity, accessModes and hostPath in the persistent volume specifications. A storageClassName, abstracts away the specifics of how storage is provisioned and focus on what characteristics is needed for application's storage requirements. The different types of accessModes provided are ReadWriteOnce, ReadOnlyMany, ReadWriteMany, or ReadWriteOncePod. A capacity is used to set a specific storage for the volume. A hostPath provides a path of a file or directory on the Node to emulate network-attached storage.

Let's apply the persistent volume file - kubectl apply -f <persistent-volume> -n <name-space>

Check whether volume is created or not by - kubectl get pv -n <name-space>

• Create a Persistent Volume Claim that references the Persistent Volume.

  Let's create a persistent Volume Claim file that references the persistent volume.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  namespace: mysql
  labels:
    app: mysql
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

PVC specifies the specific amount required from persistent volume in resources object and requests the storage amount in storage of requests object. It creates a PersistentVolumeClaim that requests a volume of at least one gibibytes that can provide read-write access for at most one Node at a time.

Let's apply the persistent volume claim file - kubectl apply -f <persistent-volume-claim> -n <name-space>

Check whether persistent volume claim is created or not by - kubectl get pvc -n <name-space>

• Update your deployment.yml file to include the Persistent Volume and Persistent Volume Claim

After applying pv.yml and pvc.yml the deployment file looks like this.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-deployment
  namespace: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:8
        name: mysql
        ports:
        - containerPort: 3306
          name: mysql
        env:
          - name: MYSQL_DATABASE
            valueFrom:
              configMapKeyRef:
                name: mysql-configmap
                key: MYSQL_DATABASE

          - name: MYSQL_ROOT_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql-secret
                key: MYSQL_PASSWORD    
        volumeMounts:
        # a mount for site-data
          - name: mysql-persistent-storage
            mountPath: /var/lib/mysql
      volumes: 
         - name: mysql-persistent-storage
           persistentVolumeClaim:
              claimName: mysql-pv-claim

volumeMounts is used to specify the volume name and the path of the container's data which has to be persisted. The Pod's configuration file specifies a persistentVolumeClaim, in volume object but it does not specify a PersistentVolume. From the Pod's point of view, the claim is a volume.

• Apply the updated deployment using the command: kubectl apply -f deployment.yml

  Apply the deployment file to update the configuration using kubectl apply -f deployment.yml -n mysql.

• Verify that the Persistent Volume has been added to your Deployment by checking the status of the Pods and Persistent Volumes in your cluster. Use this commands kubectl get pods , kubectl get pv and kubectl get pvc

  Apply the below commands to check the status of pod, persistent volume and persistent volume claim -

#To check the status of the pod
$ kubectl get pods -o wide -n <namespace>
#To check the status of persistent volume
$kubectl get pv -n <name-space>
#To check the status of persistent volume claim
$kubectl get pvc -n <name-space>

Task 2: Accessing data in the Persistent Volume

• Connect to a Pod in your Deployment using command : `kubectl exec -it bash.

  Let's get inside the container and check whether we are able to see our "cooldb" database or not by using kubectl exec -it <pod-name> -n <name-space> bash Once, we enter the bash command line, give mysql -u root -p and provide the password set in the Secret file to get access to the MySQL container. Use command show databases; to list all the database present in the MySQL. We can see "cooldb" database is present.

    $ kubectl exec -it <pod-name> -n <name-space> bash
    bash# mysql -u root -p
    Enter password:
    mysql> show databases;
  

  

  "cooldb" database is created and visible inside the container.

• Verify that you can access the data stored in the Persistent Volume from within the Pod.

  Let's create a table with some values in the DB.

    #Show the list of database
    mysql> show databases;
  
    #Switch to the desired database
    mysql> use database-name;
  
    #Create table
    mysql> CREATE TABLE table_name (column1 datatype, column2 datatype,
    column3 datatype,....);
  
    #Insert values into table
    mysql> INSERT INTO table_name (column1, column2, column3, ...)
    VALUES (value1, value2, value3, ...);
  
    #Show all the values in the table
    mysql> select * from table_name;
  

  

  

  We can see a table is created with details of one row added in it. Now, let's delete the pod where we have added the data and check if the same added data is available in our newly created pod as a new pod will be created as soon as the old one gets deleted.

    $kubectl get pods -o wide -n <name-space>
    #kubectl delete pods <pod-name> -n <name-space>
  

  

  Let's get inside the new container using exec(the same way as earlier) and see if we are able to access the data which we added in our previous container.

  

  

  We can see the same data which we have added in our old container is present in the new container. Thus, the purpose of persistent volume is served here which means the data is persisted in the volume/disk even when the pods are deleted.

  Thanks for reading!
  Happy Learning!