Kubernetes详解(三十七)——PV与PVC

今天继续给大家介绍Linux运维相关知识,本文主要内容是Kubernetes PV与PVC。

一、PV和PVC详解

当前,存储的方式和种类有很多,并且各种存储的参数也需要非常专业的技术人员才能够了解。在Kubernetes集群中,放了方便我们的使用和管理,Kubernetes提出了PV和PVC的概念,这样Kubernetes集群的管理人员就可以将注意力集中到Kubernetes集群中来,而无需操心后端的存储设备了。
Kubernetes集群存储架构如下所示:
Kubernetes详解(三十七)——PV与PVC_第1张图片
从上图可以看出,底层的存储可以使各种类型,包括NFS、Ceph、iSCSI等等,而Kubernetes会把这些存储统一抽象为PV。PV,即Persistent Volume,是集群中配置的存储资源。PVC,即Persistent Volume Claim,是用户存储的请求,通常我们在一个Pod中定义一个存储卷,定义的时候会指定该存储卷的相关信息,比如空间大小、可读可写等属性。但是PVC并不是真正的存储空间,Pod的PVC和PV之间必须建立某种联系,这样才能使得Pod可以调用实际存储空间。

二、PV和PVC生命周期

实际上,不管是PV,还是PVC,都遵循以下生命周期:
1、Provisioning
Provisioning,即配置阶段。一般而言,PV的提供方式有两种——静态和动态
所谓静态提供,就是Kubernetes管理员创建多个PV,这些PV的存储空间等属性已经确定,并且已经和真实的存储设备进行了关联。Pod中的PVC可以根据需要请求这些PV。
所谓动态提供,需要依托与StorageClass的支持,这时Kubernetes会尝试为PVC来动态的创建PV。这样做的好处是避免出现这种情况:部分PVC被分配给了远远超出其资源需求的PV、或者说系统存在很多资源较少的PV,但是一个资源需求很高的PVC缺无法被满足的情况。
2、Binding
在动态配置的情况下,用户创建或者已经创建了具有特定数量的PVC后,PVC与PV绑定的过程。
如果没有满足PVC请求需求的PV,那么PVC将无法被创建,因此造成的结果就是相应的Pod也不会被创建。
3、Using
即PVC与PC绑定后,Pod对存储空间的使用过程。
4、Releasing
当Pod被删除或者对该PV的资源使用结束后,Kubernetes就会删除该PVC对象,相应的也会回收PV资源,这时的PV就会处于这种状态。但是此时的PV还需要处理完毕之前的Pod在该存储卷上存储信息后才能够被使用。
5、Reclaiming
PV的回收策略对被释放的PV的处理过程。
6、Recycling
根据配置,有时PV会被执行擦除操作,删除掉该存储空间上的所有信息,并且该存储资源也可以被再次使用。
原创不易,转载请说明出处:https://blog.csdn.net/weixin_40228200

你可能感兴趣的:(虚拟化运维,PV,PVC,存储,Kubernetes,K8S)