Kubernetes NFS Persistent Volumes - несколько претензий на тот же объем? Претензия приостановлена?

Случай использования:

У меня есть каталог NFS, и я хочу использовать его для сохранения данных для нескольких развертываний и модулей.

Я создал PersistentVolume:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: http://mynfs.com
    path: /server/mount/point

Я хочу, чтобы несколько развертываний могли использовать этот PersistentVolume, поэтому я понимаю, что мне нужно создать несколько PersistentVolumeClaims которые все будут указывать на этот PersistentVolume.

kind: PersistentVolumeClaim
apiVersion: v1
metaData:
  name: nfs-pvc-1
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Mi

Я верю в это, чтобы создать заявку размером 50 МБ на PersistentVolume. Когда я запускаю kubectl get pvc, я вижу:

NAME        STATUS     VOLUME    CAPACITY    ACCESSMODES   AGE
nfs-pvc-1   Bound      nfs-pv    10Gi        RWX           35s

Я не понимаю, почему я вижу емкость 10Gi, а не 50Mi.

Когда я затем изменить PersistentVolumeClaim YAML развертывания для создания ПВХ с именем nfs-pvc-2 я получаю это:

NAME        STATUS     VOLUME    CAPACITY    ACCESSMODES   AGE
nfs-pvc-1   Bound      nfs-pv    10Gi        RWX           35s
nfs-pvc-2   Pending                                        10s

PVC2 никогда не связывается с PV. Это ожидаемое поведение? Могу ли я иметь несколько PVC, указывающих на один и тот же PV?

Когда я удаляю nfs-pvc-1, я вижу то же самое:

NAME        STATUS     VOLUME    CAPACITY    ACCESSMODES   AGE
nfs-pvc-2   Pending                                        10s

Опять же, это нормально?

Как правильно использовать/повторно использовать общий ресурс NFS между несколькими развертываниями/модулями?

Ответы

Ответ 1

По сути, вы не можете делать то, что хотите, так как отношения PVC & lt; → PV один на один.

Если NFS - единственное доступное хранилище, для которого требуется несколько PV/PVC для одного экспорта nfs, используйте динамическую инициализацию и класс хранилища по умолчанию.

Это еще не в официальных K8s, но этот находится в инкубаторе, и я попробовал, и это работает хорошо: https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client

Это значительно упростит предоставление томов, так как вам нужно только позаботиться о PVC, и PV будет создан в качестве каталога на указанном вами сервере экспорта/сервера nfs.

Ответ 2

От: https://docs.openshift.org/latest/install_config/storage_examples/shared_storage.html

Как упомянул Baroudi Safwen, вы не можете привязать два пвх к одному и тому же пвх, но вы можете использовать один пвх в двух разных модулях.

volumes:
- name: nfsvol-2
  persistentVolumeClaim:
    claimName: nfs-pvc-1 <-- USE THIS ONE IN BOTH PODS

Ответ 3

Постоянное требование тома связано исключительно с постоянным томом.
Вы не можете привязать 2 пвх к тому же пв.

Я думаю, вы заинтересованы в динамическом обеспечении. Я столкнулся с этой проблемой при развертывании наборов состояний, которые требуют динамической подготовки для модулей. Таким образом, вам необходимо развернуть в вашем кластере провайдера NFS, у провайдера NFS (pod) будет доступ к папке NFS (hostpath), и каждый раз, когда модуль запрашивает том, провайдер NFS будет монтировать его в каталог NFS от имени стручка.
Вот репозиторий github для его развертывания:
https://github.com/kubernetes-incubator/external-storage/tree/master/nfs/deploy/kubernetes
Но вы должны быть осторожны, вы должны убедиться, что поставщик nfs всегда работает на том же компьютере, где у вас есть папка NFS, используя селектор узлов, поскольку у вас том типа hostpath.

Ответ 4

несколько моментов о динамическом обеспечении.

использование динамической инициализации nfs не позволяет вам изменять любой из параметров монтирования nfs по умолчанию. На моей платформе это использует rsize/wsize 1M. это может вызвать огромные проблемы в некоторых приложениях, использующих небольшие файлы или блокировку чтения. (Я только что разобрался с этой проблемой)

Динамический это отличный вариант, если он соответствует вашим потребностям. Теперь я застрял с созданием 250 пар pv/pvc для моего приложения, которое обрабатывалось динамически из-за отношения 1-1.