Using Persistent Volume Claims in a Pod (PVC)

Luke Hebert

- 3 minutes read - 426 words

Persistent storage in Kubernetes is handled through two complementary objects: the PersistentVolume (PV) and the PersistentVolumeClaim (PVC). A PV represents a piece of storage in the cluster, provisioned either by an administrator or dynamically by a StorageClass. A PVC is a request for that storage, made by a user or a Pod. Once a PVC is created, you reference it inside a Pod (or Deployment/ReplicaSet) by naming the claim under the persistentVolumeClaim key in the volumes section. The example below shows a minimal Pod that mounts a PVC at /var/www/html for an Nginx container.

How PVs and PVCs Work Together

Think of a PV as the actual disk and a PVC as the ticket requesting access to it. The Kubernetes scheduler binds a PVC to a compatible PV based on size, access mode, and storage class. From the Pod’s perspective, it only ever sees the PVC; the underlying PV can be a local disk, an NFS share, an EBS volume, or any other backend. This abstraction means you can swap storage backends without changing your workload definitions.

Referencing a PVC in a Pod

Once you create a PVC, use it in a Pod definition file by specifying the PVC claim name under the persistentVolumeClaim section in the volumes section, like this:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
        - mountPath: "/var/www/html"
          name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim
Note

The same approach applies to ReplicaSets and Deployments. Add the volume and volumeMount definitions to the pod template section of a Deployment or ReplicaSet.

Access Modes

When defining a PV or PVC, you choose an access mode that controls how the volume can be mounted:

  • ReadWriteOnce (RWO) - The volume is mounted as read-write by a single node.
  • ReadOnlyMany (ROX) - The volume is mounted read-only by many nodes.
  • ReadWriteMany (RWX) - The volume is mounted as read-write by many nodes.
  • ReadWriteOncePod (RWOP) - The volume is mounted as read-write by a single Pod.

Not every backend supports every mode, so check your storage provider’s documentation before selecting one.

Static vs. Dynamic Provisioning

You can provision storage in two ways:

  • Static - An administrator creates PVs ahead of time, and users create PVCs that match them.
  • Dynamic - A StorageClass defines a provisioner (such as kubernetes.io/aws-ebs or kubernetes.io/nfs), and Kubernetes creates a PV automatically when a PVC is made.

Dynamic provisioning is the more common approach in production clusters because it removes the manual step of pre-creating volumes.

References