<p>According to <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/" rel="nofollow noreferrer">the documentation</a>:</p>
<blockquote>
<p>A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned ... It is a resource in the cluster just like a node is a cluster resource...</p>
</blockquote>
<p>So I was reading about all currently available <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes" rel="nofollow noreferrer">plugins</a> for PVs and I understand that for 3rd-party / out-of-cluster storage this doesn't matter (e.g. storing data in EBS, Azure or GCE disks) because there are no or very little implications when adding or removing nodes from a cluster. However, there are different ones such as (ignoring <code>hostPath</code> as that works only for single-node clusters):</p>
<ul>
<li>csi</li>
<li>local</li>
</ul>
<p>which (at least from what I've read in the docs) don't require 3rd-party vendors/software.</p>
<p>But <a href="https://kubernetes.io/docs/concepts/storage/volumes/#local" rel="nofollow noreferrer">also</a>:</p>
<blockquote>
<p>... local volumes are subject to the availability of the underlying node and are not suitable for all applications. If a node becomes unhealthy, then the local volume becomes inaccessible by the pod. The pod using this volume is unable to run. Applications using local volumes must be able to tolerate this reduced availability, as well as potential data loss, depending on the durability characteristics of the underlying disk.</p>
</blockquote>
<blockquote>
<p>The local PersistentVolume requires manual cleanup and deletion by the user if the external static provisioner is not used to manage the volume lifecycle.</p>
</blockquote>
<p><strong>Use-case</strong></p>
<p>Let's say I have a single-node cluster with a single <code>local</code> PV and I want to add a new node to the cluster, so I have 2-node cluster (small numbers for simplicity).</p>
<p>Will the data from an already existing <code>local</code> PV be 1:1 replicated into the new node as in having one PV with 2 nodes of redundancy or is it strictly bound to the existing node only?</p>
<p>If the already existing PV can't be adjusted from 1 to 2 nodes, can a <strong>new PV</strong> (created from scratch) be created so it's 1:1 replicated between 2+ nodes on the cluster?</p>
<p>Alternatively if not, what would be the correct approach without using a 3rd-party out-of-cluster solution? Will using <code>csi</code> cause any change to the overall approach or is it the same with redundancy, just different &quot;engine&quot; under the hood?</p>

Peter Badida
<blockquote>
<p>Can a new PV be created so it's 1:1 replicated between 2+ nodes on the cluster?</p>
</blockquote>
<p>None of the standard volume types are replicated at all.  If you can use a volume type that supports <code>ReadWriteMany</code> access (most readily NFS) then multiple pods can use it simultaneously, but you would have to run the matching NFS server.</p>
<p>Of the volume types you reference:</p>
<ul>
<li><p><code>hostPath</code> is a directory on the node the pod happens to be running on.  It's not a directory on any specific node, so if the pod gets recreated on a different node, it will refer to the same directory but on the new node, presumably with different content.  Aside from basic test scenarios I'm not sure when a <code>hostPath</code> PersistentVolume would be useful.</p>
</li>
<li><p><code>local</code> is a directory on a specific node, or at least following a node-affinity constraint.  Kubernetes knows that not all storage can be mounted on every node, so this automatically constrains the pod to run on the node that has the directory (assuming the node still exists).</p>
</li>
<li><p><code>csi</code> is an extremely generic extension mechanism, so that you can run storage drivers that aren't on the list you link to.  There are some features that might be better supported by the CSI version of a storage backend than the in-tree version.  (I'm familiar with AWS: the <a href="https://github.com/kubernetes-sigs/aws-ebs-csi-driver" rel="nofollow noreferrer">EBS CSI driver</a> supports snapshots and resizing; the <a href="https://github.com/kubernetes-sigs/aws-efs-csi-driver" rel="nofollow noreferrer">EFS CSI driver</a> can dynamically provision NFS directories.)</p>
</li>
</ul>
<p>In the specific case of a local test cluster (say, using <a href="https://kind.sigs.k8s.io" rel="nofollow noreferrer">kind</a>) using a <code>local</code> volume will constrain pods to run on the node that has the data, which is more robust than using a <code>hostPath</code> volume.  It won't replicate the data, though, so if the node with the data is deleted, the data goes away with it.</p>
