mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
109 lines
4.3 KiB
Plaintext
109 lines
4.3 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * storage/understanding-persistent-storage.adoc
|
|
|
|
[id=lifecycle-volume-claim_{context}]
|
|
= Lifecycle of a volume and claim
|
|
|
|
PVs are resources in the cluster. PVCs are requests for those resources
|
|
and also act as claim checks to the resource. The interaction between PVs
|
|
and PVCs have the following lifecycle.
|
|
|
|
[id="provisioning_{context}"]
|
|
== Provision storage
|
|
|
|
In response to requests from a developer defined in a PVC, a cluster
|
|
administrator configures one or more dynamic provisioners that provision
|
|
storage and a matching PV.
|
|
|
|
ifdef::openshift-enterprise,openshift-origin[]
|
|
Alternatively, a cluster administrator can create a number of PVs in advance
|
|
that carry the details of the real storage that is available for use. PVs
|
|
exist in the API and are available for use.
|
|
endif::[]
|
|
|
|
[id="binding_{context}"]
|
|
== Bind claims
|
|
|
|
When you create a PVC, you request a specific amount of storage, specify the
|
|
required access mode, and create a storage class to describe and classify
|
|
the storage. The control loop in the master watches for new PVCs and binds
|
|
the new PVC to an appropriate PV. If an appropriate PV does not exist, a
|
|
provisioner for the storage class creates one.
|
|
|
|
The size of all PVs might exceed your PVC size. This is especially true
|
|
with manually provisioned PVs. To minimize the excess, {product-title}
|
|
binds to the smallest PV that matches all other criteria.
|
|
|
|
Claims remain unbound indefinitely if a matching volume does not exist or
|
|
can not be created with any available provisioner servicing a storage
|
|
class. Claims are bound as matching volumes become available. For example,
|
|
a cluster with many manually provisioned 50Gi volumes would not match a
|
|
PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the
|
|
cluster.
|
|
|
|
[id="using-pods_{context}"]
|
|
== Use Pods and claimed PVs
|
|
|
|
Pods use claims as volumes. The cluster inspects the claim to find the bound
|
|
volume and mounts that volume for a Pod. For those volumes that support
|
|
multiple access modes, you must specify which mode applies when you use
|
|
the claim as a volume in a Pod.
|
|
|
|
Once you have a claim and that claim is bound, the bound PV belongs to you
|
|
for as long as you need it. You can schedule Pods and access claimed
|
|
PVs by including `persistentVolumeClaim` in the Pod's volumes block.
|
|
|
|
ifdef::openshift-origin,openshift-enterprise[]
|
|
|
|
[id="pvcprotection_{context}"]
|
|
== Storage Object in Use Protection
|
|
|
|
The Storage Object in Use Protection feature ensures that PVCs in active use by a Pod and PVs that are bound to PVCs are not removed from the system, as this can result in data loss.
|
|
|
|
Storage Object in Use Protection is enabled by default.
|
|
|
|
[NOTE]
|
|
====
|
|
A PVC is in active use by a Pod when a Pod object exists that uses the PVC.
|
|
====
|
|
|
|
If a user deletes a PVC that is in active use by a Pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any Pods. Also, if a cluster admin deletes a PV that is bound to a PVC, the PV is not removed immediately. PV removal is postponed until the PV is no longer bound to a PVC.
|
|
|
|
endif::openshift-origin,openshift-enterprise[]
|
|
|
|
[id="releasing_{context}"]
|
|
== Release volumes
|
|
|
|
When you are finished with a volume, you can delete the PVC object from
|
|
the API, which allows reclamation of the resource. The volume is
|
|
considered released when the claim is deleted, but it is not yet available
|
|
for another claim. The previous claimant's data remains on the volume and
|
|
must be handled according to policy.
|
|
|
|
[id="reclaiming_{context}"]
|
|
== Reclaim volumes
|
|
|
|
The reclaim policy of a `PersistentVolume` tells the cluster what to do with the volume after it is released. Volumes reclaim policy can either be
|
|
`Retain`, `Recycle`, or `Delete`.
|
|
|
|
* `Retain` reclaim policy allows manual reclamation of the resource for
|
|
those volume plug-ins that support it.
|
|
* `Recycle` reclaim policy recycles the volume back into the pool of
|
|
unbound persistent volumes once it is released from its claim.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
The `Recycle` reclaim policy is deprecated in {product-title} 4. Dynamic provisioning is recommended for equivalent and better
|
|
functionality.
|
|
====
|
|
|
|
* `Delete` reclaim policy deletes both the `PersistentVolume` object
|
|
from {product-title} and the associated storage asset in external
|
|
infrastructure, such as AWS EBS or VMware vSphere.
|
|
|
|
[NOTE]
|
|
====
|
|
Dynamically provisioned volumes are always deleted.
|
|
====
|