Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 29

Understanding Persistent Volumes (PVs) in Kubernetes

Recommended resources

Hello! Welcome back to our module on Persistent Storage Fundamentals.

In our last lesson, we explored the emptyDir and hostPath volume types. We concluded that while they have specific, useful roles (like sharing files within a Pod or accessing node-level system files), they fall short for general-purpose applications. Their data lifecycle is tied to either the Pod or a specific Node, making them unsuitable for robust, portable, stateful applications in a multi-node cluster.

This lesson tackles that problem head-on. Our learning goal is to describe the role of a PersistentVolume (PV) as a piece of storage in the cluster. A PersistentVolume is the foundational Kubernetes object that allows us to manage storage that lives independently of any Pod or Node, finally giving us true persistence.

As a Platform Engineer, understanding PVs is crucial, as they represent the point where your responsibility for managing the cluster's underlying infrastructure (like cloud storage or on-premise SANs) meets the world of Kubernetes.

1. From Node-Bound Storage to a Cluster Resource

The core problem with hostPath was that the data was stuck on one node. If a Pod was rescheduled to another node, the data was lost. To solve this, Kubernetes introduces an abstraction layer for storage. Instead of a Pod mounting a directory from a specific node, it will request storage from the cluster itself. This is where the PersistentVolume comes in.

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator. Think of it as a cluster-wide resource, just like CPU or memory, but for storage.

Kubernetes Volumes explained | Persistent Volume, Persistent Volume Claim & Storage Class

To start, let's watch a segment from the 'Kubernetes Volumes explained' video by TechWorld with Nana. It introduces the concept of a PersistentVolume as an abstract component that represents actual physical storage.

Watch from 02:02 to 03:42. Focus on how a PV is defined as a cluster resource and how it acts as an interface to various physical storage backends, like a local disk, an NFS server, or cloud storage.

As the video explains, a PV is an API object that captures the details of a storage implementation—be it an AWS Elastic Block Store (EBS) volume, an Azure Disk, a Google Persistent Disk, or an on-premise NFS share. The key idea is that the PV abstracts away the specifics of the storage provider.

A few critical characteristics of a PV are:

  • Independent Lifecycle: A PV's lifecycle is not tied to any Pod. The storage exists and persists data whether a Pod is using it or not.
  • Cluster-Scoped: Unlike Pods, Deployments, or Services that live inside a namespace, a PV is a cluster-wide resource. It's available to be claimed by any namespace in the cluster (within access rules).
  • An Abstraction: It separates the definition of storage from its consumption.

This model neatly aligns with your experience managing cloud infrastructure. You provision a block storage volume (like EBS) in AWS, and then a VM can attach and use it. The PV plays a similar role within Kubernetes.

2. The Administrator's Role: Provisioning Storage

So, who creates these PersistentVolumes? This is where your role as a Platform Engineer comes into play. Typically, a cluster administrator or platform team is responsible for setting up the underlying storage and then creating PV objects in Kubernetes to make that storage available to developers.

