🐶
Kubernetes

Kubernetes PV vs PVC Explained: Simple Terms

By Jan on 01/31/2025

Learn the key difference between Kubernetes Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) and how they provide storage for your applications.

Kubernetes PV vs PVC Explained: Simple Terms

Table of Contents

Introduction

In Kubernetes, managing storage for your applications involves a system of Persistent Volumes (PVs), Persistent Volume Claims (PVCs), and StorageClasses. This system ensures that your applications have access to the storage they need, even if they are moved between nodes in the cluster.

Step-by-Step Guide

Imagine you have a team of developers (Pods) who need storage space for their projects.

  1. Persistent Volume (PV): Think of PVs like empty external hard drives available in a storage room. The cluster admin sets up these PVs with specific sizes and capabilities (like how fast they are).

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: my-pv
    spec:
      capacity:
        storage: 1Gi
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain
      nfs:
        server: 172.17.0.2
        path: /volume1
  2. Persistent Volume Claim (PVC): A developer (Pod) needing storage creates a PVC, which is like a request form. They specify how much space they need and how they want to use it (read-only, read-write).

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: my-pvc
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 500Mi
  3. Binding: Kubernetes acts as the storage manager. It finds a suitable "hard drive" (PV) that matches the developer's request (PVC) and connects them.

  4. Usage: Now, the developer (Pod) can use the storage through the PVC. They don't need to know the details of the actual "hard drive" (PV).

  5. StorageClass: To simplify things further, admins can create StorageClasses, which are like storage plans (bronze, silver, gold). Developers can request storage based on these plans without worrying about the specifics.

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: slow
    provisioner: kubernetes.io/aws-ebs
    parameters:
      type: io1
      iopsPerGB: "10"

In essence:

  • PVs are the actual storage resources.
  • PVCs are requests for storage by developers (Pods).
  • StorageClasses are predefined storage "plans" for easier management.

Code Example

This code demonstrates how Kubernetes manages storage for applications. An administrator defines storage resources (PersistentVolumes) and classifies them using StorageClasses (fast and slow). Developers then create PersistentVolumeClaims, specifying the desired storage size and class, without dealing with the underlying infrastructure. Kubernetes automatically binds these claims to matching PersistentVolumes. Finally, the application Pods utilize these claims to mount the storage at specific locations, enabling data persistence and access. This abstraction simplifies storage management for developers and ensures efficient resource utilization.

Let's imagine we have two developer Pods:

  • Frontend Pod: Needs 500Mi of storage for website assets.
  • Database Pod: Needs 2Gi of storage for a database.

1. Admin Sets up PVs and StorageClasses:

# pv-fast.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-fast
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 172.17.0.2
    path: /volume1

# pv-slow.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-slow
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 172.17.0.2
    path: /volume2

# storageclass-fast.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: kubernetes.io/aws-ebs # Replace with your provisioner
parameters:
  type: io1
  iopsPerGB: "100"

# storageclass-slow.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs # Replace with your provisioner
parameters:
  type: io1
  iopsPerGB: "10"

2. Developers Create PVCs:

# frontend-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: frontend-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
  storageClassName: fast # Requesting "fast" storage

# database-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  storageClassName: slow # Requesting "slow" storage

3. Pods Use PVCs:

# frontend-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
spec:
  containers:
  - name: frontend
    image: nginx
    volumeMounts:
    - mountPath: /var/www/html
      name: frontend-volume
  volumes:
  - name: frontend-volume
    persistentVolumeClaim:
      claimName: frontend-pvc

# database-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: database-pod
spec:
  containers:
  - name: database
    image: mysql
    volumeMounts:
    - mountPath: /var/lib/mysql
      name: database-volume
  volumes:
  - name: database-volume
    persistentVolumeClaim:
      claimName: database-pvc

Explanation:

  • The admin sets up two PVs ("pv-fast" and "pv-slow") and two StorageClasses ("fast" and "slow").
  • The Frontend Pod requests 500Mi of "fast" storage through its PVC ("frontend-pvc").
  • The Database Pod requests 2Gi of "slow" storage through its PVC ("database-pvc").
  • Kubernetes binds the PVCs to suitable PVs based on their requirements and StorageClass definitions.
  • Both Pods can now access their allocated storage through the defined mount paths, without needing to know the details of the underlying PVs.

This example demonstrates how Kubernetes simplifies storage management for developers by abstracting the underlying infrastructure and providing a flexible way to request and consume storage resources.

Additional Notes

Important Considerations:

  • Access Modes: PVs and PVCs have access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) that define how the storage can be accessed by Pods. This is crucial for data consistency.
  • Reclaim Policies: PVs have reclaim policies (Retain, Recycle, Delete) that determine what happens to the storage when a PVC is deleted. This impacts data retention and cleanup.
  • Dynamic Provisioning: Instead of manually creating PVs, you can use StorageClasses with provisioners to automatically provision storage from cloud providers like AWS, Azure, or GCP.
  • Storage Backends: Kubernetes supports various storage backends, including network-attached storage (NFS), cloud block storage (EBS, AzureDisk), and local storage.
  • StatefulSets: For applications that require stable storage with persistent identities (like databases), StatefulSets are used in conjunction with PVCs.

Benefits of using PVs, PVCs, and StorageClasses:

  • Abstraction: Developers focus on application logic, not storage infrastructure.
  • Portability: Applications can be easily moved between environments without storage configuration changes.
  • Flexibility: Different storage "plans" (StorageClasses) can be offered based on application needs.
  • Scalability: Storage can be easily scaled up or down as needed.

Beyond the Basics:

  • Volume Snapshots: Create point-in-time copies of PVs for backups and restores.
  • CSI Drivers: Container Storage Interface (CSI) allows for extending Kubernetes with new storage plugins.
  • Monitoring and Management: Monitor storage usage, performance, and availability using Kubernetes tools and dashboards.

In short, Kubernetes provides a robust and flexible system for managing storage, making it well-suited for running stateful applications in a cloud-native environment.

Summary

This article explains how Kubernetes manages storage for developer projects (Pods) using an analogy of hard drives and request forms.

Concept Analogy Description
Persistent Volume (PV) External Hard Drive A pre-provisioned storage resource with defined size and capabilities, managed by the cluster admin.
Persistent Volume Claim (PVC) Storage Request Form A request for storage by a developer (Pod), specifying the desired size and access mode.
Binding Storage Manager Kubernetes automatically matches a suitable PV to a PVC, connecting the storage to the Pod.
StorageClass Storage Plan Predefined storage "plans" (e.g., bronze, silver, gold) that simplify storage provisioning for developers.

In short: Developers request storage through PVCs, Kubernetes finds matching PVs, and StorageClasses offer predefined storage options for easier management.

Conclusion

Kubernetes simplifies storage management for applications by abstracting the underlying infrastructure. Persistent Volumes (PVs) represent raw storage resources, while Persistent Volume Claims (PVCs) act as requests for storage by applications. StorageClasses further simplify this process by offering predefined storage "plans" with specific characteristics. This system ensures that applications have access to the storage they need, regardless of their location within the cluster, and enables efficient resource utilization. By decoupling storage provisioning from application deployment, Kubernetes empowers developers to focus on application logic rather than infrastructure details, ultimately leading to more portable, scalable, and manageable deployments.

References

Were You Able to Follow the Instructions?

😍Love it!
😊Yes
😐Meh-gical
😞No
🤮Clickbait