kubernetes-存储-pv

概念:

ＰersistentVolume(PV)
是由管理员设置的存储,他是集群中的一部分.就像节点是集群中的资源一样,PV也是集群中资源.PV是Volume之类的卷插件,但具有独立使用的Pod的生命周期.此API对象包含存储实现的细节,即NFS、ISCSI或特定于云供应商的存储系统．

PersistentVolumeClaim(PVC)
使用户存储的请求．它与Pod相似．Pod消耗节点资源，PVC消耗PV资源．Pod可以请求特定级别的资源（CPU和内存）．声明可以请求特定的大小和访问模式（例如，可以读／写或只读多次模式挂载）

静态ＰV
集群管理员创建一些PV．它们带有可供集群用户使用的实际存储的细节．它们存在于Kubernetes API中，可用于消费．

动态
当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试动态地为PVC创建卷．此配置基于StorageClasses:PVC必须请求（存储类），并且管理员必须创建并配置该类才能进行动态创建．声明该类为＂＂可以有效的禁止七动态配置．
要启用基于存储级别的动态存储配置，集群管理员需要启用API server上的DefaultStorageClass[准入器].例如,通过确保DefaultStorageClass位于API Server组件的–admission-contol标志,使用都好跟个的有序值列表中,可以完成此操作.
(暂时不稳定,不友好,实现方案不成熟,是未来的趋势)

绑定
master中的控制环路监视新的PVC,寻找匹配的PV(如果可能),兵将他们绑定在一起.如果新的PVC动态调配PV,则该环路将始终将该PV绑定到PVC.否则,用户总会得到它们所请求的存储,但是容量可能超出要求的数量.一旦PV和PVC绑定后,PVC绑定时排他性的,不管它们是如何绑定的.PVC跟PV绑定是一对一的映射.

持久化卷声明的保护
PVC保护的目的是确保有Pod正在使用的PVC不会从系统中移除,因为如果被移除的话可能会导致数据丢失
注意: 当Pod状态为"pending"并且Pod已经分配给节点或Pod为"running"状态时,PVC的删除将会被推迟,直到PVC不在被任何Pod使用.

PV访问模式:

PersistentVolume可以易资源提供者支持的任何方式挂在到主机上.如下表所示,供应商具有不同的功能,每个PV的访问模式都将被设置为该卷支持的特定模式.例如,NFS可以支持多个读/写客户端,但特定的NFS PV可能以只读的方式导出到服务器上.每个PV都会有一套自己的用来描述特定功能的访问模式

• ReadWriteOnce–该卷可以被单个节点以读/写模式挂载
• ReadOnlyMany–该卷可以被多个节点以只读模式挂载
• ReadWriteMany–该卷可以被多个节点以读/写模式挂载

在命令行中,访问模式缩写为:

• RWO-ReadWriteOnce
• ROX-ReadOnlyMany
• RWX-ReadWriteMany
  注意: 一个卷只能使用一种模式挂载,即使它支持很多模式.

回收策略:

• Retain(保留)–手动回收
• Recyle(回收)–基本擦除(rm -rf /thevolume/*)(新版本已删除该功能)
• Delete(删除)–关联的存储资产(例如AWS EBS、GEC PD、Azure Disk 和 OpenStack Cinder
  卷)将被删除

当前,只有NFS和Hostpath支持回收策略.AWS EBS、GEC PD、Azure Disk 和Cinder卷支持删除策略.

状态

卷可以出于以下的某种状态:

• Available(可用)–一块空闲资源还没有被任何声明绑定
• Bound(已绑定)–卷已经被声明绑定
• Released(已释放)–声明被删除,但是自愿还未被集群重新声明
• failed(失败)–该卷的自动回收失败
  命令行会显示绑定到PVde PVC的名称