Kubernetes详解（三十七）——PV与PVC

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

一、PV和PVC详解

当前，存储的方式和种类有很多，并且各种存储的参数也需要非常专业的技术人员才能够了解。在Kubernetes集群中，放了方便我们的使用和管理，Kubernetes提出了PV和PVC的概念，这样Kubernetes集群的管理人员就可以将注意力集中到Kubernetes集群中来，而无需操心后端的存储设备了。
Kubernetes集群存储架构如下所示：

从上图可以看出，底层的存储可以使各种类型，包括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