内容 : 记录k8s的持久化存储

为什么需要持久化存储：

1、使得使用资源的pod的生命周期与存储卷的生命周期分开
2、使得使用资源的pod在被重启后仍然能够使用之前的存储卷
3、使得使用资源的pod在被调度到其它节点后仍然能够使用之前的存储卷

持久化存储的相关概念：

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

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

StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 

经过API抽象，用户可以通过PVC使用存储资源，通常用户还会关心PV的很多属性，例如对不同的应用
场景需要不同的性能，仅仅提供存储大小和访问模式不能满足要求。集群管理员一方面要提供不同PV
的多种属性，一方面要隐藏底层的细节，就引入了StorageClass资源。管理员用存储级别
StorageClass描述存储的分类，不同的分类可以对应不同的质量服务Qos等级、备份策略和其他
自定义的策略。kubernetes本身不参与存储级别的划分，StorageClass概念在有的存储系统里
被称为”profiles”。

使用存储卷的过程：

用户提交请求创建Pod时,Kubernetes发现这个Pod声明使用了PVC,这时就需要
PersistentVolumeController帮它找一个PV来进行配对.如果有的话呢,就直接进行绑定.但是
如果没有呢?就去找对应的StorageClass,帮它新创建一个PV,然后再和PVC进行绑定.,此时新创建
的PV,只是一个API对象,还需要经过"两阶段"处理变成宿主机上的"持久化Volume"才算是真正有用.
这个时候,Pod就可以正常启动,并将相关文档挂载到容器内指定的路径.

使用存储卷过程的两阶段处理：

所谓"持久化Volume",指的就是这个宿主机上的目录,具备"持久性",也就是说:这个目录里面的内容,
既不会因为容器的删除而被清理掉,也不会和当前的宿主机进行绑定.这样,当容器被重启或者在其他
节点上重建出来之后,仍然能够通过挂载这个Volume来访问到目录里面的内容.

这里面主要有两个关键点:
一,不会因为容器的删除而清理掉里面的内容
二,不会和当前的宿主机进行绑定.从而使得目录具备"持久性".

Kubernetes在这个准备"持久化"宿主机目录的过程中,我们可以形象的称为"两阶段处理":

第一阶段:为虚拟机挂载磁盘,把这个阶段称为"Attach".
第二阶段:挂载磁盘之后,如果想要使用,还需要将挂载的磁盘进行格式化处理,并挂载到Volume
宿主机目录上,这个阶段称为"Mount",而这个挂载点,正是Volume的宿主机目录.

StoragyClass如何创建出pv：

StorageClass对象会定义下面两部分内容:
1,PV的属性.比如,存储类型,Volume的大小等.
2,创建这种PV需要用到的存储插件

有了这两个信息之后,Kubernetes就能够根据用户提交的PVC,找到一个对应的StorageClass,
之后Kubernetes就会调用该StorageClass声明的存储插件,进而创建出需要的PV.

PV与PVC,StoragyClass的关系：

PVC描述的是Pod想要使用的持久化存储的属性,比如存储的大小,读写权限等.
PV则是一个具体的Volume属性,比如Volume的类型,挂载目录等.
StorageClass的作用,则是充当PV的模板,从而可以动态创建需要的PV.

三者图解：

k8s mysql持久化数据没保存 k8s 持久化存储模式_持久化存储


持久化存储的种类：

Kubernetes通过插件支持下列存储：
GCEPersistentDisk
AWSElasticBlockStore
AzureFile
FC (Fibre Channel)
NFS
iSCSI
RBD (Ceph块设备)
CephFS
Cinder (openstack的快存储)
Glusterfs
VsphereVolume
HostPath (只能用于单节点)

持久化存储的访问方式：

存储有很多种，每种存储又有自己的特性，PV访问不同的存储会有不同的访问方式，
例如NFS支持多个rw的客户端，但具体到NFS PV可能会用只读方式export。
对不同PV的特性，每个PV有自己的访问方式。

访问方式包括：

ReadWriteOnce – 被单个节点mount为读写rw模式

ReadOnlyMany – 被多个节点mount为只读ro模式

ReadWriteMany – 被多个节点mount为读写rw模式


# 在同一时刻，一个卷只能使用一种访问方式mount

例如GCEPersistentDisk被可以一个节点mount为ReadWriteOnce也可以被多个节点mount为
ReadOnlyMany，但不能同时做。

回收策略：

pv可以设置三种回收策略：保留（Retain），回收（Recycle）和删除（Delete）

 - 保留策略：允许人工处理保留的数据。
 - 删除策略：将删除pv和外部关联的存储资源，需要插件支持。
 - 回收策略：将执行清除操作，之后可以被新的pvc使用，需要插件支持。

# 目前只有NFS和HostPath支持回收，AWS EBS, GCE PD和Cinder volumes只支持删除。

卷的状态：

卷有四种状态，一个卷必属于其中之一:

Available –闲置状态，没有被绑定到PVC
Bound – 绑定到PVC
Released – PVC被删掉，资源没有被在利用
Failed – 自动回收失败

卷的生命周期：

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使用。