kubernetes - 为什么可以在持久卷上设置多个访问模式？

Question

例如在以下示例中:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: exmaple-pvc
spec:
  accessModes:
    - ReadOnlyMany
    - ReadWriteMany
  storageClassName: standard
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi

为什么这是允许的？在这种情况下，卷的实际行为是什么？只读？读和写？

Answer 1

能够充分理解为什么在yaml的特定领域使用某种结构。定义，首先我们需要了解这个特定领域的目的。我们需要问它是做什么的，在这个特定的中它的功能是什么？ kubernetes api 资源 .

我努力寻找 accessModes 的正确解释在 PersistentVolumeClaim我必须承认what I found在 Kubernetes 官方文档 没有满足我:

A PersistentVolume can be mounted on a host in any way supported by the resource provider. As shown in the table below, providers will have different capabilities and each PV’s access modes are set to the specific modes supported by that particular volume. For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV’s capabilities.

幸运的是，这次我设法在 openshift documentation 中找到了对这个主题的非常好的解释。 .我们可以在那里阅读:

Claims are matched to volumes with similar access modes. The only two matching criteria are access modes and size. A claim’s access modes represent a request. Therefore, you might be granted more, but never less. For example, if a claim requests RWO, but the only volume available is an NFS PV (RWO+ROX+RWX), the claim would then match NFS because it supports RWO.

Direct matches are always attempted first. The volume’s modes must match or contain more modes than you requested. The size must be greater than or equal to what is expected. If two types of volumes, such as NFS and iSCSI, have the same set of access modes, either of them can match a claim with those modes. There is no ordering between types of volumes and no way to choose one type over another.

All volumes with the same modes are grouped, and then sorted by size, smallest to largest. The binder gets the group with matching modes and iterates over each, in size order, until one size matches.

现在可能是最重要的部分:

A volume’s AccessModes are descriptors of the volume’s capabilities. They are not enforced constraints. The storage provider is responsible for runtime errors resulting from invalid use of the resource.

我把这部分强调为 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 ，它也将可供使用。

回答您的特定问题...

Why is this allowed? What is the actual behavior of the volume in this case? Read only? Read and write?

它根本没有定义卷的行为。音量将根据其 运行能力 (我们没有定义它们，它们是预先强加的，是存储规范的一部分)。换句话说，我们将能够在我们的 Pods 中使用它。以所有可能的方式使用它。

假设我们的 standard存储供应商，在 的情况下GKE 恰好是 Google Compute Engine 永久磁盘 :

$ kubectl get storageclass
NAME                 PROVISIONER            AGE
standard (default)   kubernetes.io/gce-pd   10d

目前支持两个 AccessModes :

ReadWriteOnce

ReadOnlyMany

因此，无论我们在声明中指定什么，我们都可以使用它们，例如这边走:

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

回到你在标题中提出的问题:

Why can you set multiple accessModes on a persistent volume?

答案是:您根本无法设置它们，因为它们已经由存储提供商设置，您只能通过这种方式请求您想要的存储、它必须满足的要求以及这些要求之一是它支持的访问模式。

基本上通过键入:

spec:
  accessModes:
    - ReadOnlyMany
    - ReadWriteOnce

在我们的 PersistentVolulmeClaim我们说的定义:

“嘿!存储提供商!给我一个支持这组 accessModes 的卷。我不在乎它是否支持任何其他人，比如 ReadWriteMany，因为我不需要它们。给我一些满足我要求的东西!”

我相信这里不需要进一步解释为什么使用数组。