Состояние PV / PVC после удаления пода в Kubernetes

У меня есть кластер Kubernetes с развернутыми подами (DB, Frontend, Redis). Я не могу полностью понять, что происходит с PVC после удаления модуля.

Например, если я удалю POD_A, привязанный к CLAIM_A, я знаю, что CLAIM_A не удаляется автоматически. Если я затем попытаюсь воссоздать POD, он будет снова присоединен к тому же PVC, но все данные отсутствуют.

Может ли кто-нибудь объяснить, что происходит, я просмотрел официальную документацию, но на данный момент не имеет никакого смысла.

Любая помощь приветствуется.


person Rutnet    schedule 16.10.2019    source источник
comment
Было ли это развертывание или StatefulSet?   -  person Sida Zhou    schedule 30.06.2021


Ответы (1)


Срок службы ПВХ не зависит от стручков. Если PV все еще существует, это может быть связано с тем, что для ReclaimPolicy установлено значение «Сохранить», в котором случае он не будет удален, даже если PVC исчезнет.

PersistentVolumes может иметь различные политики возврата, включая «Сохранить», «Переработать» и «Удалить». Для динамически подготовленных PersistentVolumes политикой восстановления по умолчанию является «Удалить». Это означает, что динамически подготовленный том автоматически удаляется, когда пользователь удаляет соответствующий PersistentVolumeClaim. Такое автоматическое поведение может быть неприемлемым, если том содержит ценные данные. Обратите внимание, что ПОЛИТИКА ВОССТАНОВЛЕНИЯ - это Удалить (значение по умолчанию), которая является одной из двух политик возврата, другая - «Сохранить». (Третья политика Recycle устарела). В случае удаления, PV удаляется автоматически при удалении PVC, и данные на PVC также будут потеряны.

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

Это также может произойти, когда постоянный том защищен. Вы должны иметь возможность проверить это:

Команда:

$ kubectl describe pvc PVC_NAME | grep Finalizers

Вывод:

Finalizers:    [kubernetes.io/pvc-protection]

Вы можете исправить это, установив для финализаторов значение null с помощью патча kubectl:

$ kubectl patch pvc PVC_NAME -p '{"metadata":{"finalizers": []}}' --type=merge

РЕДАКТИРОВАТЬ:

PersistentVolume может быть установлен на хосте любым способом, поддерживаемым поставщиком ресурсов. Каждый PV получает свой собственный набор режимов доступа, описывающих возможности этого конкретного PV.

Доступны следующие режимы:

  • ReadWriteOnce - том может быть смонтирован как чтение-запись одним узлом
  • ReadOnlyMany - том может быть установлен в режиме только для чтения многими узлами.
  • ReadWriteMany - том может быть смонтирован как чтение-запись многими узлами

В интерфейсе командной строки режимы доступа сокращены до:

  • RWO - ReadWriteOnce
  • ROX - Только для чтения
  • RWX - ReadWriteMany

Таким образом, если вы воссоздали модуль и планировщик, поместите его на другой узел, и ваш PV имеет политику возврата, установленную на ReadWriteOnce, это нормально, что вы не можете получить доступ к своим данным.

В утверждениях используются те же соглашения, что и в отношении томов, при запросе хранилища с определенными режимами доступа. Мой совет - отредактировать режим доступа к PV на ReadWriteMany.

$ kubectl edit pv your_pv

Вы должны обновить режим доступа в PersistentVolume, как показано ниже.

   accessModes:
      - ReadWriteMany
person Malgorzata    schedule 17.10.2019
comment
Итак, вопрос, как мне заставить стручок вернуться к исходному ПВХ? - person Rutnet; 17.10.2019
comment
Я использую динамическое блочное хранилище в DigitalOcean на одном узле. В настоящее время нет возможности для ReadWriteMany - person Rutnet; 17.10.2019
comment
Вы можете предоставить свой файл конфигурации? - person Malgorzata; 07.11.2019