这些磁盘只能由单个节点访问。
每个节点会有不同的数据。
此外，任何节点都可以随时终止，因此您必须找到一种方法将卷重新附加到替换旧节点的新节点。你会怎么做？
在扩展后，新节点可能没有这些磁盘可供附加，因此您需要一个新磁盘。
为什么有人想做这一切？只是为了临时空间？为此，他们可以使用 EC2 实例存储或 GCE 启动磁盘（尽管我猜这可能就足够了。）
【问题讨论】：
标签： kubernetes google-kubernetes-engine persistent-volumes
我特别熟悉 EBS；我假设 GCE 永久性磁盘的工作方式相同。重要的细节是 EBS 卷不绑定到特定节点；虽然一次只能附加到一个节点，但它可以移动到另一个节点，Kubernetes 知道如何做到这一点。
EBS 卷可以动态附加到 EC2 实例。在 Kubernetes 中，通常有一个动态卷配置器，它能够创建由 EBS 卷支持的 PersistentVolume 对象，以响应 PersistentVolumeClaim 对象。至关重要的是，如果 Pod 使用引用 EBS 卷 PV 的 PVC，则存储驱动程序知道，无论 Pod 被调度到何处，它都可以将 EBS 卷动态附加到该 EC2 实例。
这意味着 EBS 卷 PersistentVolume 实际上并未“锁定”到单个节点。如果 Pod 被删除并且新 Pod 使用 PersistentVolumeClaim，则卷可以“移动”到运行新 Pod 的节点。如果节点被移除，它的所有 Pod 都可以重新调度到其他地方，EBS 卷也可以转移到其他地方。
一个 EBS 卷一次只能附加到一个实例；在 Kubernetes 卷术语中，它只能有一个 ReadWriteOnce access mode。如果它可以附加到许多实例（例如，可以是基于 EFS NFS 的文件系统），它可能是 ReadOnlyMany 或 ReadWriteMany。
这使得 EBS 成为持久数据存储的一个相当不错的默认选择，如果您的应用程序确实需要它。它实际上不是特定于主机的，它可以根据需要在集群中移动。如果两个 Pod 需要共享文件，这将不起作用，但这通常是一个复杂而脆弱的设置，最好将您的应用程序设计为不需要它。
最好的设置是如果您的应用程序根本不需要持久的本地存储。这使得扩展部署变得容易，因为数据在“其他地方”。数据可以在数据库中；数据可以在托管数据库中，例如 RDS；或者它可以在像 S3 这样的对象存储系统中。同样，这需要更改您的应用程序以不使用本地文件进行数据存储。
【讨论】：