Skip to content

Latest commit

 

History

History
80 lines (64 loc) · 3.28 KB

pv-vs-pvc.md

File metadata and controls

80 lines (64 loc) · 3.28 KB

Difference Between PersistentVolumeClaim and PersistentVolume in Kubernetes

PersistentVolume (PV)

  1. Definition: A PersistentVolume is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.
  2. Lifecycle: Managed by the cluster. It exists independently of any individual pod.
  3. Provisioning: Can be provisioned statically by an administrator or dynamically based on StorageClasses.
  4. Scope: Cluster-wide resource. It is not namespace-specific.
  5. Types: Can represent different types of storage such as GCEPersistentDisk, AWSElasticBlockStore, NFS, or a local storage device.
  6. Reclamation Policy: Defines what happens to the PV after the PVC has been deleted. Common policies are Retain, Recycle, and Delete.

PersistentVolumeClaim (PVC)

  1. Definition: A PersistentVolumeClaim is a request for storage by a user. It is similar to a pod in that pods consume node resources, and PVCs consume PV resources.
  2. Lifecycle: Managed by the user (or the application). It binds to a PersistentVolume.
  3. Provisioning: Claims specific storage (size, access modes) which is then bound to an available PV that satisfies the request.
  4. Scope: Namespace-specific resource. PVCs are created within a specific namespace.
  5. Usage: Pods use PVCs as volumes. The PVC requests storage resources and once bound, the pod can use the storage.
  6. Binding: Once a PVC is created, Kubernetes looks for a suitable PV to bind to the PVC. This binding is a one-to-one mapping.

Summary of Interaction

  1. PV Provisioning: Administrator creates a PV (or a StorageClass for dynamic provisioning).
  2. PVC Creation: User/application creates a PVC requesting storage.
  3. Binding: Kubernetes control plane matches a PVC to an appropriate PV.
  4. Usage: The PV is mounted as a volume in the pod that uses the PVC.

This separation allows for greater flexibility and decoupling of storage provisioning from storage usage in Kubernetes. Administrators can manage the storage backend and policies, while users can request and use storage without needing to know the specifics of the underlying infrastructure.

Examples

apiVersion: v1
kind: PersistentVolume
metadata:
  name: grafana-pv
  namespace: monitoring
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/storage/grafana

Here a PersistentVolume gives a location of where the storage is to be placed. Eg: Which mount / drive you want to store the data on.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana-pvc
  namespace: monitoring
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

The PersistentVolumeClaim makes a claim for that storage location that the PersistentVolume has made.

# deployment.yaml

  volumeMounts:
    - name: grafana-storage
      mountPath: /var/lib/grafana
volumes:
- name: grafana-storage
  persistentVolumeClaim:
    claimName: grafana-pvc

Here in the deployment.yaml the volumeMounts is the default location where the app stores is its data in this case Grafana stores its data in /var/lib/grafana.

Then it's claimed via the persistentVolumeClaim in volumes