Storage¶
A pod's own filesystem is discarded when the pod is replaced. Persistent storage separates the lifetime of the data from the lifetime of the pod using it.
You request storage by creating a PersistentVolumeClaim in your project, stating how much
capacity you need and which access mode. A CSI driver provisions a PersistentVolume to
satisfy the claim, binds the two together, and attaches the volume to whichever node your
pod is scheduled on. You never create the PersistentVolume yourself and you do not need to
know what the storage is made of. Object storage follows the same pattern through an
ObjectBucketClaim.
A claim belongs to one project. Once a PersistentVolume is bound to a claim it cannot be
bound to another, which scopes the volume to the project that claimed it.
The three types below are three access contracts rather than three quality levels. Moving
between them is a StorageClass change rather than an application rewrite.
| Type | Access mode | Typical use |
|---|---|---|
| Block | ReadWriteOnce |
Databases, message brokers, VM disks |
| File | ReadWriteMany |
Shared document roots, upload directories |
| Object | S3 over HTTPS | Backups, artifacts, datasets, model weights |
What this section will cover¶
- Available StorageClasses and their characteristics
- Snapshots, clones and online expansion
- Cross-zone replication and durability
- S3 endpoints and credentials
How to¶
Step-by-step guides for each of these, in the console and as YAML: