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

我们在K8上运行的平台具有不同的组件。我们需要在这两个组件(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。

最佳答案

关于accessMode的概念非常误导，尤其是在NFS中。
在Kubernetes Persistent Volume docs中，提到NFS支持所有类型的Access。 RWO，RXX和RWX。
但是accessMode类似于matching criteria，与storage size相同。在OpenShift Access Mode documentation中有更好的描述




在下一段中:


另一个示例是，您可以选择一些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已创建，您可以看到它具有2种访问模式RWO, ROX。
简而言之，accessMode更像是对PVC / PV的要求Bind。如果提供所有NFS的access modes与RWO绑定(bind)，则它满足要求，但是它将像提供该功能的NFS一样用作RWM。
希望它的答案清除了一下。
此外，您可以检查其他StackOverflow threads regarding accessMode

关于kubernetes - 为什么ReadWriteOnce在不同的节点上工作？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/63412552/