Постоянное требование объема Kubernetes на неопределенный срок в состоянии ожидания

Я быстро понял, что PersistentVolumeClaim по умолчанию устанавливает для поля storageClassName значение standard, если не указано иное. Однако при создании PersistentVolume storageClassName не имеет значения по умолчанию, поэтому селектор не находит совпадения.

Для меня сработало следующее:

kind: PersistentVolume
apiVersion: v1
metadata:
  name: models-1-0-0
  labels:
    name: models-1-0-0
spec:
  capacity:
    storage: 200Gi
  storageClassName: standard
  accessModes:
    - ReadOnlyMany
  gcePersistentDisk:
    pdName: models-1-0-0
    fsType: ext4
    readOnly: true
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: models-1-0-0-claim
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 200Gi
  selector:
    matchLabels:
      name: models-1-0-0

С динамической подготовкой вам не нужно создавать PV и PVC по отдельности. В Kubernetes 1.6+ есть инициаторы по умолчанию для GKE и некоторых других облачных сред, которые должны позволить вам просто создать PVC, и он автоматически подготавливает для вас PV и базовый постоянный диск.

Дополнительные сведения о динамической подготовке см. В следующих разделах:

https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes/

Если вы используете Microk8s, вам необходимо включить хранилище, прежде чем вы сможете успешно запустить PersistentVolumeClaim.

Просто делать:

microk8s.enable storage

Вам нужно будет удалить развертывание и начать заново.

Вам также может потребоваться вручную удалить «ожидающие» PersistentVolumeClaims, потому что я обнаружил, что удаление диаграммы Helm, которая их создавала, не очищает PVC.

Вы можете сделать это, сначала найдя список имен:

kubectl get pvc --all-namespaces

затем удаляя каждое имя с помощью:

kubectl delete pvc name1 name2 etc...

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

Была та же проблема, но это была другая причина, поэтому я делюсь ею здесь, чтобы помочь сообществу.

Если вы удалили PersistentVolumeClaim, а затем воссоздали его снова с тем же определением, он навсегда останется в ожидании, почему?

persistentVolumeReclaimPolicy по умолчанию Retain в PersistentVolume. В случае, если мы удалили PersistentVolumeClaim, PersistentVolume все еще существует, и том считается освобожденным. Но он пока недоступен для другой претензии, потому что в томе остались данные предыдущего заявителя. поэтому вам необходимо вручную восстановить объем, выполнив следующие действия:

1. Удалите PersistentVolume (связанный базовый актив / ресурс хранилища, такой как EBS, GCE PD, Azure Disk и т. Д., НЕ будет удален, все еще существует)

2. (Необязательно) Вручную очистите данные на связанном ресурсе хранилища соответствующим образом.

3. (Необязательно) Вручную удалите связанный ресурс хранилища (EBS, GCE PD, Azure Disk и т. Д.)

Если вам по-прежнему нужны те же данные, вы можете пропустить очистку и удаление связанного актива хранилища (шаги 2 и 3 выше), поэтому просто воссоздайте новый PersistentVolume с тем же определением актива хранилища, тогда вы должны будете снова создать PersistentVolumeClaim.

И последнее, о чем следует упомянуть, Retain - не единственный вариант для persistentVolumeReclaimPolicy. Ниже приведены некоторые другие варианты, которые вам, возможно, придется использовать или попробовать в зависимости от сценариев использования:

Recycle: выполняет базовую очистку тома (например, rm -rf //*) - делает его снова доступным для новой заявки. Только NFS и HostPath поддерживают переработку.

Удалить: связанный ресурс хранения, например том AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder...etc, удаляется.

Для получения дополнительной информации проверьте документация kubernetes.

По-прежнему требуются дополнительные разъяснения или есть какие-либо вопросы, пожалуйста, не стесняйтесь оставлять комментарии, и я буду более чем счастлив уточнить и помочь.

Я столкнулся с той же проблемой и понимаю, что k8s действительно выполняет своевременное предоставление, т.е.

• Когда ПВХ создается, он остается в состоянии ОЖИДАНИЕ, и соответствующий PV не создается.
• Pvc и pv (том EBS) создаются только после того, как вы создали развертывание, в котором используется pvc.

Я использую EKS с версией kubernetes 1.16, и поведение контролируется Режим привязки тома StorageClass.

Я видел такое поведение в microk8s 1.14.1, когда два PersistentVolume имеют одинаковое значение для spec/hostPath/path, например.

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-name
  labels:
    type: local
    app: app
spec:
  storageClassName: standard
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/k8s-app-data"

Кажется, что microk8s основан на событиях (что не обязательно в кластере с одним узлом) и отбрасывает информацию о любых сбоях операций, что приводит к ненужной ужасной обратной связи почти для всех сбоев.

У меня была эта проблема с Helmchart воздушного потока apache (стабильная), помогла установка storageClass на azurefile. Что делать в таких случаях с облачными провайдерами? Просто найдите классы хранилища, которые поддерживают необходимый режим доступа. ReadWriteMany означает, что ОДНОВРЕМЕННО многие процессы будут читать и записывать в хранилище. В данном случае (лазурный) это azurefile.

path: /opt/airflow/logs

  ## configs for the logs PVC
  ##
  persistence:
    ## if a persistent volume is mounted at `logs.path`
    ##
    enabled: true

    ## the name of an existing PVC to use
    ##
    existingClaim: ""

    ## sub-path under `logs.persistence.existingClaim` to use
    ##
    subPath: ""

    ## the name of the StorageClass used by the PVC
    ##
    ## NOTE:
    ## - if set to "", then `PersistentVolumeClaim/spec.storageClassName` is omitted
    ## - if set to "-", then `PersistentVolumeClaim/spec.storageClassName` is set to ""
    ##
    storageClass: "azurefile"

    ## the access mode of the PVC
    ##
    ## WARNING:
    ## - must be: `ReadWriteMany`
    ##
    ## NOTE:
    ## - different StorageClass support different access modes:
    ##   https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
    ##
    accessMode: ReadWriteMany

    ## the size of PVC to request
    ##
    size: 1Gi

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

Я внес одно изменение в свой файл persistentvolume.yml и переместил конфигурацию PersistentVolumeClaim поверх файла, а затем PersistentVolume в качестве второй конфигурации в файле yml. Это устранило эту проблему.

Нам нужно убедиться, что сначала создается PersistentVolumeClaim, а затем создается PersistentVolume, чтобы решить эту проблему фазы «Ожидание».

Я отправляю этот ответ после нескольких тестов, надеясь, что он поможет кому-то, кто с ним борется.

Убедитесь, что на вашей виртуальной машине достаточно места на диске.