<p>These disks are accessible by only a single node.</p>
<p>Each node would have different data.</p>
<p>Also, any node can be terminated at any time, so you  would have to find a way to reattach the volume to a new node that replaces the old one. How would you do that?</p>
<p>And after scaleup, a new node might not have one of these disks available to attach to, so you would need a new disk.</p>
<p>And why might anyone want to do all this? Just for   temporary space? For that, they could use an  EC2 instance store or GCE boot disk (though I guess that that might be enough.)</p>

Joshua Fox
<p>I'm specifically familiar with EBS; I assume GCE persistent disks work the same way.  The important detail is that an EBS volume is not tied to a specific node; while it can only be attached to one node at a time, it can be moved to another node, and Kubernetes knows how to do this.</p>
<p>An EBS volume can be dynamically attached to an EC2 instance.  In Kubernetes, generally there is a <em>dynamic volume provisioner</em> that's able to create PersistentVolume objects that are backed by EBS volumes in response to PersistentVolumeClaim objects.  Critically, if a Pod uses a PVC that references an EBS-volume PV, the storage driver knows that, wherever the Pod is scheduled, it can dynamically attach the EBS volume to that EC2 instance.</p>
<p>That means that an EBS-volume PersistentVolume isn't actually &quot;locked&quot; to a single node.  If the Pod is deleted and a new one uses the PersistentVolumeClaim, the volume can &quot;move&quot; to the node that runs the new Pod.  If the Node is removed, all of its Pods can be rescheduled elsewhere, and the EBS volumes can go somewhere else too.</p>
<p>An EBS volume can only be attached to one instance at a time; in Kubernetes volume terminology, it can only have a <code>ReadWriteOnce</code> <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes" rel="nofollow noreferrer">access mode</a>.  If it could be attached to many instances (as, for instance, an EFS NFS-based filesystem could be) it could be <code>ReadOnlyMany</code> or <code>ReadWriteMany</code>.</p>
<p>This makes EBS be a reasonably good default choice for persistent data storage, <em>if your application actually needs it</em>.  It's not actually host-specific and it can move around the cluster as needed.  It won't work if two Pods need to share files, but this is generally a complex and fragile setup and it's better to design your application to not need it.</p>
<p>The best setup is if your application doesn't need persistent local storage at all.  This makes it easy to scale Deployments, because the data is &quot;somewhere else&quot;.  The data could be in a database; the data could be in a managed database, such as RDS; or it could be in an object-storage system like S3.  Again, this requires changes in your application to not use local files for data storage.</p>
