Question

我们在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。

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）具有相同的访问模式集，则它们中的任何一种都可以将声明与这些模式匹配。卷的类型之间没有顺序，也无法选择一种类型。

将具有相同模式的所有卷分组，然后按大小（从最小到最大）进行排序。活页夹使组具有匹配模式，并按大小顺序对每个模式进行迭代，直到一个大小匹配为止。

在下一段中：

卷的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，您可以看到它具有2种访问模式RWO, ROX。

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

希望它的答案可以清除。

此外，您可以检查其他StackOverflow threads regarding accessMode

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

更新

1 个答案: