Kubernetes автоматически добавляет storageClassName в PVC - PullRequest
Новая
       102

Kubernetes автоматически добавляет storageClassName в PVC

1 голос
/ 25 мая 2020

У меня есть контрольная таблица, содержащая PV и PV C для монтирования томов NFS, и это прекрасно работает. Мне нужно установить эту диаграмму управления на новый кластер с очень строгими и ограниченными мерами безопасности, и я также вижу, что мои модули ожидают рассмотрения, потому что они не могут смонтировать NFS.

После некоторых исследований я обнаружил что проблема в том, что PV C и PV имеют разные storageClassName: 

kubectl -n 57 describe pvc gstreamer-claim


Events:
  Type       Reason             Age                 From                         Message
  ----       ------             ----                ----                         -------
  Warning    VolumeMismatch     98s (x83 over 21m)  persistentvolume-controller  Cannot bind to requested volume "gstreamer-57": storageClassName does not match

Это очень странно, поскольку PV C в моей диаграмме управления вообще не имеет никакого storageClassName: PV C: 

- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: gstreamer-claim
    namespace: {{ .Release.Namespace }}
  spec:
    volumeName: gstreamer-{{ .Release.Namespace }}
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi

PV: 

- apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: gstreamer-{{ .Release.Namespace }}
  spec:
    capacity:
      storage: 10Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Recycle
    mountOptions:
      - hard
      - nfsvers=4.1
    nfs:
      server: {{ .Values.global.nfsserver }}
      path: /var/nfs/general/gstreamer-{{ .Release.Namespace }}

Я попытался отредактировать PV C, но не смог его изменить.

Почему это происходит ? Может ли это быть связано с безопасностью кластера? Как это исправить?

Обновление

Информация о классе хранения: 

kubectl -n 57 get sc
NAME                      PROVISIONER                                       AGE
local-storage (default)   kubernetes.io/no-provisioner                      54d
nfs-client                cluster.local/nfs-client-nfs-client-provisioner   43m


kubectl -n 57 get sc local-storage -o yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"},"name":"local-storage"},"provisioner":"kubernetes.io/no-provisioner","volumeBindingMode":"WaitForFirstConsumer"}
    storageclass.kubernetes.io/is-default-class: "true"
  creationTimestamp: "2020-03-31T20:46:39Z"
  name: local-storage
  resourceVersion: "458"
  selfLink: /apis/storage.k8s.io/v1/storageclasses/local-storage
  uid: b8352eb1-7390-11ea-84a7-fa163e393634
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

1 Ответ

2 голосов
/ 25 мая 2020

При настройке Dynami c вам не нужно явно создавать PV. Создайте PV C с классом хранения nfs-client. 

apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: gstreamer-claim
    namespace: {{ .Release.Namespace }}
  spec:
    volumeName: gstreamer-{{ .Release.Namespace }}
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
    storageClassName: nfs-client

Другой вариант - сделать nfs-client в качестве класса хранения по умолчанию, и не нужно будет указывать storageClassName: nfs-client в PV C.

...