为什么 ReadWriteOnce 在不同的节点上工作？

Question

我们在 K8s 上运行的平台具有不同的组件。我们需要在其中两个组件（comp-A 和 comp-B）之间共享存储，但我们错误地将 PV 和 PVC 定义为 ReadWriteOnce，即使这两个组件在不同节点上运行，一切正常我们能够从这两个组件读取和写入存储。

根据 K8s 文档，ReadWriteOnce 可以挂载到一个节点，我们必须使用 ReadWriteMany：

• ReadWriteOnce -- 卷可以由单个节点以读写方式挂载
• ReadOnlyMany -- 卷可由多个节点以只读方式挂载
• ReadWriteMany -- 卷可以被许多节点以读写方式挂载"

所以我想知道为什么一切正常，而它不应该？

更多信息： 我们使用 NFS 进行存储，我们没有使用动态配置，下面是我们如何定义 pv 和 pvc（我们使用 helm）：

- apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: gstreamer-{{ .Release.Namespace }}
  spec:
    capacity:
      storage: 10Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Recycle
    mountOptions:
      - hard
      - nfsvers=4.1
    nfs:
      server: {{ .Values.global.nfsserver }}
      path: /var/nfs/general/gstreamer-{{ .Release.Namespace }}

- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: gstreamer-claim
    namespace: {{ .Release.Namespace }}
  spec:
    volumeName: gstreamer-{{ .Release.Namespace }}
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi

更新

一些 kubectl 命令的输出：

$ kubectl get -n 149 pvc
NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
gstreamer-claim   Bound    gstreamer-149                              10Gi       RWO                           177d


$ kubectl get -n 149 pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                       STORAGECLASS   REASON   AGE
gstreamer-149                              10Gi       RWO            Recycle          Bound    149/gstreamer-claim                                                 177d

我认为它会以某种方式处理它，因为 pod 唯一需要做的就是连接到该 IP。

Answer 1

关于accessMode，尤其是NFS，这是一个非常具有误导性的概念。

在 Kubernetes Persistent Volume docs 中提到 NFS 支持所有类型的访问。 RWO、RXX 和 RWX。

但是accessMode 类似于matching criteria，与storage size 相同。在OpenShift Access Mode documentation中描述得更好

PersistentVolume 可以通过资源提供者支持的任何方式安装在主机上。提供程序具有不同的功能，每个 PV 的 access modes 都设置为该特定卷支持的特定模式。例如，NFS 可以支持多个read-write 客户端，但特定的 NFS PV 可能会在服务器上导出为只读。每个 PV 都有自己的一组访问模式来描述特定 PV 的功能。

声明与具有类似访问模式的卷相匹配。 仅有的两个匹配条件是访问模式和大小。声明的访问模式代表一个请求。因此，您可能会获得更多，但绝不会更少。 例如，如果声明请求 RWO，但唯一可用的卷是 NFS PV (RWO+ROX+RWX)，则声明将匹配 NFS，因为它支持 RWO。

总是首先尝试直接匹配。卷的模式必须匹配或包含比您请求的更多的模式。大小必须大于或等于预期值。如果 NFS 和 iSCSI 等两种类型的卷具有相同的访问模式集，则它们中的任何一种都可以将声明与这些模式相匹配。卷类型之间没有顺序，也无法选择一种类型而不是另一种类型。

将所有具有相同模式的卷分组，然后按大小从小到大排序。 binder 获取具有匹配模式的组，并按大小顺序遍历每个组，直到一个大小匹配。

在下一段中：

卷的AccessModes 是卷功能的描述符。它们不是强制约束。 存储提供者应对因资源的无效使用而导致的运行时错误负责。

例如，NFS 提供 ReadWriteOnce 访问模式。如果要使用卷的 ROX 功能，则必须将声明标记为只读。 提供程序中的错误在运行时显示为安装错误。

另一个例子是你可以选择几个AccessModes，因为它不是约束，而是一个匹配条件。

$ cat <<EOF | kubectl create -f -
> apiVersion: v1
> kind: PersistentVolumeClaim
> metadata:
>   name: exmaple-pvc
> spec:
>   accessModes:
>     - ReadOnlyMany
>     - ReadWriteMany
>     - ReadWriteOnce
>   resources:
>     requests:
>       storage: 1Gi
> EOF

或按照 GKE 示例：

$ cat <<EOF | kubectl create -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: exmaple-pvc-rwo-rom
spec:
  accessModes:
    - ReadOnlyMany
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
EOF               
persistentvolumeclaim/exmaple-pvc-rwo-rom created

PVC 输出

$ kubectl get pvc
NAME                  STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
exmaple-pvc           Pending                                                                        standard       2m18s
exmaple-pvc-rwo-rom   Bound     pvc-d704d346-42b3-4090-af96-aebeee3053f5   1Gi        RWO,ROX        standard       6s
persistentvolumeclaim/exmaple-pvc created

exmaple-pvc 处于 Pending 状态，默认 GKE GCEPersistentDisk 不支持 RreadWriteMany。

Warning  ProvisioningFailed  10s (x5 over 69s)  persistentvolume-controller  Failed to provision volume with StorageClass "standard": invalid AccessModes [ReadOnlyMany ReadWriteMany ReadWr
iteOnce]: only AccessModes [ReadWriteOnce ReadOnlyMany] are supported

但是第二个 pvc exmaple-pvc-rwo-rom 被创建了，你可以看到它有两种访问模式 RWO, ROX。

简而言之，accessMode 更像是对 PVC/PV 的要求 Bind。如果提供所有access modes 的NFS 与RWO 绑定，则它满足要求，但是它将像NFS 一样作为RWM 工作，提供该功能。

希望它回答清楚一点。

另外你可以查看其他StackOverflow threads regarding accessMode