refer
refer2
claim process
(°0°)
1) A user creates a pod that contains a PVC, which uses a dynamic PV.
2) Scheduler schedules the pod to an appropriate worker node based on the pod configuration, node status, and PV configuration.
3) PV Controller watches that the pod-used PVC is in the Pending state and calls Volume Plugin (in-tree) to create a PV and PV object. The out-of-tree process is implemented by External Provisioner.
4) AD Controller detects that the pod and PVC are in the ‘To Be Attached’ state and calls Volume Plugin to attach the storage device to the target worker node.
5) On the worker node, Volume Manager in the kubelet waits until the storage device is attached and uses Volume Plugin to mount the device to the global directory /var/lib/kubelet/pods/[pod uid]/volumes/kubernetes.io~iscsi/[PV
name] (iscsi is used as an example).
6) The kubelet uses Docker to start the containers in the pod and uses the bind mount method to map the volume that is mounted to the local-global directory to the containers.
lifecycle
PersistentVolumes and PersistentVolumeClaims Lifecycle
The communication between PVs and PVCs consists of the following stages:
Provisioning: This is the process of creating a storage volume, which can be done statically or dynamically.
Static: The static way of provisioning a storage volume is when PVs are created before PVCs by an Administrator and exist in the Kubernetes API, waiting to be claimed by a user’s storage request, using PVC.
Dynamic: The dynamic way of storage provisioning involves creating PVs automatically, using StorageClass instead of manual provisioning of PersistentVolumes. Kubernetes will dynamically provision a volume specifically for this storage request, with the help of a StorageClass. (More about StorageClass and how it is used to provision PVs dynamically in the next part of this series).
Binding: When an Administrator has provisioned PVs and users make a specific amount of storage requests (PVCs), a control loop in the master finds a matching PV and binds them together. If a matching volume does not exist, the claim will remain unbound until a volume match is created.
Using: Pods use claims as volumes. The Kubernetes API checks the claim to find a bound PV and mounts it in the Pod for the users. When a claim is already bound to a PV, the bind remains unchanged as long as the user wants it. So user A’s bound PV can not be taken over by user B, if it is still in use by user A.
Reclaiming: When a user is done with the volume usage, the resources must be freed up by deleting the PVC objects from Kubernetes. This practice will free the PV from the PVC, allowing reclamation of the resources, making it available for future use. What happens to the volumes afterwards is determined by the PersistentVolumeReclaimPolicy (PVRP) value specified in the configuration file. The PVRP provides three options of what you can do to a PersistentVolume after the claim has been deleted: retain, delete, or recycle.
Retain: This is the default reclaim policy. It is a process that allows manual deletion of the PV by the Administrator. When a PVC is deleted, the PV remains intact, including its data, thus making it unavailable for use by another claim. However, the Administrator can still manually reclaim the PersistentVolume.
Delete: When the reclaim policy is set to delete, the PV deletes automatically when the PVC is deleted and makes the space available. It is important to note that the dynamically provisioned PVs inherit the reclaim policy of their StorageClass, which defaults to Delete.
Recycle: This type of reclaim policy will scrub the data in the PV and make it available for another claim.
pv, pvc, sc
(°0°)
- PersistentVolumes States
A PV has different states, can be in any of these, and each has its own meaning, described as follows:Available: The PV is free and not yet claimed or bounded. Bound: The PV has been claimed or bounded. Released: The bounded PVC has been deleted, and the PV is free from its previous bounded state. Failed: The PV has failed its automatic reclamation. - PersistentVolumeClaims States
Each PVC, like the PV, has its own states that represent its current status.Bound: The PVC is bound to a PV. Pending: The PVC can not bind to a PV. This could be due to a higher storage request than the PV capacity, or the PV accessMode value is different from that of the PVC, etc.
pv accessmode
- ReadWriteOnce: You can mount the PV as read-write by a single node.
- ReadOnlyMany: You can mount the PV as read-only by multiple nodes.
- ReadWriteMany: You can mount the PV as read-write by multiple nodes.
delete a pvc
When a persistent volume claim (PVC) is deleted, the persistent volume (PV) still exists and is considered “released”. However, the PV is not yet available for another claim because the data of the previous claimant remains on the volume. To manually reclaim the PV as a cluster administrator: Delete the PV.
static pv vs dynamic pv
(°0°)
commands
kubectl get volumeattachment
kubectl get pvc
kubectl describe pv <> # find volume ID from 'VolumeHandle' tag
kubectl patch pvc data00-# -p '{"metadata":{"finalizers":null}}'