Gopal Gautam's Blog

Day 36 Task: Managing Persistent Volumes in Your Deployment

Gopal Gautam's photo
Gopal Gautam
·

3 min read

Table of contents

🔹Persistent Volume (PV)

  • A Persistent Volume (PV) is a resource that represents a piece of storage in a cluster.

  • PVs are provisioned and managed by cluster administrators.

  • They abstract the details of the underlying storage, allowing developers and applications to request storage without worrying about its physical characteristics.

  • PVs have a lifecycle independent of pods. They can be created, claimed, and released separately from pods.

  • PVs can be dynamically provisioned or statically defined.

  • PVs are associated with a specific storage plugin or backend, like NFS, AWS EBS, or a local filesystem.

  • PVs have a reclaim policy that determines what happens to the storage when the PV is released: "Delete," "Retain," or "Recycle" (deprecated).

🔹Persistent Volume Claim (PVC):

  • A Persistent Volume Claim (PVC) is a request for storage by a user or a pod.

  • PVCs are created by developers or applications to request a specific amount of storage with defined characteristics.

  • PVCs are bound to available PVs that match the criteria defined in the Storage Class specified in the claim.

  • They have a similar lifecycle to pods. When a PVC is deleted, the associated PV may be released, allowing it to be used by another claim.

  • PVCs can request storage with specific access modes, which define how the pod can use the storage.

Access Modes: Kubernetes supports three access modes for volumes, which define how the storage can be accessed by pods:

  1. ReadWriteOnce (RWO):

    • This mode allows the volume to be mounted as read-write by a single node (pod) at a time.

    • It's suitable for scenarios where only one pod should have read-write access to the storage, like a database that should be accessible from only one replica.

  2. ReadOnlyMany (ROX):

    • In this mode, multiple nodes (pods) can mount the volume as read-only simultaneously.

    • It's useful when you want multiple pods to read data from the same storage but not write to it, such as sharing configuration files.

  3. ReadWriteMany (RWX):

    • RWX allows the volume to be mounted as read-write by multiple nodes (pods) concurrently.

    • It's typically used for scenarios where multiple pods need both read and write access to shared storage, like a file server.

🔹Task1:

Add a Persistent Volume to your Deployment todo app.

Create a Persistent Volume:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: persistent-volume-todop
spec:
  capacity:
    storage: 500Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: "/tmp/data"

Create a Persistent Volume Claim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: persistent-volume-claims-todo
spec:
  volumeName: persistent-volume-todop
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

Update your deployment.yml file to include the Persistent Volume Claim. After Applying pv.yml pvc.yml your deployment file look like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: todo-app
  labels:
    app: todo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: todo
  template:
    metadata:
      labels:
        app: todo
    spec:
      containers:
      - name: todo
        image: gopalgtm001/node-app:latest
        ports:
        - containerPort: 8000
        volumeMounts:
            - name: todo-app-data
              mountPath: /app/data
      volumes:
        - name: todo-app-data
          persistentVolumeClaim:
            claimName: persistent-volume-claims-todo

Access the data in the Persistent Volume.

#day36TrainWithShubham#90daysofdevopsKubernetes