概述

PersistentVolume子系统提供了用户和管理员使用和管理存储的抽象API。在这个子系统中,引进了两个新的API资源:PersistentVolume和PersistentVolumeClaim。

**PersistentVolume(PV)**是已经由管理员提供或者使用Storage类动态地从k8s Volume中配备的一块存储器。PV是Volume的插件,它有自己独立的生命周期,不受使用PV的Pod的生命周期影响。这个API对象描述了存储的实现细节,例如NFS、iSCSI或云提供商特定的存储系统。

**PersistentVolumeClaim(PVC)**是由用户申请存储的请求。 它和Pod类似:Pod消耗节点资源而PVC消耗PV资源;Pod可以配置请求资源的限制(CPU和存储器)而PVC可以配置存储特定的大小和访问模式(例如,挂载一次读/写或多次只读的存储)。

**StorageClass(存储类)**PVC允许用户消耗抽象存储资源,且一般带有存储参数需求:例如性能、访问模式等,且不希望暴露这些卷底层实现的细节。针对这些需,k8s提供了StorageClass资源来实现。

PV和PVC的生命周期

PV和PVC都遵循如下生命周期:

Provisioning–>Binding–>Using–>Releasing–>Recycling

存储供应

PV有二种类型:静态PV和动态PV。

静态PV

可供k8s集群用户使用的真实存储实现的PV,他们存在于Kubernetes API中,且可直接被消费。

动态PV

当管理员没有为匹配的用户PVC而创建的静态PV时,可以尝试动态地为PVC提供volume卷。此配置是基于StorageClasses:必须先配置和创建好StorageClasses,然后在PVC请求此存储类。要使用StorageClasses,请确保在API服务器上启用DefaultStorageClass控制器。可通过对apiserver的启动参数–enable-admission-plugins添加DefaultStorageClass生效。

Binding

在动态配置的情况下,用户创建或已经创建了具有特定数量的存储请求和特定访问模式的PersistentVolumeClaim。 主机中的控制回路监视新的PVC,找到匹配的PV(如果可能),并将它们绑定在一起。 如果为新的PVC动态配置PV,则循环将始终将该PV绑定到PVC。 否则,用户总是至少得到他们要求的内容,但是卷可能超出了要求。 一旦绑定,PersistentVolumeClaim绑定是排他的,不管用于绑定它们的模式。

如果匹配的卷不存在,PVC将保持无限期。 随着匹配卷变得可用,PVC将被绑定。 例如,提供许多50Gi PV的集群将不匹配要求100Gi的PVC。 当集群中添加100Gi PV时,可以绑定PVC。

Using

Pod使用PVC作为卷。 集群检查声明以找到绑定的卷并挂载该卷的卷。 对于支持多种访问模式的卷,用户在将其声明用作pod中的卷时指定所需的模式。

一旦用户有声明并且该声明被绑定,绑定的PV属于用户,只要他们需要它。 用户通过在其Pod的卷块中包含persistentVolumeClaim来安排Pods并访问其声明的PV。

Releasing

当用户完成卷时,他们可以从允许资源回收的API中删除PVC对象。 当声明被删除时,卷被认为是“释放的”,但是它还不能用于另一个声明。 以前的索赔人的数据仍然保留在必须根据政策处理的卷上.

Reclaiming

PersistentVolume的回收策略告诉集群在释放其声明后,该卷应该如何处理。 目前,卷可以是保留,回收或删除。 保留可以手动回收资源。 对于那些支持它的卷插件,删除将从Kubernetes中删除PersistentVolume对象,以及删除外部基础架构(如AWS EBS,GCE PD,Azure Disk或Cinder卷)中关联的存储资产。 动态配置的卷始终被删除

Recycling

如果受适当的卷插件支持,回收将对卷执行基本的擦除(rm -rf / thevolume / *),并使其再次可用于新的声明。
但是,管理员可以使用Kubernetes控制器管理器命令行参数来配置自定义的回收站pod模板,如这里所述。 定制回收站模板必须包含卷规范,