我想将PostgreSQL数据库中的数据存储在persistentvolumeclaim中。(在Microsoft Azure上的托管Kubernetes集群上(
我不确定该选择哪种访问模式
查看可用的访问模式：
ReadWriteOnceReadOnlyManyReadWriteManyReadWriteOncePod
我想说，我应该选择ReadWriteOnce或ReadWriteMany。
考虑到我可能想在某个时候将数据库pod迁移到另一个节点池，我会直观地选择ReadWriteMany。
如果我选择ReadWriteMany而不是ReadWriteOnce，会有什么缺点吗？
迁移是正确的，其中访问模式应设置为ReadWriteMany。
通常，如果您在microsoft azure上具有访问模式ReadWriteOnce和多节点集群，其中需要多个pod访问数据库，那么kubernetes将强制所有pod都安排在首先装载卷的节点上。您的节点可能会被pod过载。现在，如果您有一个DaemonSet，其中每个节点上安排一个pod，这可能会带来问题。在这种情况下，最好使用访问模式ReadWriteMany标记PVC和PV。
因此
- 如果您希望在多个节点上调度多个pod，并且可以访问DB，则对于写入和读取权限，请使用访问模式
ReadWriteMany - 如果您在逻辑上需要在一个节点上有pod/db，并且确信您将在一个结点上保留该逻辑，请使用访问模式
ReadWriteOnce
您应该选择ReadWriteOnce。
我对AWS有点熟悉，所以我会把它作为一个激励性的例子。在AWS中，最容易获得的持久卷由Amazon弹性块存储(EBS(卷支持。这一次只能附加到一个节点，这就是ReadWriteOnce语义；但是，如果当前没有任何东西在使用该卷，则可以将其分离并重新连接到另一个节点，并且集群知道如何做到这一点。
同时，在PostgreSQL数据库存储(以及大多数其他数据库存储(的情况下，一次只能有一个进程在一个或多个节点上使用物理存储。在最好的情况下，指向同一存储的数据库的第二个副本将无法启动；在最坏的情况下，你会破坏数据。
因此：
- 一次将卷连接到多个pod是没有意义的
- 因此，一次将卷连接到多个节点是没有意义的
ReadWriteOnce卷很容易获得，但默认情况下ReadWriteMany可能不可用
此逻辑可能适用于大多数用例，特别是在云环境中，在云环境下，您还可以使用云提供商的本地存储系统(例如，AWS S3存储桶(。进程之间共享文件充满了危险，尤其是在多个节点之间。我几乎总是选择ReadWriteOnce，而没有真正特定的使用需求。