#kubernetes
#kubernetes
Вопрос:
Я создаю следующий PersistentVolume
cat mypv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: myvolume
labels:
type: local
spec:
storageClassName: normal
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
- ReadWriteMany
hostPath:
path: "/etc/foo"
Однако после создания
k create -f mypv.yaml
persistentvolume/myvolume created
Я понял, что нет normal StorageClass доступных.
k get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
standard (default) k8s.io/minikube-hostpath Delete Immediate false 8d
Итак, как получилось PersistentVolume , что создание с несуществующим классом хранения завершилось успешно?
Ответ №1:
Обратите внимание, что класс хранилища вызывается, когда том необходимо подготовить динамически. Он хорошо работает с облачными провайдерами, такими как GCD, AWS, Azure.
С другой стороны, тома hostPath подготавливаются статически. Класс хранилища игнорируется в этих определениях PV. Следовательно, в вашем случае pv был создан без ошибок. pv привязан к хранилищу на хост-компьютере.
Перейдите по ссылке ниже для получения справки -> https://docs.openshift.com/container-platform/4.2/storage/persistent_storage/persistent-storage-hostpath.html
Ответ №2:
В hostPath случае storageClassName , если на самом деле не игнорируется.
Он по-прежнему используется для привязки к ПВХ.
В файле конфигурации указано, что том находится в /mnt/data на узле кластера. <…>
Он определяет руководство по именованию класса StorageClass для PersistentVolume, которое будет использоваться для привязки запросов PersistentVolumeClaim к этому PersistentVolume.
А также он может быть использован для динамической подготовки, в случае, если кластер предоставляет dynamic provisioner для hostPath (как это делает Minikube).
Ответ №3:
Если у вас включена динамическая подготовка, вы можете создать класс хранения по требованию. MiniKube имеет собственную динамическую инициализацию, которая использует путь к хосту