本篇内容介绍了“hostPath volume存在的问题有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
hostPath volume存在的问题
过去我们经常会通过hostPath volume让Pod能够使用本地存储，将Node文件系统中的文件或者目录挂载到容器内，但是hostPath volume的使用是很难受的，并不适合在生产环境中使用。
我们先看看hostPath Type有哪些类型：
| Value | Behavior |
|---|
| Empty string (default) is for backward compatibility, which means that no checks will be performed before mounting the hostPath volume. |
| DirectoryOrCreate | If nothing exists at the given path, an empty directory will be created there as needed with permission set to 0755, having the same group and ownership with Kubelet. |
| Directory | A directory must exist at the given path |
| FileOrCreate | If nothing exists at the given path, an empty file will be created there as needed with permission set to 0644, having the same group and ownership with Kubelet. |
| File | A file must exist at the given path |
| Socket | A UNIX socket must exist at the given path |
| CharDevice | A character device must exist at the given path |
| BlockDevice | A block device must exist at the given path |
看起来支持这么多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：
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
spec:
capacity:
storage: 100Gi
# volumeMode field requires BlockVolume Alpha feature gate to be enabled.
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: local-storage
local:
path: /mnt/disks/ssd1
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- example-node
对应的local-storage storageClass定义如下：
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
使用local persistent volume注意事项
使用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：
// VolumeBindingImmediate indicates that PersistentVolumeClaims should be
// immediately provisioned and bound.
VolumeBindingImmediate VolumeBindingMode = "Immediate"
// VolumeBindingWaitForFirstConsumer indicates that PersistentVolumeClaims
// should not be provisioned and bound until the first Pod is created that
// references the PeristentVolumeClaim. The volume provisioning and
// binding will occur during Pod scheduing.
VolumeBindingWaitForFirstConsumer VolumeBindingMode = "WaitForFirstConsumer"
节点上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。
“hostPath volume存在的问题有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注天达云网站，小编将为大家输出更多高质量的实用文章！