k8s中pv和pvc如何理解

持久化与有状态应用的误区

刚接触k8s的伙伴会有一个误区：有状态应用才使用pv,和pvc,或者有更深的误会
有状态应用，我们这次不表，后面的文章再继续分享
结论：无状态应用，同样需要持久化能力

k8s 带来的持久化问题和应用状态问题

应用状态问题，下次再说

正如大家知道的那样，k8s对pod采用了声明式的管理，对于pod生命周期的细节我们不用操心。这也与大家期望相符。
换句话说，pod可能在任意时刻出现或死在任何节点上，那pod所依赖的数据又该何去何从呢？

k8s采用pv和pvc 的办法巧妙的解决了这个问题

认识PV/PVC/StorageClass

**PersistentVolume（PV）：**是集群中由管理员配置的一段网络存储。 它是集群中的资源，就像节点是集群资源一样。 PV是容量插件，如Volumes，但其生命周期独立于使用PV的任何单个pod。 此API对象捕获存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。

**PersistentVolumeClaim（PVC）**是由用户进行存储的请求。 它类似于pod。 Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以一次读/写或多次只读）。

虽然PersistentVolumeClaims允许用户使用抽象存储资源，但是PersistentVolumes对于不同的问题，用户通常需要具有不同属性（例如性能）。群集管理员需要能够提供各种PersistentVolumes不同的方式，而不仅仅是大小和访问模式，而不会让用户了解这些卷的实现方式。对于这些需求，有StorageClass 资源。

StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 不同的类可能映射到服务质量级别，或备份策略，或者由群集管理员确定的任意策略。 Kubernetes本身对于什么类别代表是不言而喻的。 这个概念有时在其他存储系统中称为“配置文件”。
　　PV类型
GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
FC (Fibre Channel)
Flexvolume
Flocker
NFS
iSCSI
RBD (Ceph Block Device)
CephFS
Cinder (OpenStack block storage)
Glusterfs
VsphereVolume
Quobyte Volumes
HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
Portworx Volumes
ScaleIO Volumes
StorageOS

快速理解

StorageClass 把所有可以为集群所用的存储进行分类管理，至于如何分类，k8s并不关注，我们按照常规运维标准进行分类即可。比如：性能，容量，安全性等指标分类，即可。

PV可以理解为是对StrongClass的进一步细分，毕竟Storage的分类粒度过大，我们不可能把一个存储集群，直接分给某个pod使用，为了满足更为灵活的管理需求，比如权限，大小，读写方式，挂载路径等要求。
我们把集群的存储根据需要划分为很多个小的存储卷（pv）供pod 使用。

pvc 这样划分之后，又有新的问题出现了，集群中那么多的pod,那么多的pv ，到底谁是谁的pv,谁是谁的pod呢？
pvc 记录了pv的使用情况，以及被谁使用。

生命周期

PV是群集中的资源。PVC是对这些资源的请求，并且还充当对资源的检查。PV和PVC之间的相互作用遵循以下生命周期：

Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling

供应准备Provisioning—通过集群外的存储系统或者云平台来提供存储持久化支持。

• 静态提供Static：集群管理员创建多个PV。 它们携带可供集群用户使用的真实存储的详细信息。 它们存在于Kubernetes API中，可用于消费
• 动态提供Dynamic：当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试为PVC动态配置卷。 此配置基于StorageClasses：PVC必须请求一个类，并且管理员必须已创建并配置该类才能进行动态配置。 要求该类的声明有效地为自己禁用动态配置。
  绑定Binding—用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前，pvc会保持未绑定状态。
  使用Using—用户可在pod中像volume一样使用pvc。
  释放Releasing—用户删除pvc来回收存储资源，pv将变成“released”状态。由于还保留着之前的数据，这些数据需要根据不同的策略来处理，否则这些存储资源无法被其他pvc使用。
  回收Recycling—pv可以设置三种回收策略：保留（Retain），回收（Recycle）和删除（Delete）。
• 保留策略：允许人工处理保留的数据。
• 删除策略：将删除pv和外部关联的存储资源，需要插件支持。
• 回收策略：将执行清除操作，之后可以被新的pvc使用，需要插件支持。
  注：目前只有NFS和HostPath类型卷支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持删除(Delete)策略