[K8S系列七]存储-PV、PVC与Storage Class

本质上说，一个volume(卷)就是一个目录，从容器内部可以访问这个目录中的内容，而这个目录是怎么来的，它背后的媒介是什么以及它里面的内容，都是由volume的类型来决定的；而使用volume，只需要在pod上指定使用哪种类型的volume，以及mount到容器中的什么位置即可。K8S支持的存储类型如下所示，这里主要介绍HostPath和Persistent Volume。

hostPath 类型的volume是映射Pod所在的节点的文件或者目录到 pod 里。在使用 hostPath 类型的存储卷时，也可以设置 type 字段，支持的类型有文件、目录、File、Socket、CharDevice 和 BlockDevice。

根据附录1的volume-pod.yaml创建一个pod，使用hostPath类型的volume

部署后查看pods详情， 发现volume-pod位于w2节点，登录到w2 尝试在pods的容器中创建文件

因为hostPath类型的volume只映射pod所在的节点的文件或目录到pod中，如果pod因为重启被调度到其他节点时，将会看不到原来节点保存的数据，因此有了网络存储+pv+pvc的方式。

通过PersistentVolume(PV)与PersistentVolumeClaim(PVC)将提供存储与消费存储分离：

2.PVC由用户创建来消费存储，如同通过创建pod来消费cpu、mem资源。

PVC与PV是通过PersistentVolume Controller 进行绑定的。PV Controller 会不断地循环去查看每一个 PVC，是不是已经处于 Bound（已绑定）状态。如果不是，那它就会遍历所有的、可用的 PV，并尝试将其与未绑定的 PVC 进行绑定，这样，Kubernetes 就可以保证用户提交的每一个 PVC，只要有合适的 PV 出现，它就能够很快进入绑定状态。而所谓将PV 与 PVC 进行“绑定”，其实就是将这个 PV 对象的名字，填在了 PVC 对象的 spec.volumeName 字段上 。

这里以NFS+PV+PVC为例进行说明， NFS搭建过程请参考附录2，根据考附录3 nginx-pv-pvc.yaml ，创建nginx(deployment)、nginx-pv(pv)、nginx-pvc(pvc)。nginx-pv挂载在/nfs/data/nginx 下。在/nfs/data/nginx下创建文件1.html，pod中也可以访问，并且pod的重新创建不影响1.html。

上节说的PV和PVC方法虽然能实现屏蔽底层存储，但是PV创建比较复杂，通常都是由集群管理员管理，这非常不方便。

利用StorageClass实现，可以根据PVC需求，自动构建相对应的PV持久化存储卷，进一步简化运维管理成本。

StorageClass对象会定义下面两部分内容:

示例部分参考 nfs-subdir-external-provisioner 。 相关文件来源于 deploy ，需要略作修改。

1. Volumes

2.《kubernetes权威指南》

3. Kubernetes 存储设计

NFS(Network File System)网络文件系统，是FreeBSD支持的文件系统中的一种，允许网络中的计算机之间通过TCP/IP网络共享资源。

由于容器本身是非持久化的，因此需要解决在容器中运行应用程序遇到的一些问题。首先，当容器崩溃时，kubelet将重新启动容器，但是写入容器的文件将会丢失，容器将会以镜像的初始状态重新开始；第二，在通过一个Pod中一起运行的容器，通常需要共享容器之间一些文件。Kubernetes通过卷解决上述的两个问题。

在Docker有卷的概念卷，但Docker中存储卷只是磁盘的或另一个容器中的目录，并没有对其生命周期进行管理。Kubernetes的存储卷有自己的生命周期，它的生命周期与使用的它Pod生命周期一致。因此，相比于在Pod中运行的容器来说，存储卷的存在时间会比的其中的任何容器都长，并且在容器重新启动时会保留数据。当然，当Pod停止存在时，存储卷也将不再存在。在Kubernetes支持多种类型的卷，而Pod可以同时使用各种类型和任意数量的存储卷。在Pod中通过指定下面的字段来使用存储卷：