This creates a clear separation of concerns:

  • Administrator / Platform Engineer: Provisions physical or cloud storage, manages its lifecycle (backups, security), and creates PersistentVolumes in Kubernetes that represent that storage.
  • Developer / User: Consumes the available storage by making a request (which we'll cover in the next lesson) without needing to know the low-level details of the storage backend.
Kubernetes PersistentVolume (PV) and PersistentVolumeClaim (PVC) Workflow
This diagram illustrates the separation of roles. The **Admin** (steps 1-2) sets up the actual network storage and creates a PersistentVolume in Kubernetes. Later, a **User** (steps 3-5) will claim and use this volume.

This workflow is fundamental. Your responsibility is to ensure that a "pool" of storage is available to the cluster for applications to use.

Kubernetes Volumes explained | Persistent Volume, Persistent Volume Claim & Storage Class

Let's hear this distinction explained clearly in another clip from TechWorld with Nana. This directly relates to the roles in a typical DevOps or platform team.

Watch from 07:43 to 09:13. The video breaks down the responsibilities of the 'Kubernetes administrator' and the 'Kubernetes user' in the context of persistent storage.

3. The Anatomy of a PersistentVolume

Now let's get practical and look at what a PersistentVolume manifest looks like. We'll use a hostPath PV for this example, as it's simple and builds on what you learned in the last lesson. Remember, in production you'd use a more robust type like awsElasticBlockStore, azureDisk, or nfs.

Configure a Pod to Use a PersistentVolume for Storage

The official Kubernetes documentation provides a great hands-on example. Please read the section on creating a PersistentVolume. We'll break down the key fields right after.

Read the section titled 'Create a PersistentVolume'. Focus on the YAML configuration file (pv-volume.yaml) and the explanation of its fields. Also, note the STATUS of the PV after it's created.

Let's dissect the spec of the PV from that example:

spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
  • capacity.storage: This is straightforward—it defines the total size of the storage volume.
  • accessModes: This is a crucial field that defines how the volume can be mounted. It's a list that can contain one or more of the following:
    • ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node. This is common for block storage like AWS EBS or Azure Disk.
    • ReadOnlyMany (ROX): The volume can be mounted as read-only by many nodes.
    • ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes. This is typically supported by file-based storage like NFS.
  • storageClassName: This is used to classify storage. A name like slow or fast-ssd could be used to differentiate types of storage. For now, manual tells Kubernetes that this PV must be manually assigned to a request. We'll touch on what happens when you use other names later.
  • hostPath / nfs / awsElasticBlockStore etc.: This is the "plug-in" section. It defines the actual backend storage type and its specific configuration, like the server path for nfs or the volume ID for awsElasticBlockStore.

After creating the PV, kubectl get pv shows its STATUS as Available. This means it has been successfully provisioned into the cluster and is ready to be used, but nothing is using it yet.

Kubernetes Persistent Volume (PV) and Persistent Volume Claim (PVC) Architecture
This diagram reinforces the concept. The Cluster Admin manages a set of PersistentVolumes, each with different capacities, access modes, and backend storage types (like AWS EBS or GCE PD), making them available for Pods to use.
Test your understanding!

You need to provide storage for a new application. The application is a legacy system that requires a shared filesystem where multiple instances of the application (running on different nodes) can all read and write to the same files simultaneously.

When creating the PersistentVolume to support this application, which accessMode would you choose and why?

Show answer

You would need to choose ReadWriteMany (RWX).

The requirement is that multiple application instances on different nodes need to read and write to the storage at the same time.

  • ReadWriteOnce (RWO) would not work because it only allows a single node to mount the volume as read-write.
  • ReadOnlyMany (ROX) would not work because the application needs to write data, not just read it.

Therefore, ReadWriteMany is the only access mode that meets the requirement. This would also constrain your choice of underlying storage technology to one that supports this mode, such as NFS or a cloud provider's managed file service.

Conclusion

In this lesson, we've focused on the administrator's side of Kubernetes storage. We've defined the PersistentVolume as the essential abstraction that decouples storage from individual nodes and Pods.

Key Takeaways:

  • A PersistentVolume (PV) is a cluster-scoped API object representing a piece of physical storage.
  • It has a lifecycle independent of any Pod, allowing data to persist.
  • It's the responsibility of the cluster administrator or platform engineer to provision the underlying storage and create the PV object.
  • The PV manifest specifies key properties like capacity, access modes (RWO, ROX, RWX), and the configuration for the actual storage backend (e.g., nfs, awsElasticBlockStore).
  • An unused PV has a status of Available, meaning it's ready for a developer's application to claim it.

Next Up:
We've established the "supply" side of storage. But how do applications "consume" it? In the next lesson, we will introduce the other crucial half of this system: the PersistentVolumeClaim (PVC). You'll learn how a developer requests storage with a PVC and how Kubernetes orchestrates the "binding" process between a PVC and an available PV.