如果pod在另一个节点上死亡并再次上升，kubernetes的HostPath的卷会发生什么？
我想一个新的节点上的新吊舱不会看到它吗？卷会永远存在并泄漏磁盘空间吗？
防止这种情况的正确解决方案是什么？
主机路径卷有点像"逃生舱口"。没有特别的持久性、生命周期或任何其他与之相关的东西。如果一个吊舱在另一个节点上被重新安排，那么
-
它将在另一个节点上看到相同主机目录的内容，这些内容可能相同，也可能不相同，以及
-
如果您将应用程序数据存储在第一个节点的主机目录中，那么它实际上将成为"孤立"。
这使得主机路径卷与正常应用程序数据不匹配；几乎可以选择任何其他存储类型。
我看到它们被有效使用的地方是您确实需要管理一些通常存在于主机系统上的数据的地方。例如，标准的fluentd Kubernetes部署在守护进程集中运行fluentd，以收集集群中每个节点上/var/lib/docker/containers的日志；这是由主机Docker守护进程管理的数据，而不是由任何特定的容器管理的数据。因为它是由守护进程集管理的，所以它在每个节点上运行，所以如果一个节点离开了它的日志，它的日志转发器也会随之离开，这是意料之中的事。
比HostPath稍好的解决方案是使用本地PersistentVolumes
本地卷只能用作静态创建的PersistentVolume。尚不支持动态设置。与hostPath卷相比，本地卷可以以持久和可移植的方式使用，而无需手动将Pod调度到节点，因为系统通过查看PersistentVolume上的节点相关性来了解卷的节点约束。
但是，本地卷仍然受制于底层节点的可用性，并不适合所有应用程序。如果一个节点变得不健康，那么本地卷也将变得不可访问，使用它的Pod将无法运行。使用本地卷的应用程序必须能够容忍这种可用性降低以及潜在的数据丢失，这取决于底层磁盘的持久性特征。
外部静态预配置程序可以单独运行，以改进对本地卷生命周期的管理。请注意，此设置程序还不支持动态设置。有关如何运行外部本地设置程序的示例，请参阅本地卷设置程序用户指南。
如果未使用外部静态设置程序管理卷生命周期，则本地PersistentVolume需要用户手动清理和删除。