🔹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:
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.
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.
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.
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.