Understanding Storage in Kubernetes: A Deep Dive into Persistent Volumes and Persistent Volume Claims

Welcome to the 29th installment of our CK2024 blog series! In this article, we'll be exploring the crucial topic of storage within Kubernetes, focusing on Persistent Volumes (PV), Persistent Volume Claims (PVC), and Storage Classes. If you’re familiar with Docker storage concepts, you’ll find this discussion particularly relevant as we bridge the gap between Docker and Kubernetes storage mechanisms.

Introduction to Storage in Kubernetes

Storage in Kubernetes is fundamental to ensuring that your applications can manage and persist data effectively. Unlike Docker, where storage is tied to individual containers, Kubernetes abstracts storage through the concepts of Persistent Volumes (PV) and Persistent Volume Claims (PVC). Understanding these components is key to managing stateful applications within Kubernetes.

Persistent Volumes (PV) and Persistent Volume Claims (PVC)

• Persistent Volume (PV): A PV is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It represents a storage resource that can be used by Pods.
• Persistent Volume Claim (PVC): A PVC is a request for storage by a user. It specifies the amount of storage, access modes (e.g., read-write or read-only), and other requirements. The Kubernetes scheduler binds PVCs to PVs based on these requirements.

How PV and PVC Work Together

1. Provisioning a PV:
   An administrator creates a PV with a defined storage capacity, access modes, and other attributes. For example, a PV could have 100 GiB of storage with read-write permissions.

2. Creating a PVC:
   A user creates a PVC specifying their storage needs, such as 10 GiB of storage. Kubernetes matches this PVC with a suitable PV based on the requested capacity and access mode.

3. Binding PVC to PV:
   Once a match is found, the PVC is bound to the PV. The PV’s available capacity is reduced by the amount allocated to the PVC. For instance, if a PV initially had 100 GiB and a PVC requests 10 GiB, the PV’s remaining capacity becomes 90 GiB.

4. Usage by Pods:
   The PVC is then used by Pods to mount the storage, allowing applications to read from and write to the mounted volume.

Practical Example: Using PV and PVC in a Pod

Let’s walk through a practical example of how to use PV and PVC in a Kubernetes Pod:

1. Define the Persistent Volume (PV):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

1. Create the Persistent Volume Claim (PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

1. Use the PVC in a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: my-storage
  volumes:
  - name: my-storage
    persistentVolumeClaim:
      claimName: my-pvc

In this example, the my-pod Pod mounts storage from the my-pvc PVC, which is bound to the my-pv PV. This allows the Pod’s container to use the storage defined by the PVC.

Storage Classes

Storage Classes provide a way to define different types of storage with varying performance and cost characteristics. They abstract the provisioning of storage and enable dynamic volume provisioning.

A Storage Class defines the storage types and parameters used for provisioning PVs. It allows users to request specific types of storage based on their application requirements.

Example of a Storage Class:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2

In this example, the fast-storage Storage Class uses AWS EBS (Elastic Block Store) with the gp2 type for high-performance storage.

Conclusion

Understanding and properly implementing PVs, PVCs, and Storage Classes are essential for managing stateful applications in Kubernetes. These components help ensure that your applications can handle persistent data across Pod restarts and scaling events.

Stay tuned for the next article in our CK2024 series, where we’ll dive into more advanced Kubernetes topics.

For further reference, check out the detailed YouTube video here: