2.3. Persistent volumes
Each PV contains a spec and status, which is the specification and status of the volume, for example:
PersistentVolume object definition example
apiVersion: v1 kind: PersistentVolume metadata: name: pv0001 1 spec: capacity: storage: 5Gi 2 accessModes: - ReadWriteOnce 3 persistentVolumeReclaimPolicy: Retain 4 ... status: ...
2.3.1. Types of PVs
OpenShift Container Platform supports the following persistent volume plug-ins:
- AWS Elastic Block Store (EBS)
- Azure Disk
- Azure File
- Cinder
- Fibre Channel
- GCE Persistent Disk
- HostPath
- iSCSI
- Local volume
- NFS
- OpenStack Manila
- Red Hat OpenShift Container Storage
- VMware vSphere
2.3.2. Capacity
Generally, a persistent volume (PV) has a specific storage capacity. This is set by using the capacity attribute of the PV.
Currently, storage capacity is the only resource that can be set or requested. Future attributes may include IOPS, throughput, and so on.
2.3.3. Access modes
A persistent volume can be mounted on a host in any way supported by the resource provider. Providers have different capabilities and each PV’s access modes are set to the specific modes supported by that particular volume. For example, NFS can support multiple read-write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV’s capabilities.
Claims are matched to volumes with similar access modes. The only two matching criteria are access modes and size. A claim’s access modes represent a request. Therefore, you might be granted more, but never less. For example, if a claim requests RWO, but the only volume available is an NFS PV (RWO+ROX+RWX), the claim would then match NFS because it supports RWO.
Direct matches are always attempted first. The volume’s modes must match or contain more modes than you requested. The size must be greater than or equal to what is expected. If two types of volumes, such as NFS and iSCSI, have the same set of access modes, either of them can match a claim with those modes. There is no ordering between types of volumes and no way to choose one type over another.
All volumes with the same modes are grouped, and then sorted by size, smallest to largest. The binder gets the group with matching modes and iterates over each, in size order, until one size matches.
The following table lists the access modes:
| Access Mode | CLI abbreviation | Description |
|---|---|---|
| ReadWriteOnce |
| The volume can be mounted as read-write by a single node. |
| ReadOnlyMany |
| The volume can be mounted as read-only by many nodes. |
| ReadWriteMany |
| The volume can be mounted as read-write by many nodes. |
Volume access modes are descriptors of volume capabilities. They are not enforced constraints. The storage provider is responsible for runtime errors resulting from invalid use of the resource.
For example, NFS offers ReadWriteOnce access mode. You must mark the claims as read-only if you want to use the volume’s ROX capability. Errors in the provider show up at runtime as mount errors.
iSCSI and Fibre Channel volumes do not currently have any fencing mechanisms. You must ensure the volumes are only used by one node at a time. In certain situations, such as draining a node, the volumes can be used simultaneously by two nodes. Before draining the node, first ensure the pods that use these volumes are deleted.
| Volume plug-in | ReadWriteOnce [1] | ReadOnlyMany | ReadWriteMany |
|---|---|---|---|
| AWS EBS [2] |
✅ |
- |
- |
| Azure File |
✅ |
✅ |
✅ |
| Azure Disk |
✅ |
- |
- |
| Cinder |
✅ |
- |
- |
| Fibre Channel |
✅ |
✅ |
- |
| GCE Persistent Disk |
✅ |
- |
- |
| HostPath |
✅ |
- |
- |
| iSCSI |
✅ |
✅ |
- |
| Local volume |
✅ |
- |
- |
| NFS |
✅ |
✅ |
✅ |
| OpenStack Manila |
- |
- |
✅ |
| Red Hat OpenShift Container Storage |
✅ |
- |
✅ |
| VMware vSphere |
✅ |
- |
- |
- ReadWriteOnce (RWO) volumes cannot be mounted on multiple nodes. If a node fails, the system does not allow the attached RWO volume to be mounted on a new node because it is already assigned to the failed node. If you encounter a multi-attach error message as a result, force delete the pod on a shutdown or crashed node to avoid data loss in critical workloads, such as when dynamic persistent volumes are attached.
- Use a recreate deployment strategy for pods that rely on AWS EBS.
2.3.4. Phase
Volumes can be found in one of the following phases:
| Phase | Description |
|---|---|
| Available | A free resource not yet bound to a claim. |
| Bound | The volume is bound to a claim. |
| Released | The claim was deleted, but the resource is not yet reclaimed by the cluster. |
| Failed | The volume has failed its automatic reclamation. |
You can view the name of the PVC bound to the PV by running:
$ oc get pv <pv-claim>
2.3.4.1. Mount options
You can specify mount options while mounting a PV by using the annotation volume.beta.kubernetes.io/mount-options.
For example:
Mount options example
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
annotations:
volume.beta.kubernetes.io/mount-options: rw,nfsvers=4,noexec 1
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
nfs:
path: /tmp
server: 172.17.0.2
persistentVolumeReclaimPolicy: Retain
claimRef:
name: claim1
namespace: default
- 1
- Specified mount options are used while mounting the PV to the disk.
The following PV types support mount options:
- AWS Elastic Block Store (EBS)
- Azure Disk
- Azure File
- Cinder
- GCE Persistent Disk
- iSCSI
- Local volume
- NFS
- Red Hat OpenShift Container Storage (Ceph RBD only)
- VMware vSphere
Fibre Channel and HostPath PVs do not support mount options.
