PersistentVolume (PV for short) and PersistentVolumeClaim (PVC for short)
PersistentVolume (Persistent Volume, PV for short) is a part of the network storage provided by the administrator in the cluster. Just like nodes in a cluster, PVs are also a resource in a cluster. It is also a volume plugin like Volume, but its life cycle is independent of the Pod that uses it. PV is an API object that captures implementation details such as NFS, ISCSI, or other cloud storage systems.
PersistentVolumeClaim (Persistent Volume Claim, PVC for short) is a storage request from the user. It is similar to Pod, Pod consumes Node resources, while PVC consumes PV resources. Pods can request specific resources (such as CPU and memory). A PVC can request a specified size and access mode (which can be mapped as read-write once or read-only multiple times).
PVCs allow users to consume abstracted storage resources, and users also often need PVs with various properties such as performance. Cluster administrators need to provide PVs of various sizes and access patterns without exposing users to the details of how these volumes are implemented. Because of this demand, a StorageClass resource was born.
StorageClass provides a way for an administrator to describe the class of storage he offers. Cluster administrators can map different levels to different service levels, different backend policies.
Supplying
PVs are the resources in the cluster, and PVCs are requests for and "extraction certificates" for these resources. The interaction of PV and PVC follows the following lifecycle:
There are two ways PV is provided: static and dynamic.
Static
Cluster administrators create multiple PVs that carry details of the real storage that is available to cluster users. They exist in the Kubernetes API and are available for storage usage.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv01
namespace: sit
spec:
capacity:
storage: 100Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
nfs:
server: 10.42.0.55
path: "/opt/public"
dynamic
when admin created static When none of the PVs match the user's PVCs, the cluster may try to provision volumes exclusively to the PVCs. This provisioning is based on StorageClass: the PVC must request such a class, and the administrator must have created and configured such a class in case this dynamic provisioning occurs. A PVC with a request class configured as "" effectively disables its own dynamic provisioning capabilities.
Kubernetes 1.4 has added a new API object StorageClass, which can define multiple StorageClass objects, and can specify storage plugins and set parameters to provide different storage volumes. This design enables cluster administrators to define and provision volumes of different types and parameters (same or different storage systems) within the same cluster. This design also ensures that end users have the ability to choose different storage options without having to know too much.
This scenario is more common in the case of advanced private cloud distributed storage or public cloud storage, most of which are integrated with third parties.
Example: create a slow, another fast disk on Google Cloud
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: slow
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd
Binding
The user creates a PVC (or has previously been created for dynamic provisioning) specifying the required storage size and access mode. There is a control loop in the master that monitors new PVCs, looks for matching PVs (if any), and binds PVCs and PVs together. If a PV has been dynamically supplied to a new PVC, the loop will always bind the PV and PVC. Additionally, users always get at least as much storage as they ask for, but volumes may exceed their requests. Once bound, PVC bindings are proprietary, regardless of their binding mode.
If no matching PV is found, the PVC will remain in the unbound state indefinitely, and once the PV is available, the PVC will become bound again. For example, if a PV cluster supplies many 50G, it will not match a PVC requiring 100G. The PVCs will not be bound until 100G of PVs are added to the cluster.
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-test01
namespace:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
Using a
Pod using PVC is like using a volume. The cluster checks the PVCs, looks for bound PVs, and maps PVs to Pods. For PVs that support multiple access modes, the user can specify the desired mode.
Once a user owns a PVC, and the PVC is bound, the PV remains with the user as long as the user needs it. Users schedule Pods to access PVs by including PVCs in the Pod's volume block.
kind: Pod
apiVersion: v1
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: pvc-test01
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
Release
When the user finishes using the PV, they can delete the PVC object through the API. When a PVC is deleted, the corresponding PV is considered to be "released", but cannot be used by another PVC. The belonging of the previous PVC still exists in this PV and must be disposed of according to the policy.
The reclamation policy for reclaiming
a PV tells the cluster what the cluster should do with the PV after it has been released. Currently, PVs can be Retained, Recycled, or Deleted. Reservation allows the resource to be reclaimed manually. For PV volumes that support delete operations, the delete operation removes the PV object from Kubernetes, as well as the corresponding external storage (such as AWS EBS, GCE PD, Azure Disk, or Cinder volume). Dynamically provisioned volumes are always deleted.
refer to:
https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/