云计算时代操作系统Kubernetes之PV，PVC存储体系

Posted 2023-03-28

参考技术A 我们前边的关于存储卷的讨论，都是在讲如何将网络存储设备挂载到我们的应用程序POD中，而在实际项目上，我们必须对集群所提供存储技术和类型有深入的理解，才能顺利完成将支持类型的volume挂载到容器中，供应用程序来持久化数据。

举个例子，如果你使用的是托管的阿里巴巴ACK集群，需要使用OSS存储类型，那么你就必须定义对应的Persistent Volume，当我们将应用迁移到自己数据中心后，就需要定义数据中心Kubernetes环境支持的Persistent Volume对象，因此这种直接定义PV的方式，灵活性太差了。为了能在其他云平台上使用PV，我们就必须修改YAML文件，以适配新的环境。

我们一直强调Kubernetes标准化了应用程序的部署，特别是在多个云平台之间的跨云部署场景，每次都修改PV才能完成部署很明显有悖于我们介绍的Kubernetes理念。幸运的是，Kubernetes已经考虑了这个问题，并且提供了一种更加便利的机制来给POD增加存储资源。而我们通常把这种机制叫做PV/PVC体系。

理想情况下对于开发人员而言，部署应用程序到Kubernetes集群就不应该关心具体的存储技术和细节，就如同Kubernetes将工作节点进行抽象类型，开发人员面对的只有POD，而基础设施相关的部分应该让专业人士来处理，比如集群的运维人员和专业的devops团队。

正因为如此，我们在部署应用到Kuberntes集群的时候，我们很少直接设置具体存储的细节，而是通过一种间接的方式来使用PV提供的存储能力，如下图所示，这就把POD和底层具体的存储系统进行了解耦，POD的定义中不用在包含和具体基础设施相关的配置信息：

很多公司内部都会自己搭建NFS文件存储服务器，我们来举个例子，假设在POD中我们要使用NFS文件服务来共享数据，那么在volume的定义中就需要包含NFS文件服务器的IP地址和要挂载的目录路径，如下图所示：

注：网络文件系统（NFS）是文件系统之上的一个网络抽象，允许远程客户端以和本地文件系统类似的方式来通过网络进行数据访问。NFS允许在多个用户之间共享公共文件系统，并提供数据集中的优势，来最小化所需的存储空间。

这样做的结果是，我们将POD和具体的集群存储细节进行了耦合，从而降低了灵活性。如果我们要将如上这个POD部署到另外一个集群中，那么我们就需要修改NFS文件服务器的IP地址，修改YAML文件可能会产生错误，因此这种方式本质上说明POD跨Kubernetes集群部署的灵活性不足。如下图所示：

由于这个原因，我们需要将环境相关的配置信息抽取到另外一个叫PV的对象中，来解耦POD和具体存储信息，提升POD的兼容性。Kubernetes平台用PersistentVolume对象来代表集群中可以用来存储数据的volume，如下图所示，PersistentVolume对象将底层存储机制的详细信息从POD的YAML文件中解耦：

由于POD中不再包含基础设施相关的配置信息，兼容性得到了极大的提升。当然这些配置信息还是需要的，只是被转移到PV对象上而已。本上上来看，这其实并不是什么新技术。但是计算机从发展之初，通过增加一层来解决问题的方法，可以说是屡试不爽，我们应该在自己的架构设计中，多多考虑这样的思想，当然需要考虑复杂性和合理性，并不是说中间层越多越好。

笔者在上篇文章中介绍过使用阿里云OSS存储卷类型的例子，如果你还有印象的话，应该记得我们的配置文件中使用persistentVolumeClaim对象来定义数据卷，如下图所示。在Kubernetes平台中，通常POD间接的通过PVC映射到PV对象，这就让PV从POD的生命周期中进一步解耦。

如上图所示，PersistentVolumeClaim对象表示用户对存储资源的需求，由于用户在使用存储资源的时候，并不清楚集群中有哪些类型的Volume，因此Kubernetes就引入了这个PVC对象，来简化使用PV的复杂度。这样的话我们只需要在定义POD的时候，使用PVC对象即可，而在PVC对象的定义中，我们需要声明存储的需求，比如存储空间大小，访问模式等。

当POD运行完成退出的时候，会删除PVC，底层的PV会被释放，释放后的PV就可以被其他的PVC使用。接下来我们通过一个实际的例子看看如何定义PCV和PV存储模式。

比如我们现在已经在集群中创建了一个PV对象，指向NFS文件存储服务器；有一个PVC对象绑定到PV对象，这样我们就可以直接在POD的YAML中，数据卷定义部分直接指定PVC对象，不用设置详细的NFS文件服务器IP地址等。

如下图所示，当POD被调度到具体的工作节点时，Kubernetes负责通过PVC引用到PV对象，然后使用PV对象中配置的NFS文件服务器的信息将对应的目录挂载到容器中。

如上图所示，POD在创建的时候，会通过PVC引用的PV对象来定位到存储资源的具体信息，并将指定的目录挂载到容器实例上。表面看，通过三个对象来挂载存储资源很明显比一个要复杂，但是你有没有深入思考过Kubernetes为什么要如此设计？

其实这里最大的好处就是“解耦”，或者叫消除依赖。通过增加PV和PVC这两个对象，基础设施相关的信息和应用的部署YAML解耦了，让专业的人，集群管理员来负责PV的创建，开发人员的时间就可以放在更具价值的开发上，如果要部署，只需要使用PCV来声明自己的需求就可以了。如下图所示，我们来看看集群管理员开发人员是如何配合在一起，各司其职，成功将应用部署到Kubernetes集群上：

如上图所示，开发人员不用再面对具体底层的存储资源配置细节，集群管理员统一负责配置和管理所有的存储资源，并且在Kubernetes平台上通过创建PV对象来提供给应用程序使用。当开发人员在部署应用的时候，通过创建PVC来声明具体要使用的资源需求，比如直接指定PV对象的名称，或者指定请求的存储空间大小和访问模式，Kubernetes基于这些信息完成绑定。

接下来我们就可以在POD中定义volume的时候使用PCV，当POD被创建的时候，POD中运行的容器实例就可以将存储设备attach到工作节点，并将指定的目录挂载到容器的文件目录树中。大家需要特别注意的是，在PVC/PV模式下，开发人员不需要了解底层具体的存储设备信息，这部分工作属于专业人士集群管理员，开发人员只需要通过PVC来声明应用的存储资源需求。

进一步讲，如果我们的集群是托管实例，那么管理员甚至都不需要自己手动来进行PV的创建和管理，我们可以通过云平台提供的自动化volume提供机制，在有需要的时候，自动创建PersistentVolume和PersistentVolumeClaim对象，提供给应用程序使用。

通过上边的内容，相信读者对PVC/PV有全面的了解了，接下来我们来通过实际的例子来验证一下。由于笔者使用的Kubernetes环境支持的存储资源非常有限，但是又需要通过具体的例子来说明这些对象如何使用，笔者决定暂缓这部分内容到后续专门介绍如何在阿里云ACK上使用PV/PCV。

好了，今天的内容就这么多了，我们下篇文章会介绍云原生模式中一个非常重要的概念，如何让应用无状态，或者说如何管理应用程序的配置信息，敬请期待！