<p>What happens with kubernetes's HostPath's volume in case of pod dying and rising again on another node?</p>

<p>I guess a new pod on a new rised node will not see it? Will the volume live forever and leak diskspace?</p>

<p>What is the right solution to prevent that?</p>

J.J. Beam
<p>Host-path volumes are kind of an "escape hatch".  There's no particular persistence, life cycle, or anything else associated with them.  If a pod gets rescheduled on a different node, then</p>

<ol>
<li><p>It will see the contents of the same host directory on the other node, which may or may not be the same, and</p></li>
<li><p>If you were storing application data in that host directory on the first node it will in fact become "orphaned".</p></li>
</ol>

<p>This makes host-path volumes not a good match for normal application data; choose pretty much any other storage type.</p>

<p>The place where I've seen them used effectively is where you do actually need to manage some data that normally lives on the host system.  The <a href="https://docs.fluentd.org/container-deployment/kubernetes" rel="nofollow noreferrer">standard fluentd Kubernetes deployment</a>, for example, runs fluentd in a daemon set to collect the logs from <code>/var/lib/docker/containers</code> on every node in the cluster; that's data managed by the host Docker daemon and not by any particular container.  Because it's managed by a daemon set, it runs on <em>every</em> node, so if a node goes away its logs and its log forwarder will go away with it, and that's fairly expected.</p>
