PV和PVC

CSI容器存储接口

CSI以容器方式部署
CSI Plugin通过本地Socket与kubelet通信

关于CSI组件

• 有些存储类型可以不部署External Attacher
• Kubelet直接调用CSI Plugin实现数据卷的Mount/Unmount操作

Volume(存储卷)

K8s集群中的存储卷跟Docker的存储卷有些类似，只不过Docker的存储卷作用范围为一个容器，而K8s的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。 K8s支持非常多的存储卷类型，特别的，支持多种公有云平台的存储，包括AWS， Google和Azure云；支持多种分布式存储包括GlusterFS和Ceph；也支持较容易使用的主机本地目录hostPath和NFS。 K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储，使用这种存储，使得存储的使用者可以忽略后台的实际存储技术（例如AWS， Google或GlusterFS和Ceph），而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。

PV(持久存储卷)和PVC(持久存储卷声明)

pv是持久卷
pvc是持久卷消费
pv是全局的
pvc是绑定命名空间的
挂载中的pvc无法删除，除非占用该pvc的pod删除。

Persistent Volume， PV（持久存储卷）
Persistent Volume Claim， PVC（持久卷消费）：

PV和PVC使得K8s集群具备了存储的逻辑抽象能力，使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非常类似的； PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，由K8s集群的使用者即服务的管理员来配置。

PV可以理解成k8s集群找那个的某个网络存储对应的一块存储，与Volume很类似，但有以下区别：
① PV只能提供网络存储，不属于任何Node，但可以在每个Node上访问
② PV并不是定义在Pod之上的，而是独立于Pod之外定义。
③ PV目前只有几种类型： GCE Persistent Disks、 NFS、 RBD、 iSCSI、 AWS ElasticBlockStore、 GlusterFS

PV的accessModes属性有以下几类：

• ReadWriteOnce(RWO)：读写权限、且只能被单Node挂载,一般用块存储,例如云硬盘
• ReadOnlyMany(ROX)：只读权限，可被多Node挂载
• ReadWriteMany(RWX)：读写权限，可被多Node挂载

关于PV回收策略

• Retain(保留)模式：PVC删除后，PV依然存在,需手动清理
• Recycle(回收)模式：PVC删除后，PV数据被清空,PV可再次使用
• Delete(删除)模式：PVC删除后，PV同时被删除

PV的有如下几种状态：

• Avaliable(): 空闲状态,还未被PVC绑定
• Bound(已绑定): PV已经绑定到PVC上
• Release(已释放): PVC已被删除,但资源未被集群重新声明(数据未删除)
• Failed(失败): 表示该PV自动回收失败

关于pv、pvc绑定

可以通过Selector配置特定的PVC、PV绑定
PVC找不到匹配的PV时，才会触发Provisioner创建PV

PVC和PV Bound

A. Bound操作是由PersistentVolumeController来执行的
B. 处在Bound状态的PVC对象.spec.volumeName字段 == PV name
C. 处在Bound状态的PV对象.spec.ClaimRef 记录了bound的PVC对象的信息
D. unbound(删除pvc对象)的PV对象不可以直接被新的PVC对象bound

PV动态供给StorageClass

nfs的动态存储类创建的pvc不支持动态扩容缩容,不支持使用kubectl edit 编辑pvc容量

PV静态供给的缺点是维护成本高,生产环境中使用PV动态供给,使用StorageClass对象实现自动创建PV并关联PVC.