感谢作者，原文链接：https://cloud.tencent.com/developer/article/1195068
摘要：本文分析了hostPath volume缺陷，然后对local persistent volume的使用场景、基本的工作机制进行了分析，介绍了使用时的注意事项，并简单介绍local volume manager如何帮助administrator进行local persistent volume的生命周期管理的。
hostPath volume存在的问题
过去我们经常会通过hostPath volume让Pod能够使用本地存储，将Node文件系统中的文件或者目录挂载到容器内，但是hostPath volume的使用是很难受的，并不适合在生产环境中使用。
我们先看看hostPath Type有哪些类型：
看起来支持这么多type还是挺好的，但为什么说不适合在生产环境中使用呢？
由于集群内每个节点的差异化，要使用hostPath Volume，我们需要通过NodeSelector等方式进行精确调度，这种事情多了，你就会不耐烦了。
注意DirectoryOrCreate和FileOrCreate两种类型的hostPath，当Node上没有对应的File/Directory时，你需要保证kubelet有在Node上Create File/Directory的权限。
另外，如果Node上的文件或目录是由root创建的，挂载到容器内之后，你通常还要保证容器内进程有权限对该文件或者目录进行写入，比如你需要以root用户启动进程并运行于privileged容器，或者你需要事先修改好Node上的文件权限配置。
Scheduler并不会考虑hostPath volume的大小，hostPath也不能申明需要的storage size，这样调度时存储的考虑，就需要人为检查并保证。
StatefulSet无法使用hostPath volume，已经写好的使用共享存储的Helm Chart不能兼容hostPath volume，需要修改的地方还不少，这也挺难受的。
local persistent volume
FEATURE STATE: Kubernetes v1.11 Beta
Local persistent volume就是用来解决hostPath volume面临的portability, disk accounting, and scheduling的缺陷。PV Controller和Scheduler会对local PV做特殊的逻辑处理，以实现Pod使用本地存储时发生Pod re-schedule的情况下能再次调度到local volume所在的Node。
local pv在生产中使用，也是需要谨慎的，毕竟它本质上还是使用的是节点上的本地存储，如果没有相应的存储副本机制，那意味着一旦节点或者磁盘异常，使用该volume的Pod也会异常，甚至出现数据丢失，除非你明确知道这个风险不会对你的应用造成很大影响或者允许数据丢失。
那么通常什么情况会使用Local PV呢？
比如节点上的目录数据是从远程的网络存储上挂载或者预先读取到本地的，为了能加速Pod读取这些数据的速度，相当于起Cache作用，这种情况下因为只读，不存在惧怕数据丢失。这种AI训练中存在需要重复利用并且训练数据巨大的时候可能会采取的方式。
如果本地节点上目录/磁盘实际是具有副本/分片机制的分布式存储(比如gluster, ceph等)挂载过来的，这种情况也可以使用local pv。
Local volume允许挂载本地的disk, partition, directory到容器内某个挂载点。在Kuberentes 1.11仍然仅支持local pv的static provision，不支持dynamic provision。
Kubernetes使用PersistentVolume的.spec.nodeAffinityfield来描述local volume与Node的绑定关系。
使用volumeBindingMode: WaitForFirstConsumer的local-storage StorageClass来实现PVC的延迟绑定，使得PV Controller并不会立刻为PVC做Bound，而是等待某个需要使用该local pv的Pod完成调度后，才去做Bound。
下面是定义local pv的Sample：
对应的local-storage storageClass定义如下：
注意事项
使用local pv时必须定义nodeAffinity，Kubernetes Scheduler需要使用PV的nodeAffinity描述信息来保证Pod能够调度到有对应local volume的Node上。
volumeMode可以是FileSystem（Default）和Block，并且需要enable BlockVolume Alpha feature gate。
创建local PV之前，你需要先保证有对应的storageClass已经创建。并且该storageClass的volumeBindingMode必须是WaitForFirstConsumer以标识延迟Volume Binding。WaitForFirstConsumer可以保证正常的Pod调度要求（resource requirements, node selectors, Pod affinity, and Pod anti-affinity等），又能保证Pod需要的Local PV的nodeAffinity得到满足，实际上，一共有以下两种volumeBindingMode：
节点上local volume的初始化需要我们人为去完成（比如local disk需要pre-partitioned, formatted, and mounted. 共享存储对应的Directories也需要pre-created），并且人工创建这个local PV，当Pod结束，我们还需要手动的清理local volume，然后手动删除该local PV对象。因此，persistentVolumeReclaimPolicy只能是Retain。
local volume manager
上面这么多事情需要人为的去做预处理的工作，我们必须要有解决方案帮我们自动完成local volume的create和cleanup的工作。官方给出了一个简单的local volume manager，注意它仍然只是一个static provisioner，目前主要帮我们做两件事：
local volume manager 监控配置好的discovery directory的新的挂载点，并为每个挂载点根据对应的storageClassName, path, nodeAffinity, and capacity创建PersistentVolume object。
当Pod结束并删除了使用local volume的PVC，local volume manager将自动清理该local mount上的所有文件, 然后删除对应的PersistentVolume object.
因此，除了需要人为的完成local volume的mount操作，local PV的生命周期管理就全部交给local volume manager了。下面我们专门介绍下这个Static Local Volume Provisioner。
后面我会单独写一个博文对local volume manager进行深度剖析。
总结
本文对hostPath volume不能在生产环境中很好使用的原因进行了阐述，然后对local persistent volume的使用场景、基本的工作机制进行了分析，介绍了使用时的注意事项，最后简单介绍了local volume manager如何帮助administrator进行local persistent volume的生命周期管理的。接下来，我会再写两篇博客，分别对scheduler和pv controller如何对local persistent volume的处理逻辑进行源码分析，对local volume manager进行深度剖析。
============================
PV，PVC，POD是如何工作的？流程如下：
网友评论