Постоянный объем не соответствует заявке - PullRequest
0 голосов
/ 20 апреля 2019

Я создал простой локальный том хранения. Примерно так:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: vol1
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /srv/volumes/vol1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - my-node

Я создаю претензию:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage:1Gi

По неизвестной причине они не получают спичек. Что я делаю не так?

Ответы [ 3 ]

1 голос
/ 20 апреля 2019

Вы должны указать volumeName в вашем PVC, чтобы привязать это конкретно к PV, который вы только что создали, так:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeName: "vol1"
  resources:
    requests:
      storage:1Gi

Кроме того, если вы укажите storageClassName в вашем PVC, ваш PVC будеттакже связывайтесь с PV, соответствующим этой спецификации (хотя это не гарантирует, что он будет связан с вашим PV "vol1", если для этого класса хранения более 1 PV).

Надеюсь, это поможет!

1 голос
/ 26 апреля 2019

О локальном хранилище стоит отметить, что:

Использование локального хранилища связывает ваше приложение с этим конкретным узлом, делая ваше приложение сложнее планировать. Если этот узел или локальный том сталкивается с ошибкой и становится недоступным, тогда этот модуль также становится недоступным. Кроме того, многие облачные провайдеры не обеспечить обширные гарантии долговечности данных для локального хранения, так что вы может потерять все ваши данные в определенных сценариях.

Это для Kubernetes 1.10 . В Кубернетесе 1,14 локальные постоянные объемы стали GA.

Вы опубликовали ответ, который требуется пользователю. Просто чтобы уточнить пользователя, которого вы имели в виду, это потребитель, такой как модуль, развертывание, набор состояний и т. Д. Таким образом, использование простого определения pod сделает ваш PV связанным:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

Теперь проблема возникает, когда вы удаляете модуль и пытаетесь запустить другой. В этом случае, если вы или кто-то еще ищете решение, оно было описано в этой проблеме GitHub .

Надеюсь, это прояснит ситуацию.

0 голосов
/ 20 апреля 2019

Я понял это.Мне просто нужен был пользователь.Пока у меня был пользователь, все работало отлично.

...