Как вручную восстановить PV

Question

Как вручную восстановить PV

Согласно официальным документам https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/ с политикой "Сохранить", PV можно восстановить вручную. Что это на самом деле означает, и есть ли инструмент, с помощью которого я могу прочитать данные с этого "сохраненного" PV и записать их на другой PV, или это означает, что вы можете смонтировать руководство по тому, чтобы получить доступ?

19

kubernetes persistent-volumes pv

Источник

user8066674 16 апр '18 в 13:53

4 ответа

Другие вопросы по тегам kubernetes persistent-volumes pv

user3514300 08 апр '19 в 07:33 2019-04-08 07:33 · Answer 1 · 2019-04-08 07:33

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

Убедитесь, что PV находится в освобожденном состоянии.

 ➜  ~ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                     STORAGECLASS   REASON   AGE
pvc-eae6acda-59c7-11e9-ab12-06151ee9837e   16Gi       RWO            Retain           Released   default/dhanvi-test-pvc   gp2                     52m

Редактировать PV (kubectl edit pv pvc-eae6acda-59c7-11e9-ab12-06151ee9837e) и удалите часть spec.claimRef. Претензия в отношении PV будет отклонена, как показано ниже.

 ➜  ~ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pvc-eae6acda-59c7-11e9-ab12-06151ee9837e   16Gi       RWO            Retain           Available           gp2                     57m

Затем подайте заявку на использование PV, как показано ниже

---

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dhanvi-test-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 16Gi
  volumeName: "pvc-eae6acda-59c7-11e9-ab12-06151ee9837e"

Может использоваться в стручках, как показано ниже.

volumes:
- name: dhanvi-test-pv
  persistentVolumeClaim:
    claimName: dhanvi-test-pvc

user3532095 04 ноя '20 в 06:17 2020-11-04 06:17 · Answer 2 · 2020-11-04 06:17

Как сказано в ответе Туммалы Дханви, spec.claimRefраздел, которым нужно заняться. При удалении всего spec.claimRefможет быть полезно, если у вас есть только один PV, это будет очень неприятно, если у вас есть несколько PV, которые нужно "спасти".

Первый шаг - убедиться, что у PV есть Retainвернуть политику перед удалением PVC. Вы можете редактировать или исправлять PV, чтобы добиться этого.

kubectl edit pv pvc-73e9252b-67ed-4350-bed0-7f27c92ce826
- Найди spec.persistentVolumeReclaimPolicy ключ
- ввод Retain за его ценность
- сохранить и выйти
или в одной команде kubectl patch pv pvc-73e9252b-67ed-4350-bed0-7f27c92ce826 -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"

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

Чтобы успешно повторно смонтировать PV в желаемый модуль, вам нужно еще раз отредактировать конфигурацию PV, на этот раз spec.claimRefраздел. Но не удаляйте весь раздел. Вместо этого удалите только resourceVersion и uidключи. Результирующий раздел будет выглядеть примерно так

...
  capacity:
    storage: 16Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: database
    namespace: staging
  nodeAffinity:
...

Повторите это для всех ваших PV и их статуса в kubectl get pv выход будет Availableпотом. Оставив spec.claimRef.name и spec.claimRef.namespace ключи не повреждены, мы позаботились о том, чтобы новый ПВХ с соответствующим spec (staging/database в моем случае) будет привязан к точному PV, который должен быть.

Кроме того, убедитесь, что в вашем новом заявлении не указана большая емкость хранилища, чем на самом деле имеет PV(кажется, что емкость новых требований может быть меньше, чем емкость существующего PV). Если новый PVC требует большего хранилища, вместо него будет создан новый PV. Лучше оставить его таким же.

Чтобы отвлечься: если storageClassвы используете позволяет изменять размер тома, вы можете изменить его размер позже; здесь объясняется, как: https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/

Мой опыт с этим был довольно напряженным. У меня было 6 клипов, спасибо RetainРежим. По какой-то причине новое развертывание застряло, два модуля просто не хотели завершать работу. В конце концов я удалил все развертывание (используя helm), перезапустив узлы кластера, а затем заново развернув. Это привело к созданию 6 новых клипов!

Я нашел эту тему и удалил spec.claimRefвсех клипов. Удаление и развертывание установки снова привело к повторному использованию PV, но они не были смонтированы там, где они должны были, данных не было. После хорошего копания я понял, что database том был смонтирован на модуле RabbitMQ, mongodb был установлен в ElasticSearch и т. д.

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

Надеюсь, это избавит от серьезных головных болей!

user3172693 17 апр '18 в 14:37 2018-04-17 14:37 · Answer 3 · 2018-04-17 14:37

Существует три политики возврата, которые определяют, что происходит с постоянным томом после удаления заявки на связанный том.

сохранить
удалять
Рециркулировать

Удалить означает, что постоянный том, а также связанный ресурс хранения во внешней инфраструктуре удаляются.

Recycle очистит том rm -rf /thevolume/*, после чего он будет доступен для новых постоянных утверждений о томах.

Сохранять оставляет постоянный том в освобожденном состоянии, что не позволяет новым постоянным томам требовать его восстановления. Весь процесс восстановления является ручным. Вы должны удалить постоянный том самостоятельно. Вы можете сделать резервную копию данных из хранилища и впоследствии удалить их. Затем вы можете удалить ресурс хранения или создать новый постоянный том для этого ресурса.

Если вы хотите записать данные на другой постоянный том, используя Kubernetes, вы можете использовать Job для копирования данных.

В этом случае убедитесь, что вы используете режимы доступа к постоянным томам ROX - ReadOnlyMany или RWX - ReadWriteMany и запускаете задание, в котором выполняется контейнер, который запрашивает резервное копирование постоянного тома с помощью селектора и запрашивает другой целевой том резервной копии. Затем скопируйте данные через контейнер.

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

Оба варианта, которые я описал, являются более или менее стратегией резервного копирования вручную. Если вы стремитесь к более сложной стратегии резервного копирования для производственных рабочих нагрузок, вы можете взглянуть на Stash - Резервное копирование дисков для рабочих нагрузок в Kubernetes.

user428173 30 мар '21 в 14:44 2021-03-30 14:44 · Answer 4 · 2021-03-30 14:44

Я нашел этот вопрос по несколько иным причинам, чем существующий адрес ответов, поэтому я взвешу.

В моем случае у меня был самоуправляемый кластер Microk8s для целей разработки и тестирования с ручным локальным хранилищем (смонтированный путь на одном из узлов), например:

      apiVersion: v1
kind: PersistentVolume
metadata:
    name: pv-1
    labels:
        type: local
spec:
    storageClassName: manual
    capacity:
        storage: 50Gi
    accessModes:
        - ReadWriteOnce
    hostPath:
        path: "/mnt/data-1"

Был также PVC и Deployment, использующий этот PV. Затем я случайно уничтожил пространство имен, в котором находились эти ресурсы.

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

В моем случае с локальным ручным хранилищем все, что требовалось, это просто удалить PV и создать его снова. Удаление PV НЕ удаляет фактические данные на сервере (по крайней мере, с политика). Воссоздание PV с монтированием по пути, где данные уже существуют, также работает нормально — данные просто используются.