问为什么会有人想要在Kubernetes中使用GCE Persistent Disk或EBS？

EN

我特别熟悉EBS；我假设GCE持久化磁盘也是以同样的方式工作的。重要的细节是，EBS卷不绑定到特定节点；虽然它一次只能连接到一个节点，但可以移动到另一个节点，Kubernetes知道如何做到这一点。

EBS卷可以动态附加到EC2实例。在Kubernetes中，通常有一个

动态卷调配程序

它能够创建由EBS卷支持的PersistentVolume对象，以响应PersistentVolumeClaim对象。重要的是，如果Pod使用引用EBS-volume PV的PVC，那么存储驱动程序知道，无论Pod被调度到哪里，它都可以动态地将EBS卷附加到该EC2实例。

这意味着EBS卷PersistentVolume实际上并没有“锁定”到单个节点。如果Pod被删除，而新的Pod使用PersistentVolumeClaim，则卷可以“移动”到运行新Pod的节点。如果Node被删除，它的所有Pod都可以在其他地方重新调度，EBS卷也可以到其他地方。

一个EBS卷一次只能附加到一个实例；在Kubernetes卷术语中，它只能有一个ReadWriteOnce访问模式

..。如果它可以连接到许多实例(例如，基于EFS的文件系统)，那么它可能是ReadOnlyMany 或者 ReadWriteMany..。

这使得EBS成为持久数据存储的相当好的默认选择，如果您的应用程序确实需要它..。它实际上不是特定于主机的，它可以根据需要在集群中移动。如果两个Pod需要共享文件，它将无法工作，但这通常是一个复杂和脆弱的设置，最好将您的应用程序设计为不需要它。

最好的设置是如果您的应用程序根本不需要持久本地存储。这使得扩展部署变得很容易，因为数据在“其他地方”。数据可以在数据库中；数据可以在托管数据库中，比如关系数据库；也可以在对象存储系统中，比如S3。同样，这需要在应用程序中进行更改，使其不使用本地文件进行数据存储。