Что делать с выпущенным постоянным томом? - PullRequest
0 голосов
/ 03 июня 2018

TL; DR.Я заблудился о том, как получить доступ к данным после удаления PVC, а также о том, почему PV не исчезнет после удаления PVC.

Шаги, которые я предпринимаю:

  1. создал диск в GCE вручную:

    gcloud compute disks create --size 5Gi disk-for-rabbitmq --zone europe-west1-b
    
  2. run:

    kubectl apply -f /tmp/pv-and-pvc.yaml
    

    со следующей конфигурацией:

    # /tmp/pv-and-pvc.yaml
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv-for-rabbitmq
    spec:
      accessModes:
      - ReadWriteOnce
      capacity:
        storage: 5Gi
      gcePersistentDisk:
        fsType: ext4
        pdName: disk-for-rabbitmq
      persistentVolumeReclaimPolicy: Delete
      storageClassName: standard
    ---
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc-for-rabbitmq
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi
      storageClassName: standard
      volumeName: pv-for-rabbitmq
    
  3. удалил PVC вручную (на высоком уровне: здесь я имитирую катастрофический сценарий, такой как случайное удаление или неправильная конфигурация helm выпуска):

    kubectl delete pvc pvc-for-rabbitmq
    

На этом этапе я вижу следующее:

$ kubectl get pv
NAME              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                      STORAGECLASS   REASON   AGE
pv-for-rabbitmq   5Gi        RWO            Delete           Released   staging/pvc-for-rabbitmq   standard                8m
$

Дополнительный вопрос, просто улучшите мое понимание: почему PV все еще там, хотя у него есть политика восстановленияDelete? Разве это не то, что документы говорят о политике восстановления Delete?

Теперь, если я попытаюсь воссоздать PVCчтобы восстановить доступ к данным в PV:

$ kubectl apply -f /tmp/pv-and-pvc.yaml
persistentvolume "pv-for-rabbitmq" configured
persistentvolumeclaim "pvc-for-rabbitmq" created
$

Я все еще получаю это на pv с, например, PV застрял в Released состоянии:

$
kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                             STORAGECLASS   REASON    AGE
pv-for-rabbitmq                            5Gi        RWO            Delete           Released   staging/pvc-for-rabbitmq          standard                 15m
$

..И я получаю это за pvc с:

$
kubectl get pvc
NAME               STATUS    VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-for-rabbitmq   Pending   pv-for-rabbitmq   0                         standard       1m
$

Похоже, мой PV застрял в состоянии Released, и PVC не может получить доступ к PV, который не находится в состоянии Available.

Итак, почему те же PV и PVC не могут снова быть друзьями? Как сделать PVC для восстановления доступа к данным в существующем PV?

Ответы [ 3 ]

0 голосов
/ 16 июня 2018

Вы работаете в типичном заблуждении, считая, что PV и PVC более связаны, чем они есть.

Постоянный том : В K8s этот ресурс имеет множество опций.Например, hostPath зарезервирует указанный размер из узла, на котором запущен модуль, и сопоставит его с желаемым путем в обоих;ваш модуль и ваш узел.

Заявка о постоянном объеме : PVC, особенно в GKE, создаст физический постоянный диск на Google Cloud Platform и подключит его к узлу, на котором находится модульработает, как вторичный диск.Таким образом, претензия в большей степени относится к облачному провайдеру.

Примечание: вам не нужно вручную создавать диск.Просто создайте заявку и узнайте, что происходит.Вам нужно будет подождать некоторое время, но в итоге статус должен быть BOUND, что означает, что постоянный диск создан, подключен и готов к использованию.

Если вы выполните df -h, онбудет отображаться как подключенное устройство, а также будет отображаться с kubectl get pv, так как в итоге это постоянный том

Об удалении объектов.Когда вы удаляете PV или PVC, ничего не происходит.Вы все еще можете попасть в капсулу и перейти на путь, который был нанесен на карту.Нет проблем.Поскольку он не удаляется, модуль все еще имеет к нему доступ.Теперь, если ваш модуль выйдет из строя и восстановится заново, без этого PV или PVC, вы получите ошибку.

0 голосов
/ 15 августа 2019

Официальная документация имеет ответ, надеюсь, она поможет другим, ищущим то же самое (https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)

