云原生之K8S------K8S持久化存储PV、PVC

目录

一，PV和PVC

1，PV概念

2，PVC概念

3，PV与PVC之间的关系

3.1 PV和PVC的生命周期

3.2 一个PVC从创建到销毁的具体流程

3.3 三种回收策略

3.4 查看PV pvc的定义方式，规格

4，两种PV的提供方式

二，基于NFS创建静态PV资源和PVC资源

1，实验环境

2,所有节点安装NFS

3，在master节点创建共享目录

4，master授权共享目录

5，master编辑exports文件

6,master启动rpc和nfs

 7，master创建pv

 8，定义PVC

9,进行测试

 三，搭建storageclass+NFS 实现NFS的动态PV创建

 2，使用deployment来创建NFS Provisioner

 3，创建NFS存储管理器（provisioner）

 4，创建storageclass，复制建立pvc并调用NFS provisioner 进行预订的工作，并让pv与pvc建立关联。

 5，创建PVC和POD测试

---

一，PV和PVC

1，PV概念

1. persistentVoiume（PV）是集群中由管理员配置的一段网络存储，集群中的资源就像一个节点是一个集群资源，可以从远程的NFS或分布式对象存储系统中创建得来（PV储存空间大小，访问方式）。
2. PV是诸如卷之类的卷插件，但是只有独立于使用PV的任何单个pod的生命周期。
3. 该API对象捕获存储的实现细节，即NFS、ISCSI 或云提供商特定的存储系统
4. PV就是从存储设备中的空间创建出一个存储资源

2，PVC概念

1.  PersistentVolumeClaim(PVC) 是用户存储的请求，PVC的使用逻辑：在pod中定义一个存储卷（该存储卷类型为PVC），定义的时候直接按指定大小，PVC必须与对应的PV建立关系，PVC会根据定义去PV申请，而PV是由存储空间创建出来的，PV和PVC是kubernetes抽象出来的一种存储资源
2. 虽然PersistentVolumeClaim允许用户使用抽象存储资源，但是场景的需求是，用户需要根据不同的需求去创建PV,用于不同的场景，而此时需要集群管理员提供不同需求的PV，而不仅仅是PV的大小和访问模式，但又不需要用户了解这些卷的实现细节。
3. 对应这样的需求，此时可以采用storageclass资源。

3，PV与PVC之间的关系

PV是集群中的资源，PVC是这些资源的请求，也是对资源的索引检查。

3.1 PV和PVC的生命周期

PV和PVC之间的相互作用遵循以下生命周期：

Provisioning(配置) ---> Binding(绑定) ---> Using(使用) ---> Releasing(释放) ---> Recycling(回收)

• Provisioning：即PV的创建，可以直接创建PV（静态方式）也可以使用storageclass动态创建
• binding：将PV分配给PVC
• Using：Pod通过PVC使用该volume，并可以通过准入控制storageprotection，阻止删除正在使用的PVC。
• Releasing：POD释放volume并删除PVC
• Recycling：回收PV,可以保留PV以便下次使用，也可以直接从云存储中删除。

根据这五个阶段，pv的状态有以下4种：

Avaliable（可用）：表示可以状态。还未被任何PVC绑定

Bound（已绑定）：表示PV已经被绑定到PVC

Released（已释放）：表示PVC被删掉，但是资源尚未被集群回收

Failes（失败）：表示该PV的自动回收失败

3.2 一个PVC从创建到销毁的具体流程

1. 一个PV创建完后状态会变成available，等待被pvc绑定
2. 一旦被PVC绑定，PV的状态会变成Bound，就可以被定义了相应PVC的pod使用。
3. Pod使用完成后会释放PV,PV的状态变成Released。
4. 变成Released的PV会根据定义的回收策略做相应的回收工具。

3.3 三种回收策略

有三种回收策略，Retain，Delete和Recycle。

Retain就是保留现场，K8S集群什么也不做，等待用户收到去处理PV里的1数据，处理完成后，再手动删除PV。

Delete策略：K8S会自动删除该PV及里面的数据。

Recycle方式：K8S会将PV里的数据删除，然后把PV的状态变成Available，又可以被新的pvc绑定使用。

3.4 查看PV pvc的定义方式，规格

查看PV的定义方式

kubectl explain pv

FIELDS:
	apiVersion: v1
	kind: PersistentVolume
	metadata:    #由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespace
	  name: 
	spec

查看PV定义的规格

kubectl explain pv.spec

spec:
  nfs:（定义存储类型）
    path:（定义挂载卷路径）
    server:（定义服务器名称）
  accessModes:（定义访问模型，有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访问模式）
    - ReadWriteOnce          #（RWO）存储可读可写，但只支持被单个 Pod 挂载
	- ReadOnlyMany           #（ROX）存储可以以只读的方式被多个 Pod 挂载
	- ReadWriteMany          #（RWX）存储可以以读写的方式被多个 Pod 共享
#nfs 支持全部三种；iSCSI 不支持 ReadWriteMany（iSCSI 就是在 IP 网络上运行 SCSI 协议的一种网络存储技术）；HostPath 不支持 ReadOnlyMany 和 ReadWriteMany。
  capacity:（定义存储能力，一般用于设置存储空间）
    storage: 2Gi （指定大小）
  storageClassName: （自定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）
  persistentVolumeReclaimPolicy: Retain    #回收策略（Retain/Delete/Recycle）
#Retain（保留）：当删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。
#Delete（删除）：删除与PV相连的后端存储资源（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
#Recycle（回收）：删除数据，效果相当于执行了 rm -rf /thevolume/* （只有 NFS 和 HostPath 支持）

查看PVC的定义方式

kubectl explain pvc

KIND:     PersistentVolumeClaim
VERSION:  v1
FIELDS:
   apiVersion	
   kind	  
   metadata