Kubernetes PersistentVolumes режимы доступа - PullRequest
2 голосов
/ 26 февраля 2020

В соответствии с официальной K8S документацией:

Доступны следующие режимы доступа:

ReadWriteOnce - том может монтироваться как чтение-запись одним узлом

ReadOnlyMany - том может быть подключен только для чтения многими узлами

ReadWriteMany - том может быть подключен для чтения и записи многими узлами

Я создал один постоянный том с режимом доступа RWO. Я применил PV C:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: readwriteonce-test
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: ""

и развертывание:

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: test-deployment
spec:
  selector:
    matchLabels:
      app: test-deployment
  replicas: 3
  template:
    metadata:
      labels:
        app: test-deployment
    spec:
      containers:
      - name: test-pod
        image: "gcr.io/google_containers/busybox:1.24"
        command:
          - "/bin/sh"
        args:
          - "-c"
          - "rm -R /data/*; while :; do ls /data/; name=$(date '+%s'); echo \"some data in file ${name}\" >> \"/data/${name}.txt\" ; sleep 10; cat \"/data/${name}.txt\"; done"
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /data
          name: test-volume
      restartPolicy: Always
      volumes:
      - name: test-volume
        persistentVolumeClaim:
          claimName: readwriteonce-test

PeristentVolume:

Name:            readwriteonce-test
Labels:          volume-name=readwriteonce-test
Annotations:     kubectl.kubernetes.io/last-applied-configuration:
                   {"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"volume-name":"readwriteonce-test"},"name":"readwriteo...
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    
Status:          Bound
Claim:           ***/readwriteonce-test
Reclaim Policy:  Retain
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        8Gi
Node Affinity:   <none>
Message:         
Source:
    Type:      NFS (an NFS mount that lasts the lifetime of a pod)
    Server:    ***.efs.eu-west-1.amazonaws.com
    Path:      /readwriteonce-test
    ReadOnly:  false
Events:        <none>

Вопрос:

Может ли кто-нибудь объяснить мне, почему нет ошибки в такой конфигурации? Как видите, каждый модуль был установлен на разных узлах. Каждый модуль может видеть файлы, созданные другими модулями.

снимок экрана

1 Ответ

0 голосов
/ 03 марта 2020

Я могу только подтвердить, что я использую те же наблюдения, что и вы, в моем тестовом кластере EKS при использовании постоянных томов на основе EFS, динамически создаваемых с помощью PV C request spe c: accessModes: ReadOnlyMany.

Как видно ниже, я могу одновременно записывать в один и тот же файл два разных модуля, запланированных на разных узлах:

Hello from test-deployment-6f954f9f67-ljghs at 1583239308 on ip-192-168-68-xyz.us-west-2.compute.internal node
Hello from test-deployment-6f954f9f67-bl99s at 1583239308 on ip-192-168-49-abc.us-west-2.compute.internal node

Вместо этого я предпочел бы ожидать такого же поведения *, как в случае другие типы PV, поддерживающие все типы режимов доступа (RWO, RWX, ROX):

Warning  FailedAttachVolume  103s  attachdetach-controller  Multi-Attach error for volume "pvc-badb4724-5d5a-11ea-8395-42010aa80131"

 Multi-Attach error for volume "pvc-badb4724-5d5a-11ea-8395-42010aa80131" Volume is already used by pod(s) test-deployment-xyz-...

* происходит, когда планировщик пытается запланировать вторую реплику модуля, используя тот же PV.

Я думаю, что это лежит в основе хранилища на основе NFS, которое является базовым типом хранилища для EFS-Provider .

Похоже, у нас не единственные проблемы с пониманием официальной документации в этом отношении, пожалуйста, проверьте эти открытые проблемы github: # 18714 , # 60903 .

...