Сохранять. Политика возврата позволяет сохранять ресурс вручную. Когда PersistentVolumeClaim удален, PersistentVolume все еще существует итом считается «освобожденным». Но он еще не доступен для другой заявки, поскольку данные предыдущего заявителя остаются на томе. Администратор может вручную восстановить том, выполнив следующие действия.

  1. Удаление PersistentVolumeСвязанный ресурс хранения во внешней инфраструктуре (например, том AWS EBS, GCE PD, том Azure Disk или Cinder) все еще существует после удаления PV.
  2. Вручную очистите данные соответствующего актива хранения соответствующим образом..
  3. Удалите связанный ресурс хранения вручную или, если вы хотите повторно использовать этот же ресурс хранения, создайте новый PersistentVolume с определением ресурса хранения.
0 голосов
/ 16 июня 2018

Фраза, которая говорит, что Pods потребляют ресурсы узла, а PVC потребляют ресурсы PV, могут быть полезны для полного понимания теории и дружбы между PV и PVC.

Я попытался полностью воспроизвести поведение, отмеченное с использованиемпредоставил файл YAML и не удалось, и он вернул ожидаемый результат.Следовательно, прежде чем предоставить какие-либо дополнительные подробности, вот краткий обзор моей репродукции.

Шаг 1: Создание PD в зоне Европа-запад1

sunny@dev-lab:~$ gcloud compute disks create --size 5Gi disk-for-rabbitmq --zone europe-west1-b

WARNING: You have selected a disk size of under [200GB]. This may result in poor I/O 
performance. For more information, see: 

NAME               ZONE            SIZE_GB  TYPE         STATUS
disk-for-rabbitmq  europe-west1-b  5        pd-standard  READY

Шаг 2: Создание PV и PVC с использованием файла проекта YAML

sunny@dev-lab:~$  kubectl apply -f pv-and-pvc.yaml

persistentvolume "pv-for-rabbitmq" created
persistentvolumeclaim "pvc-for-rabbitmq" created

Шаг 3: Список всех доступных PVC

sunny@dev-lab:~$ kubectl get pvc
NAME               STATUS    VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-for-rabbitmq   Bound     pv-for-rabbitmq   5Gi        RWO            standard       16s

Шаг 4: Список всех доступных PV

sunny@dev-lab:~$ kubectl get pv
NAME              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                      STORAGECLASS   REASON    AGE
pv-for-rabbitmq   5Gi        RWO            Delete           Bound     default/pvc-for-rabbitmq   standard                 28s

Шаг 5: Удалите PVC и проверьте результат

sunny@dev-lab:~$  kubectl delete pvc pvc-for-rabbitmq
persistentvolumeclaim "pvc-for-rabbitmq" deleted

sunny@dev-lab:~$  kubectl get pv

Ресурсы не найдены.

sunny@dev-lab:~$  kubectl get pvc

Ресурсы не найдены.

sunny@dev-lab:~$  kubectl describe pvc-for-rabbitmq

на сервере нет типа ресурса "pvc-for-rabbitmq"

Asна ваш вопрос

Дополнительный вопрос, просто улучшите мое понимание: почему PV все еще там, даже если для него установлена ​​политика удаления , установленная на Delete? Разве это не то, что документы говорят о политике удаления возврата?

Вы абсолютно правы, согласно документации, когда пользователь покончит со своим томом, ониможно удалить объекты PVC из API, которыйпозволяет восстановление ресурса.Политика восстановления для PersistentVolume сообщает кластеру, что делать с томом после того, как он выпустил свою заявку.В вашем YAML было установлено:

Reclaim Policy:  Delete

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

Почему его не удалили? Единственное, о чем я мог подумать, - это, может быть, о том, что PV каким-то образом все еще востребован, что, вероятно, является результатом того, что PVC не был успешно удален, поскольку его емкость показывает «0», и чтобы исправить это, вам нужно будет удалить POD.В качестве альтернативы вы можете использовать команду $ kubectl describe pvc, чтобы узнать, почему PVC все еще находится в состоянии ожидания.

И на вопрос Как мне сделать PVC для восстановления доступа к данным в существующем PV?

Это невозможно, потому чтостатуса политики возврата, т. е. Reclaim Policy: Delete, чтобы сделать это возможным, вместо этого вам потребуется использовать опцию «Сохранять» в соответствии с документацией

Для проверки теории, что вы можете удалить PVCи сохраните диск, выполните следующие действия:

  • Измените политику восстановления на Сохранение
  • Удалите PVC
  • Удалите PV

А затем проверьте, был ли диск сохранен.

...