Skip to content

Volumes

You want disk that outlives the pod using it. On AWS that is an EBS volume for one instance, or EFS when several need the same files. The same split exists here, and choosing between the two is the main decision.

You ask for storage with a PersistentVolumeClaim; the storage operator provisions a disk and binds it to your claim. There is nothing to pre-create.

Prerequisites

  • A project you can create resources in
  • A view on how many workloads need the same data at once

The step-by-step guide and the console walkthrough cover the operations. The rest of this page explains how it fits together.

How it fits together

flowchart LR
    PVC["PersistentVolumeClaim<br/>you ask for size + class"]
    SC["StorageClass<br/>decides the kind of disk"]
    CSI["CSI driver"]
    PV["PersistentVolume<br/>provisioned on demand"]
    POD["your pod<br/>mounts it"]
    PVC -->|storageClassName| SC
    SC --> CSI
    CSI -->|creates| PV
    PV -->|Bound| PVC
    PVC --> POD

Bound means a disk exists and is attached to your claim. A claim that stays Pending has not been given one, and the event on the claim says why - usually a storage class that does not exist, an access mode it cannot provide, or no capacity left.

Block or file, fixed at creation

Kind Access mode Use it for
Block ReadWriteOnce one workload at a time - databases, anything with its own storage engine
File ReadWriteMany several workloads at once - shared uploads, content directories

ReadWriteOnce means one node at a time, which in practice means one pod.

This is the most common storage mistake here

Give a ReadWriteOnce volume to a Deployment with two replicas and the second pod stays Pending forever, with an event saying the volume is already attached elsewhere. It looks like a scheduling problem and it is not.

If more than one pod needs the same data, choose a file storage class and ReadWriteMany at creation. Neither the class nor the access mode can be changed afterwards - the fix is a second claim and a copy.

Volumes grow and never shrink

A volume can be expanded in place. The filesystem is extended when the pod next starts, or immediately if the storage class supports expanding a mounted volume.

It cannot be shrunk, so size for what you need rather than the most you might.

What deleting does

The classes here delete the disk with the claim

reclaimPolicy on the storage class decides, and on this platform it is Delete. There is no undo and no snapshot taken on your behalf.

A claim mounted by a running pod stays Terminating until that pod is gone. That is the protection working - scale the workload down rather than forcing it.