能够充分理解为什么在特定领域使用某种结构yaml定义，首先我们需要了解这个特定字段的用途。我们需要问它的用途是什么，它在这个特定的环境中的功能是什么？kubernetes api 资源.
我很难找到正确的解释accessModes in PersistentVolumeClaim我必须承认我发现了什么 in Kubernetes 官方文档没有让我满意：
A PersistentVolume可以以任何支持的方式安装在主机上
资源提供者。如下表所示，提供商将
具有不同的功能，每个PV的访问模式设置为
该特定卷支持的特定模式。例如，NFS
可以支持多个读/写客户端，但特定的 NFS PV 可能
以只读方式导出到服务器上。每个 PV 都有自己的一组
描述特定 PV 功能的访问模式。
幸运的是，这次我设法找到了关于这个主题的非常好的解释OpenShift 文档。我们可以在那里读到：
声明与具有相似访问模式的卷相匹配。仅有的两个
匹配标准是访问模式和大小。索赔的访问模式
代表一个请求。因此，你可能会获得更多，但永远不会
较少的。例如，如果索赔请求 RWO，但唯一的卷
可用的是 NFS PV (RWO+ROX+RWX)，则声明将与 NFS 匹配
因为它支持RWO。
总是首先尝试直接匹配。音量模式必须
匹配或包含比您要求的更多的模式。尺寸必须是
大于或等于预期值。如果有两种类型的卷，
例如 NFS 和 iSCSI，具有相同的访问模式集，其中之一
他们可以将声明与这些模式相匹配。之间没有顺序
卷的类型，并且无法选择一种类型而不是另一种类型。
将所有具有相同模式的卷分组，然后按大小排序，
最小到最大。活页夹获取具有匹配模式的组并
按大小顺序迭代每个，直到一个大小匹配。
现在可能是最重要的部分：
一卷的AccessModes是卷的描述符
能力。它们不是强制的约束。存储提供商
负责因无效使用而导致的运行时错误
资源。
我强调这部分为AccessModes很容易被误解。让我们看一下例子：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: exmaple-pvc-2
spec:
accessModes:
- ReadOnlyMany
storageClassName: standard
volumeMode: Filesystem
resources:
requests:
storage: 1Gi
事实上，我们在我们的PersistentVolumeClaim仅定义ReadOnlyMany访问模式并不意味着它不能用于其他accessModes由我们的存储提供商支持。重要的是要理解，我们不能在这里对我们如何使用所请求的存储设置任何限制Pods。如果我们的存储提供商，隐藏在我们的背后standard存储类，还支持ReadWriteOnce，它也将可供使用。
回答你的具体问题...
为什么这是允许的？此卷的实际行为是什么
案件？只读？读和写？
它根本不定义卷的行为。音量将根据其表现能力（我们没有定义它们，它们是预先强加的，作为存储规范的一部分）。换句话说，我们将能够在我们的Pods以所有可能的方式，允许使用它。
就说我们的standard存储供应商，在这种情况下GKE恰好是Google 计算引擎永久磁盘:
$ kubectl get storageclass
NAME PROVISIONER AGE
standard (default) kubernetes.io/gce-pd 10d
目前支持两个AccessModes:
ReadWriteOnceReadOnlyMany
因此，无论我们在声明中指定什么，我们都可以使用它们，例如这边走：
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
labels:
app: my-app
spec:
replicas: 1
selector:
matchLabels:
app: debian
template:
metadata:
labels:
app: debian
spec:
containers:
- name: debian
image: debian
command: ['sh', '-c', 'sleep 3600']
volumeMounts:
- mountPath: "/mnt"
name: my-volume
readOnly: true
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: example-pvc-2
initContainers:
- name: init-myservice
image: busybox
command: ['sh', '-c', 'echo "Content of my file" > /mnt/my_file']
volumeMounts:
- mountPath: "/mnt"
name: my-volume
在上面的例子中两种功能都被使用。首先我们的卷安装在rw模式由init container它会保存一些文件，然后将其安装到main container作为只读文件系统。即使我们在我们的中指定，我们仍然能够做到这一点PersistentVolumeClaim只有一种访问模式：
spec:
accessModes:
- ReadOnlyMany
回到你在标题中提出的问题：
为什么可以在持久卷上设置多个访问模式？
答案是：您根本无法设置它们，因为它们已经由存储提供商设置，您只能通过这种方式请求您想要什么存储，它必须满足什么要求，以及这些要求之一是它支持的访问模式。
基本上通过输入：
spec:
accessModes:
- ReadOnlyMany
- ReadWriteOnce
in our PersistentVolulmeClaim我们说的定义：
“嘿！存储提供商！给我一个支持这套的卷accessModes。我不在乎它是否支持其他任何人，比如ReadWriteMany，因为我不需要它们。给我一个符合我要求的东西吧！”
我相信进一步解释为什么an array这里使用的是不需要的。
