【发布时间】：2020-04-18 10:15:30
【问题描述】：
如果 pod 死亡并在另一个节点上再次上升，kubernetes 的 HostPath 卷会发生什么情况？
我猜一个新的上升节点上的新 pod 不会看到它？卷会永远存在并泄漏磁盘空间吗？
什么是防止这种情况的正确解决方案？
【问题讨论】：
标签： kubernetes kubernetes-pod persistent-volumes
【发布时间】：2020-04-18 10:15:30
【问题描述】：
主机路径卷是一种“逃生舱”。没有特别的持久性、生命周期或任何与它们相关的东西。如果一个 pod 被重新调度到不同的节点上，那么
它会在另一个节点上看到相同主机目录的内容，可能相同也可能不同，并且
如果您将应用程序数据存储在第一个节点的主机目录中，它实际上会变成“孤立的”。
这使得主机路径卷不能很好地匹配正常的应用程序数据；几乎可以选择任何其他存储类型。
我看到它们有效使用的地方是您确实需要管理一些通常存在于主机系统上的数据。例如，standard fluentd Kubernetes deployment 在一个守护进程集中运行 fluentd，以从集群中每个节点上的/var/lib/docker/containers 收集日志；这是由主机 Docker 守护进程管理的数据，而不是由任何特定容器管理的数据。因为它是由一个守护程序集管理的，所以它在每个节点上运行，所以如果一个节点离开它的日志，它的日志转发器也会随之离开，这是完全可以预料的。
【讨论】：
-
很好的解释，请告知“选择几乎任何其他存储类型”。 - 选择什么？
-
这取决于集群中可用的内容； Types of Volumes 的列表可能是一个有用的起点。可能最好的方法是创建一个persistent volume claim 并让集群为您分配存储。
比 HostPath 稍微好一点的解决方案是使用local PersistentVolumes
本地卷只能用作静态创建的 PersistentVolume。尚不支持动态配置。 与 hostPath 卷相比，本地卷可以以持久且可移植的方式使用，而无需手动将 Pod 调度到节点，因为系统通过查看 PersistentVolume 上的节点亲和性来了解卷的节点约束。
但是，本地卷仍然受制于底层节点的可用性，并不适合所有应用程序。如果一个节点变得不健康，那么本地卷也将变得不可访问，并且使用它的 Pod 将无法运行。使用本地卷的应用程序必须能够容忍这种可用性降低以及潜在的数据丢失，具体取决于底层磁盘的持久性特征。
可以单独运行外部静态配置器，以改进对本地卷生命周期的管理。请注意，此配置器尚不支持动态配置。有关如何运行外部本地配置程序的示例，请参阅local volume provisioner 用户指南。
如果不使用外部静态配置器来管理卷生命周期，则本地 PersistentVolume 需要用户手动清理和删除。
【讨论】：