PV是系统管理员设置的存储，它是群集的一部分，是一种资源，所以它有独立于Pod的生命周期。

PVC是用户存储的请求。它与Pod相似，Pod消耗节点的CPU和内存资源，PVC则消耗PV资源，可以生命特定的容量大小和访问模式。

PV和PVC遵循如下的生命周期管理

PV有两种配置方式：静态或动态

要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的 DefaultStorageClass 准入控制器 。例如，通过确保 DefaultStorageClass 位于 API server 组件的 --admission-control 标志，使用逗号分隔的有序值列表中，可以完成此 *** 作。有关 API server 命令行标志的更多信息，请检查 kube-apiserver 文档。

一旦用户创建或已经创建了具有特定存储量的 PersistentVolumeClaim 以及某些访问模式。Kubernetes控制器会监视到新的 PVC，并寻找匹配的 PV，并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则控制器会始终将该 PV 绑定到 PVC。总之，用户总会得到他们所请求的存储，但是容量可能超出请求的数量。一旦 PV 和 PVC 绑定后，PersistentVolumeClaim 绑定是排他性的，不管它们是如何绑定的。 PVC 跟 PV 绑定是一对一的映射。

如果没有匹配的PV，PVC将无限期地保持未绑定状态。随着匹配PV的可用，PVC将被绑定。例如，配置了许多 50Gi PV的集群将不会匹配请求 100Gi 的PVC。将100Gi PV 添加到群集时，则可以绑定到该 PVC。

Pod 使用PVC作为卷。集群检查PVC以查找绑定的卷并为集群挂载该卷。对于支持多种访问模式的卷，用户指定在使用声明作为容器中的卷时所需的模式（读写、只读）。

用户生命了PVC，并且该PVC是绑定的，则只要用户需要，绑定的 PV 就属于该用户。用户通过在 Pod 的 volume 配置中包含persistentVolumeClaim来调度 Pod 并访问用户声明的 PV。

K8S支持的卷类型很多，主要分为分布式文件系统、ConfigMap和本地文件系统这几种，其中本地文件系统支持：hostPath和local（从1.11开始出了Beta版本，编写本文时目前K8S最新版本是1.13了）。

在我们目前项目的实际开发中，我们常用两种卷挂载模式：

但是对于使用到本地磁盘来存储数据时，hostPath往往不太适合我们了，虽然它能够让Pod使用本地存储，将Node文件系统中的文件或者目录挂载到容器内，但是在这种应用场景，hostPath并不适合生产环境使用，主要原因如下：

当然hostPath还有其他的缺点，由于以上这两个关键的缺陷，在真正需要持久化数据存储的场景，我们不得不考虑local存储卷了。

Local PV是从kuberntes 1.10开始引入，本质目的是为了解决hostPath的缺陷。通过PV控制器与Scheduler的结合，会对local PV做针对性的逻辑处理，从而，让Pod在多次调度时，能够调度到同一个Node上。

首先，我们要准备好K8S环境，检查一下K8S中的节点。

现在登录到节点10.25.68.239上，然后手工创建一个目录，我们将后在后面创建的local PV绑定到这个目录中。

创建local的Storage Class

查看一下创建的storage class

创建PV：

查看一下pv情况

创建PVC

PVC将会一直处于Pending状态直到我们创建一个Pod使用它。

创建一个deployment使用这个pvc。

pvc现在绑定到对应的pv上面了。

查看pod被调度的节点，可以看到这个pod是会被调度到PV所在的Node：

我们再次登录到10.25.68.239，在/data/pv下生成index.html文件

检查一下index.html文件的服务

Local持久卷基本具备了hostPath的绑定本地文件系统目录的能力和方便性，同时自动具备调度到指定节点的能力，并且可以对持久卷进行管理。

唯一的问题在于，我们还需要手工去对应的节点创建对应的目录和删除对应的目录，这需要结合我们的应用系统来进行统一的设计和管理。

总得来说，对于状态应用程序的部署来说，Local持久卷能够提供分布式存储无法提供的高性能，同时具备了一定的调度的灵活性，是一个不错的选择。

---