Shulou(Shulou.com)06/01 Report--

Kubernetes PV/PVC/StroageClass persistent storage is how, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

PersistentVolume (PV) and PersistentVolumeClaim (PVC)

PersistentVolume (persistent Volume, or PV for short) is part of the network storage provided by the administrator in the cluster. Like nodes in a cluster, PV is a resource in a cluster. Like Volume, it is a volume plug-in, but its life cycle is independent of the Pod that uses it. PV, an API object, captures the implementation details of cloud storage systems such as NFS, ISCSI, or other cloud storage systems.

PersistentVolumeClaim (persistent volume declaration, or PVC for short) is a storage request made by the user. It is similar to Pod, where Pod consumes Node resources and PVC consumes PV resources. Pod can request specific resources (such as CPU and memory). PVC can request a specified size and access mode (which can be mapped to read-write or multiple read-only).

PVC allows users to consume abstract storage resources, and users often need PV for various attributes, such as performance. Cluster administrators need to provide a variety of PV with different sizes and access modes without exposing the details of how these volume are implemented to users. Because of this demand, a kind of StorageClass resource is born.

StorageClass provides a way for an administrator to describe the level of storage he provides. Cluster administrators can map different levels to different service levels and different back-end policies.

Supply

PV is the resource in the cluster, and PVC is the request for these resources, and it is also the "extraction certificate" of these resources. The interaction between PV and PVC follows the following lifecycle:

There are two ways that PV provides: static and dynamic.

Static state

The cluster administrator creates multiple PV that carry details of the real storage that is available to cluster users. They exist in Kubernetes API and can be used for storage.

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 none of the static PV created by the administrator matches the user's PVC, the cluster may try to specifically feed the volume to the PVC. This provisioning is based on the fact that StorageClass:PVC must request such a level, and the administrator must have created and configured such a level in case this dynamic provisioning occurs. PVC, with a request level of "", effectively disables its own dynamic provisioning function.

A new API object StorageClass is added in Kubernetes 1.4, which can define multiple StorageClass objects, specify storage plug-ins and set parameters to provide different storage volumes. This design allows cluster administrators to define and provide different types of volumes with different parameters (the 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 knowing much.

This kind of 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 and 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 master that monitors the new PVC, finds a matching PV, if any, and binds the PVC to the PV. If a PV has been dynamically fed to a new PVC, the loop will always bind the PV to the PVC. In addition, users always get at least the storage they require, but the volume may exceed their requests. Once bound, PVC bindings are exclusive, regardless of their binding mode.

If no matching PV is found, the PVC will be left in the unbound unbound state indefinitely, and once the PV is available, the PVC will become bound again. For example, if a PV cluster provides a lot of 50G, it will not match the PVC that requires 100G. The PVC will not be bound until 100G PV is added to the cluster.

Kind: PersistentVolumeClaim

ApiVersion: v1

Metadata:

Name: pvc-test01

Namespace:

Spec:

AccessModes:

-ReadWriteOnce

Resources:

Requests:

Storage: 100Gi

Use

Pod uses PVC just like volume. The cluster checks the PVC, looks for the bound PV, and maps PV to Pod. For PV that supports multiple access modes, users can specify which mode they want to use.

Once the user has a PVC and the PVC is bound, the PV always belongs to that user as long as the user needs it. The user schedules Pod and accesses PV by including PVC in the volume block of Pod.

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 users have finished using PV, they can delete the PVC object through API. When the PVC is deleted, the corresponding PV is considered to be "released", but it cannot be used by another PVC. The ownership of the previous PVC still exists in the PV and must be disposed of according to policy.

Recovery

PV's recycling strategy tells the cluster what the cluster should do with the PV after it has been released. Currently, PV can be Retained (reserved), Recycled (reuse), or Deleted (deleted). Reservation allows resources to be manually re-declared. For PV volumes that support the delete operation, the delete operation removes the PV object from the 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.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.