共计 1392 个字符，预计需要花费 4 分钟才能阅读完成。
在 Kubenetes 体系内，针对每一个长久化存储卷，都有三种拜访形式：ReadWriteOnce(RWO)，ReadOnlyMany(ROX)，ReadWriteMany(RWX)。在以后的定义中，这三种形式都是针对节点级别的，也就是说，对于一个 Persistent Volume, 如果是 RWO, 那么只能被挂载在某一个 Kubernetes 的工作节点（以下简称节点）上，当再次尝试在其余节点挂载的时候，零碎会报 Multi-Attach 的谬误（当然，在只有一台可调度节点的状况，即便 RWO 也是可能被多个 Pod 同时应用的，但除了开发测试，有谁会这么用呢？）；如果是 RMX, 那么能够同时在多个节点上挂载并被不同的 Pod 应用。举例如下:
在官网文档中（https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes），
咱们能够理解到目前存储反对 ReadWriteMany 的状况如下：
从列表中咱们能够看到，只有文件类的存储可能反对 ReadWriteMany, 而所有的块存储，无论是私有云，还是 Ceph, iSCSI，都无奈反对 RWX。
那么 RWX 到底意味着什么？对于用户的利用来说有什么影响呢？咱们以理论的一个利用 WordPress 为例，典型的拓扑构造如下：
多个 WordPress 实例之间须要一个共享的卷作为 Uploads 目录，同时还须要一个 MySQL 服务。这个共享卷就是一个很典型的 ReadWriteMany 的需要，当 WordPress 实例须要疾速横向扩大的时候，新扩大的实例能够间接拜访到原有的用户上传的数据，不须要复制等操作，因为大家共享的是一份数据，这种需要对于不反对 ReadWriteMany 的块存储来说，就十分难堪了。咱们会发现在真实世界中，不乏各种困惑的声音，例如下图中的这个理论例子（https://www.digitalocean.com/community/questions/kubernetes-readwritemany-or-the-same-effect），
来个摘要，这位小哥正在寻找一个容器平台上运行 WordPress 的计划，须要在多个 Pod 上同时拜访同一份数据（Master 上可读可写，其它节点只读）。
人民的力量是微小的，也不是没有解决方案，见下图（https://blog.openebs.io/setting-up-persistent-volumes-in-rwx-mode-using-openebs-142632244cb2?gi=1a701ed8e4bd），咱们看到它是利用相似于 Re-Export 的形式，将块存储暴露出 NFS 的接口来实现了。但它真的好吗？暂且不说性能如何，这里存在着单点啊，因为图中的 RWO 卷只能挂载给一个 NFS。
焱融 YRCloudFile 是一款专门针对容器场景开发的高性能分布式文件存储，天生的反对 ReadWriteMany 的读写形式，通过如下的拓扑构造，完满的解决了有状态利用 WordPress 的高可用构造，无论是共享的目录，还是 MySQL 数据库须要的存储目录，对立治理，高性能反对。
在下一篇文章中，作者将联合上图，以高牢靠、高可扩大的 WordPress 架构为例，理论地演示如何联合焱融容器存储，部署基于 ReadWriteMany 读写模式的利用。
