Learn the key difference between Kubernetes Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) and how they provide storage for your applications.
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.
Imagine you have a team of developers (Pods) who need storage space for their projects.
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
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
Binding: Kubernetes acts as the storage manager. It finds a suitable "hard drive" (PV) that matches the developer's request (PVC) and connects them.
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).
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:
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:
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:
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.
Important Considerations:
Benefits of using PVs, PVCs, and StorageClasses:
Beyond the Basics:
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.
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.
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.