Persistent Volume Claim

Kubernetes Cluster: Persistent Volume Claim

Whenever a Kubernetes application pod needs persistent storage, it requests access through a Persistent Volume Claim (PVC). The claim defines the required amount of storage and the access mode that the application needs.
Storage Size A PVC specifies how much persistent storage the application needs.
Access Mode A PVC also defines how the persistent volume may be mounted and shared.

Persistent Volume Claim Overview

A Persistent Volume Claim is the Kubernetes mechanism used by application pods to request persistent storage. The claim describes both the required storage capacity and the required access mode.

The platform does not impose additional restrictions on PVC creation. Standard Kubernetes PersistentVolumeClaim functionality can be used directly.

StorageClass Considerations

The Kubernetes Cluster includes the default jelastic-dynamic-volume StorageClass, which works with the built-in volume provisioner.

Important: If a PVC specifies a StorageClass other than the default jelastic-dynamic-volume, the corresponding Persistent Volume must already exist.

This means the built-in dynamic provisioning flow applies to the platform’s default StorageClass. Custom storage configurations may require the Persistent Volume to be prepared separately before the claim can be bound.

Sharing a Persistent Volume

When several pods need to use the same Persistent Volume, verify that the volume supports a compatible multi-pod access mode.

ROX — ReadOnlyMany Allows the volume to be mounted as read-only by multiple pods or nodes.
RWX — ReadWriteMany Allows the same persistent volume to be mounted with read/write access by multiple pods or nodes.
Shared-volume rule: If several pods must use one Persistent Volume, make sure the storage backend supports either ROX or RWX, depending on whether shared write access is required.
A PVC does not create compatibility that the underlying storage does not support. The access mode requested by the claim must be available from the corresponding Persistent Volume and storage backend.

What’s next?