kubernetes - 为什么要在一个持久卷上设置多个accessModes？

例如下面的示例:

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

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

最佳答案

为了能够完全理解为什么在yaml定义的特定字段中使用某种结构，首先我们需要了解该特定字段的目的。我们需要询问它的用途，在此特定 kubernetes api-resource 中的功能是什么。

我很难在accessModes中找到PersistentVolumeClaim的正确解释，我必须承认官方kubernetes文档中的what I found不满足我的要求:

幸运的是，这次我在openshift documentation中找到了关于此主题的很好的解释。我们可以在这里阅读:

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

我强调了这一部分，因为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 Compute Engine永久磁盘:

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

目前支持两个AccessModes:

ReadWriteOnce

ReadOnlyMany

因此，无论我们在 claim 中指定的内容如何，例如，这条路:

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

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

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

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

关于kubernetes - 为什么要在一个持久卷上设置多个accessModes？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/60248790/