<p>I am learning Kubernetes and quite new to it.</p>
<p>let us say a pod A needs to use some persistent volume in node A (i.e. meaning the container in the pod A will write some data into some path in node A). Then after some time, the pod A dies and a new pod B is scheduled to node B. Then, can pod B somehow remotely access that persistent volume in node A so that it can still work properly?</p>
<p>In other words, can Kubernetes provide some local persistent volume in a particular node that can be used by a pod and can still be accessed although the pod can be rescheduled to another node?</p>

<p>It is recommended to use <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/" rel="nofollow noreferrer">Persistent Volumes</a> and <code>Persistent Volume Claims</code> when an application deployed on Kubernetes needs storage.</p>
<p>PV and PVC are abstractions and can be backed by several different storage systems, with its own properties/capabilities.</p>
<h2>Volumes located off-Node</h2>
<p>The most common backing of Kubernetes PV at cloud providers is <a href="https://aws.amazon.com/ebs" rel="nofollow noreferrer">AWS Elastic Block Storage</a> and <a href="https://cloud.google.com/persistent-disk" rel="nofollow noreferrer">Google Persistent Disk</a>. These systems are not local volumes on the Kubernetes Nodes, but accessed over the network. From the applications view, it is accessed through the filesystem, like a local volume. This has the advantage that these volumes <strong>are accessible from any Node</strong> within the Availability Zone.</p>
<h2>Volumes located on-Node</h2>
<p>However, the cloud providers also offer Local Disks that are physical disks on the Node. Those are much more expensive, you allocate larger volumes but you also get much better disk performance. The typical usage for those are <em>distributed databases</em>, e.g. deployed as <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSets</a> and actively replicate the data between eachother, typically using <a href="https://raft.github.io/" rel="nofollow noreferrer">Raft Consensus Algorithm</a> - this means that they can tolerate to loose an instance (including the disk) and recover from that state, by creating a new instance - that starts to catchup with the data replication.</p>
